Hi,
When I run a debugging session the processor Hard Faults for code which it should not hard fault for.
The issue has been tracked down to the code running from the debugging session not beeing the same as the one in the elf file.
When i run
arm-none-eabi-objdump -d
You can see that instruction 0x40a is different from when running in gdb session
The practical information:
OS: Ubuntu 16.04
Debugger: J-Link Base
MCU: NXP S32K144 (Evaluation board S32K144EVB)
The commands I'm using
To start the gdb server:
JLinkGDBServer -device S32K144 -if SWD -speed 4000
To start the gdb session:
arm-none-eabi-gdb ../target/thumbv7em-none-eabihf/debug/examples/light.hex
target remote :2331
monitor semihosting enable
load
The elf file is ziped and added as an Attachments (light.zip) in case you wish to run tests on it.
Hope you can make sense out of this bizarre bug as I'm completely lost.
When I run a debugging session the processor Hard Faults for code which it should not hard fault for.
The issue has been tracked down to the code running from the debugging session not beeing the same as the one in the elf file.
When i run
arm-none-eabi-objdump -d
You can see that instruction 0x40a is different from when running in gdb session
The practical information:
OS: Ubuntu 16.04
Debugger: J-Link Base
MCU: NXP S32K144 (Evaluation board S32K144EVB)
The commands I'm using
To start the gdb server:
JLinkGDBServer -device S32K144 -if SWD -speed 4000
To start the gdb session:
arm-none-eabi-gdb ../target/thumbv7em-none-eabihf/debug/examples/light.hex
target remote :2331
monitor semihosting enable
load
The elf file is ziped and added as an Attachments (light.zip) in case you wish to run tests on it.
Hope you can make sense out of this bizarre bug as I'm completely lost.