This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cortex-M23 FVP hard faults when using DS-5 Debugger

Hi,

I'm starting to explore this technology by running the TrustZone example application in Linux using GNU ARM Toolchain. This example is provided by a CMSIS software pack containing this example called "TrustZone for ARMv8-M No RTOS" which I was able to successfully run on Windows 10 + Keil.

I've been able to compile this example and even download it to the FVP (FVP_MPS2_Cortex-M23) after using GNU ARM Toolchain on Linux. But when it comes to debugging, problems start to appear... First, I tried to use ARM Fast Models' Model Debugger and it all went fine except I couldn't place any breakpoints in the non-secure code as this software acts kind of strange when 2 elf files are loaded because it ignores one of these files' debug information. Then, I decided to give DS-5 a try, thinking this wouldn't happen.

Created a project in DS-5 IDE, Makefile based, because I only want to use its Debugger. Now, the problem is that the example always crashes after entering libc_init_array function and executing the "BLX R3" instruction. Which is kind of odd, because when I used Model Debugger with the same .elf files, the program would never crash when this instruction was executed! I found that R3 contained different values when using Model Debugger and DS-5 Debugger to debug this application. How can this happen? Is CADI Server messing with the FVP? Am I missing something? I don't know what more can I do to solve this.

The value present in R3 before the "BLX R3" instruction is 0xCFDFDFDF

This is what I got after executing the instruction on the Commands tab:

ERROR(CMD256-TAD10-NAL23):
! Unable to display contents at location "0xCFDFDFDE"
! Failed to read 2 bytes from address 0xCFDFDFDE
! Memory read from model failed.

Please, can you help me out? Thank you in advance!

  • I finally found the problem! DS-5 Debugger loads the data values directly to the VMA equivalent, and not to the LMA, as it happens in other debuggers. This command sorted things out: "set elf load-segments-at-p_paddr on"