Okay so we went from having no connection to the chip at all to having a connection but failing to flash. Some progress. Sad this not working out of the box.
Can you rerun the command from above? What does it say now?
If the program has connected successfully, use Ctrl+C to stop it again.
Seems to have had a bit of progress.
Did I do the Ctrl+C correctly? I am still new to command prompt as well.
After this step I ran a PIO Debug again, and I received the same exact error about “no flash bank”.
Yes, it very succesfully discovered and connected to the Cortex-M3 processor. Very good.
This is now a PlatformIO fault that it wants to flash to address 0x0. Lookg at the datasheet’s memory mapping, it looks to me like 0x0 is where the bootloader is (if this is non-modifyble we can’t write stuff there) and 0x80000 is where the actual internal flash is where the program should live.
Let me just double-check these memory addresses and how PlatformIO links the application and see how we can solve this very likely bug.
Now I also get why videos like PlatformIO Tutorial: programming Arduino DUE with Atmel-ICE / ST-Link - YouTube use a custom script that use the 0x80000 address to fix PlatformIO’s bug.
Actually, the platform might have a configuration option there that might correct it.
Can you add
board_upload.offset_address = 0x80000
to the platformio.ini and retry debugging?
Of Course.
I guess my real question is, do you see any errors? I assume that I will get used to this the more I work with the debugger.
No, that’s actually good and says that the debugging probe (STLinkv2) was able to halt execution on the chip so that it can read out the memory (for variables etc.) in peace. You’d have to worry about “failed to halt target” messages if there were any.
The output look very good. Can you stop debugging (stop button) and add
debug_init_break = break setup
(docs) to the platformio.ini.
Then if you start debugging now and if everything works it should now halt in the setup() function of your firmware code, indicated by a highlighted red or yellow line in the source code (“current execution position”). From there you can try to use the “step over” (arrow) button to step over the lines of code in your firmware.
I see, it seems as if there gets to a point where I can not step over anymore. Is there a way to get into the loop part of the program? Or is that something I learn by just getting familiar with debuggers.
However, adding the debug_init_break = break setup indeed made a stop at the setup.
What’s the last line you can still step over?
It is the last line of code in setup. After that there is only a pause option, which if I hit, takes me to a location in a random default file location. The two times I have tried hitting pause (it being one of the only options to click, besides stop), I have been left in wiring.c and hooks.c.
After the debugger halts in setup(), place a setup in the loop() function by clicking to the left of the line number.
Then press the “Play” button to resume execution. Does it hit the breakpoint in loop() or does it never reach there?
It does not stop there.
establishContact which is in the setup is the last thing to get highlighted before my options look like this:
Okay. Press the pause button. There should be a “Call Stack” on the left side which will tell you exactly how it got into the place it halted at. You can click at each individual function. Does one of the higher level ones trace back to your code? Maybe it blocks execution until the serial port is opened and a byte or something is sent?
You can also always open a separate serial monitor if you need it to establish the serial connection to your board as your sketch requires it. I like using programs like HTerm - der-hammer for it.
I do think that the Serial communication is what is stopping the program it seems.
