Hello,
I'm using a J-Trace Pro to debug an ATSAM4SD32C. While I've tried to figure out, why my code is not doing, what it is supposed to do, I came to the conclusion, that the content of my elf file is not flashed correctly. This is not 100% reproducible but if I inspect for example the interrupt table and compare it with a list file or hex file, I find the address of the Reset_Handler to be "reasonable", but not correct. In the log of the SEGGER J-Link GDB Server V6.54 (GUI Version), I found a clue, that there might have been something wrong:
I've set the "Verify download" option in the GDB server, but even with this option, I don't get any feedback that I can see in GDB (cli version; 7.12.1). This is how my .gdbinit looks like:
Is there a ways to get reliable around this error / to prevent this error? Is there a way to at least get direct feedback in GDB, that such an error occurred?
best regards,
Torsten
I'm using a J-Trace Pro to debug an ATSAM4SD32C. While I've tried to figure out, why my code is not doing, what it is supposed to do, I came to the conclusion, that the content of my elf file is not flashed correctly. This is not 100% reproducible but if I inspect for example the interrupt table and compare it with a list file or hex file, I find the address of the Reset_Handler to be "reasonable", but not correct. In the log of the SEGGER J-Link GDB Server V6.54 (GUI Version), I found a clue, that there might have been something wrong:
The line starting with `ERROR` does not appear, when loading the elf file, but when I start my debug sequence with `monitor reset`. In the cases, where it looks it seems to working correctly, the Error message and the two following lines starting with "RAM" are not present in the log file.log wrote:
Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x0040035C (Data = 0xF0004801)
Read 2 bytes @ address 0x0040035C (Data = 0x4801)
Received monitor command: speed 1000
Target interface speed set to 1000 kHz
Received monitor command: flash breakpoints = 1
Flash breakpoints enabled
Received monitor command: flash download = 1
Flash download enabled
Received monitor command: flash device = ATSAM4SD32C
Selecting device: ATSAM4SD32C
Downloading 15952 bytes @ address 0x00400000 - Verified OK
Downloading 7452 bytes @ address 0x00403E50 - Verified OK
Downloading 240 bytes @ address 0x00405B6C
- Verified OK
ERROR: Failed to prepare for programming.
RAM check failed @ addr 0x20000785.
RAM check failed while testing 0x07F0 bytes @ addr 0x20000784.
Writing register (PC = 0x 400000)
Read 4 bytes @ address 0x00400000 (Data = 0xFEF7FFFF)
Read 2 bytes @ address 0x00400000 (Data = 0xFFFF)
Read 2 bytes @ address 0x004009F0 (Data = 0xFFFF)
Read 4 bytes @ address 0x00400000 (Data = 0xFFFFFFFF)
Read 2 bytes @ address 0x00400000 (Data = 0xFFFF)
Read 2 bytes @ address 0x00400002 (Data = 0xFFFF)
Read 2 bytes @ address 0x0040499C (Data = 0xFFFF)
Read 2 bytes @ address 0x0040499C (Data = 0xFFFF)
Read 2 bytes @ address 0x0040499C (Data = 0xFFFF)
Read 2 bytes @ address 0x00400A82 (Data = 0xFFFF)
Read 2 bytes @ address 0x00400ABA (Data = 0xAB4B)
Received monitor command: reset
Resetting target
Received monitor command: reset
I've set the "Verify download" option in the GDB server, but even with this option, I don't get any feedback that I can see in GDB (cli version; 7.12.1). This is how my .gdbinit looks like:
.gdbinit wrote:
# set print pretty on
# set debug remote 1
target remote localhost:2331
monitor speed 1000
monitor flash breakpoints = 1
monitor flash download = 1
monitor flash device = ATSAM4SD32C
load ../sensor-blp/cmake-build-workspace-none-cortex-m4-debug-gcc/bin/backend_verifications.elf
symbol ../sensor-blp/cmake-build-workspace-none-cortex-m4-debug-gcc/bin/backend_verifications.elf
break crash_log_hardfault_parameters
break usb.cpp:28
monitor reset
Is there a ways to get reliable around this error / to prevent this error? Is there a way to at least get direct feedback in GDB, that such an error occurred?
best regards,
Torsten