No source available for "Reset_Handler() at 0x8984" while debugging an ARM TrustZone Project in Renesas e2 Studio and embOS Library

Question

Summary

I have a C++ ARM TrustZone project which is running on a R7FA4M2 controller and the embOS-MPU RTOS should be used. When I try do debug this project, the debugger does not find the source files as soon the code jumps from the secure project to the non secure project.

Detail

When the debugger is started, the code is found correctly. I see that there's a breakpoint hit at SystemInit(); at address 000010b0

              void Reset_Handler (void)
              {
                /* Initialize system using BSP. */
-> 000010b0     SystemInit();

The MCU State is also in SSD.Secure, so the program starts in the secure project as it should. I can step through the code until this point where the program jumps to the non-secure reset handler.

               /* Jump to the NS Reset_Handler */
-> 00000f54    p_ns_reset();

After that, the source files are not found correctly and the message No source available for "Reset_Handler() at 0x8984 is shown in the editor window.

Observations

Disassembly View

When I now change to the Disassembly View and step through the code in "Instruction Step Mode", debugging is still possible and somehow the name Reset_Handler is also known by the Disassembly view.

             Reset_Handler:
-> 00008984:   push    {r3, lr}
   00008986:   bl      0x8990 <SystemInit>
   0000898a:   bl      0x83f0 <main>
   0000898e:   b.n     0x898e <Reset_Handler+10>

It seems that the code is running correctly and also jumps to the non-secure project (which starts at address 00008000).

Project without embOS-MPU

The non-secure project has an embOS-MPU library included libosT8MLVHLDP_TZ.a and there are some minimal configurations that the project is compiling without errors. There are no Task or other embOS features implemented. When i remove this library from the project, the debugger is working as it should and is also able to find the files in the non-secure project. This means: An empty Bare-Metal ARM TrustZone Project is debuggable.

What I've checked

• Compiler Debug level: Default (-g)
• Debug format: dwart-4
• Debugging with different optimization levels (-Og, -O0, -O2)
• The linker command: -T "C:\\Workspace\\project\\fsp.ld" -Xlinker --gc-sections -L "C:\\Workspace\\project/script" -Wl,-Map,"host_sw_ns.map" --specs=nano.specs --specs=rdimon.specs secure.o "C:\Workspace\project\embos_mpu\Lib\libosT8MLVHLDP_TZ.a"

The .elf Files

There is a .elf file for each project host_sw_s.elf and host_sw_ns.elf. The .elf file of the secure project host_sw_s.elf can be unfolded in the Project Explorer:

host_sw_s Binaries

Unfolding the sw_ns.elf is not possible

host_sw_ns Binaries

When building without the embOS library, the functions are visible.

What I've tested

Adding Symbol File while Debugging

When the Debugger is already running I've tried to load the symbols again. The Debugger Console looks like this

add-symbol-file "C://Workspace//project//Debug//host_sw_ns.elf" 0x8000

add symbol table from file "C://Workspace//Gilgen//project//Debug//host_sw_ns.elf" at
    .text_addr = 0x8000
(y or n) [answered Y; input not from terminal]
Reading symbols from C://Workspace//project//Debug//host_sw_ns.elf...(no debugging symbols found)...done.
Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module C:\Workspace\project\Debug\host_sw_ns.elf]

It seems that there is Dwarf 5 defined in the .elf file even if in the setting Dwarf 4 is defined.

Checked gdb Version

I'm using the Renesas e2-studio v4.4.0 with the build in gdb debugger. At the start of the Debugger it is shown that there's an older version of the gdb in use

GNU gdb (GDB) 7.8.2-20221107-Build_1

Dwarf 5 is supported above gdb v10.1 which should cause the Dwarf Error Message.

Assumption

My assumption is that the embOS library was built with Dwarf 5 Debug information and when the linker does his job, there's somewhere Dwarf 5 defined in the .elf file and the old gdb does not understand this symbols.

Unsuccessful trials

Debug with Release embOS library

There's also a release build version of the embOS library libosT8MLVHLR_TZ.a. Maybe the release build library does not contain any debug information and therefore dwarf 5 is not defined. → Same error

Running external gdb Debugger

On the System is an gdb v12.1 debugger installed with Cygwin. In the Debugger settings I've changed the debugger to the specific path. The gdb does not start with following error message: Could not determine GDB version using command: gdb --version. When a local console is opened in e2 studio the command is working

C:\Renesas\RA\e2studio_v2023-04_fsp_v4.4.0\eclipse>gdb --version
GNU gdb (GDB) (Cagwin 12.1-1) 12.1

I've not troubleshooted this solution further.

Trying to update internal e2-studio gdb Debugger

I've not found a way yet. Is this even possible?

Answer 1

The Problem was, that the embOS-MPU library was Build with GCC V11.2 which included Dwarf-5 debug information. The integrated gdb Debugger v7.8 in e2-Studio v4.4 does not support Dwarf-5.

I've fixed the Debugging issue by integrate the Source files of the embOS instead of the pre-compiled library File. With this solution, the integrated GCC and gdb Debugger of the e2-Studio can be used with Dwarf-4 debug information.