I recently transitioned from working with the SAME51J20A to exploring the J18A. Given that the J18A lacks native support, I had to create a Board json and make adjustments to the linker scripts to accommodate the smaller flash and RAM size. Although my debug console indicates that everything is in order and I can build without encountering any errors, I’ve hit a roadblock during the debugging process. Every time I try to debug my code, the controller gets stuck in the Reset handler without executing any command. When I disconnect and opt for debug without upload, attempting to reconnect to the J18A results in this message: [at91same51j18.cpu] halted due to debug-request, current mode: Handler HardFault. It appears to be a memory violation issue to me, but I’m unsure about the next steps to take. Any insights or assistance would be greatly appreciated.
Maybe just an addtional Information: my setup for the SAME51J18A works perfectly fine for the J20A so there shouldn not be any servere mistakes regarding the board JSON. The only difference I noticed was the different flash (256KB) and ram size (128KB) which i changed.
Do you flash your firmware at 0x0 or somewhere higher because there’s a bootloader installed?
I would recommend you watch the execution instruction-by-instruction, starting from the moment of reset. For that, add
debug_init_break = break Reset_Handler
and see if starts execution in your reset handler as defined by the .S startup file at all. Forward one instructions at a time by using the stepi in the Debug Console. Note the last instruction it tries to execute before it jumps into your hardfault handler.
I am flashing with an offset of 4000 for my 16KB Bootloader. the Bootloader was confirmed and bootprot has been set.
Your line does not impact the debugging of the SAME51J18A at all it still is stuck at the first line of Reset_Handler without executing. I compared the same procedure for my J20A and there it works as intended an breaks at the Handler making stepping available.
For the J18 However i cant step at all since i won’t even reach the first command line.
This is again a very low address. If you have the .elf file of the bootloader available, you should be able to get some symbol information on at least which file, function and line you’re currently on with a command like
Especially check if the bootloader was rebuilt for the smaller RAM size, since a wrong first entry in the vector table (initial SP) will cause a crash very quickly at the first branch, push or pop instruction since that uses the stack.