1.3.0 squashes bug 64277-download-and-reset-without-gdb (thank you team). However, when disconnected from SWIO and powered-on the chip never starts.

[Sking.21]

Compiling with a Release configuration seems to be correct because when connected via j-link, activating "Run" the console now prints "Starting target CPU" and "GDB closed TCP/IP connection" and the CPU starts. But disconnect SWIO and reset power and nothing happens.

Assuming boot0 and NRST were wired correctly, would my CPU be expected to start when power is applied?

[mattias norlander]

Yes. It should be able to start. Are you able to start it if you via Debug? The Run configuration shares data with the "Debug" configuration (derived from .launch-file). Difference is just performing load command and monitor reset.

Monitor reset command may either reset the device writing to some core register in MCU or use the NRST pin. This is up to the implementation of the GDB-server. Please consult SEGGER manual if you are using the J-Link.

[Sking.21]

Hi Mattias,

Thanks for the reply. Based on your answer, for testing, another slightly different board was built with the same

MCU and that one does start, so there was something up with the first one.

It fooled me because it worked perfectly from CubeIDE and numerous hardware checks passed. (scratch head).

I still think a run or download-only command should not care about debugger settings, but that is another matter.

Thanks again.

[mattias norlander]

"I still think a run or download-only command should not care about debugger settings, but that is another matter."

There are pros and cons with this approach. Some of the debug settings will be required in some use cases, while they quite likely will result in load+reset not possible in other use cases. We are open to improvement suggestions based on feedback from the forum! :)

[Sking.21]

Hmm. Well, personally I find it frustrating that I have to say "run" to program the chip. I didn't want anything to run, I wanted to program the memory. I am familiar with the Atmel Studio software. It has a very satisfyingly distinct "program chip" button. I am not quite sure what happens if you download while a running instance is stopped at a breakpoint, which I will guess is one of the thorny use cases to which you allude. I think its debugger is part of the same process and so does not need socket information to communicate with a gdb process. But I think a program button on CubeIDE should do what CubeProgrammer does.