Trouble with debugger when using RAMFUNC

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Trouble with debugger when using RAMFUNC

1,564 Views
dh1
Contributor II

Hello

We just started to use RAMFUNC to improve code performance that is too slow with xip in QSPI flash.

Now we have a problem with the debugger. When we set a breakpoint in a RAMFUNC function, and then try to single-step, a long delay happens where nothing happens, and then an error is displayed by the debugger:

          Failed to execute MI command:
          -data-disassemble -s 50 -e 226 -- 3
          Error message from debugger back end:
          Cannot access memory at address 0x20000

The problem disappears when compiler optimization is off.

When the Disassembly window is closed, the problem does not happen.

The test is done with the NXP RT1060 devboard.

Please find attached the zipped project.

Best Regards,

Daniel

Labels (1)
Tags (1)
0 Kudos
Reply
3 Replies

1,449 Views
dh1
Contributor II

Hi Felipe

Is there an example of the easiest way to relocate the vector table to RAM with MCUXPresso?

Regards,

Daniel

0 Kudos
Reply

1,449 Views
FelipeGarcia
NXP Employee
NXP Employee

Hi Daniel,

 

I recommend you to check the following thread that discuss your question in more detail.

https://community.nxp.com/thread/453898 

 

Best regards,

Felipe

0 Kudos
Reply

1,449 Views
FelipeGarcia
NXP Employee
NXP Employee

Hi Daniel,

 

I recommend you to check the MCUXpresso User Manual in chapter 17.13.5. I will copy the related information below.

Due to the distance in the memory map between Flash memory and RAM, you will typically require a “long branch veneer” between the function in RAM and the calling function in Flash. The linker can automatically generate such a veneer for direct function calls, or you can effectively generate your own by using a call via a function pointer.

 

One point to note is that debugging code with a linker generated veneer can sometimes cause problems. This veneer will not have any source level debug information associated with it, so that if you try to step in to a call to your code in RAM, typically the debugger will step over it instead.

 

You can work around this by single stepping at the instruction level, setting a breakpoint in your RAM code, or by changing the function call from a direct one to a call via a function pointer.

https://www.nxp.com/docs/en/user-guide/MCUXpresso_IDE_User_Guide.pdf

 

In addition, if you are trying to run interrupts from RAM it is recommended to move vector table to RAM as well.

 

Best regards,

Felipe

0 Kudos
Reply