Debugging with ATSAME51J18A

Development Platforms
1

Hey everyone,

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.

Thanks, Paul

2

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.

3

Is there no backtrace available in GDB? (where command in the “Debug Console”).

If this appears early in the startup code, the initial value of the stackpointer / SP (which should be at RAM end) may be wrong or not properly updated.

4

So I started a debug session in VSC and entered “where” into the debug console after i paused the program which gave me this response:
where

#0 0x00000c7a in ?? ()

#1 0x00000592 in ?? ()

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

{“token”:26,“outOfBandRecord”:[],“resultRecords”:{“resultClass”:“done”,“results”:[]}}

how do i find the source to this issue?

5

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 =

or

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.

6

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.

7

Both these addresses are below 16KB, so it’s in the bootloader?

When you halt the chip via the pause button and execute i r, what’s the output?

8

you are right, I am using the same bootloader for J18 as for J20 and didnt have a look into that yet…
thats the output:

i r
r0             0x200001d0          536871376
r1             0xf01669ef          -266966545
r2             0x2002f000          537063424
r3             0x0                 0
r4             0x5931              22833
r5             0x0                 0
r6             0x40000000          1073741824
r7             0x80000000          -2147483648
r8             0xf7fb9fbe          -134504514
r9             0xfffbffff          -262145
r10            0xfffbffff          -262145
r11            0xfff5efa9          -659543
r12            0x0                 0
sp             0x2000d660          0x2000d660
lr             0xfffffff9          -7
pc             0x570               0x570
xPSR           0x61000003          1627389955
fpscr          0x0                 0
msp            0x2000d660          0x2000d660
psp            0xfffffffc          0xfffffffc
primask        0x0                 0
basepri        0x0                 0
faultmask      0x0                 0
control        0x0                 0
9

The register output does not seem complete, where is sp, lr and pc? I was interested in the address that it is in after crashing.

10

my bad copying from VSC console is a pain. I edited the previous message

11

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

symbol-file bootloader.elf -readnow
12

your right, this seems to be a bootloader issue. Thanks for your Help!

13

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.