downloading code to SRAM_OC --- breakpoints don't work?

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

downloading code to SRAM_OC --- breakpoints don't work?

756 Views
ztzstan
Contributor II

I am trying to put some functions in SRAM_OC space (or SDRAM space), but it is weird that breakpoints don't work for the functions which are in SRAM_OC (or SDRAM). Thus debugging these functions is impossible. I encount this problem with program running on the offical dev board: evkmimxrt1060.

This is how to reproduce the problem that I see, by importing an SDK example:

1. click "Import SDK example", select board "evkmimxrt1060" --> demo apps --> iled_blinky --> click next --> select "link application to RAM" in MCU linker --> click finish.

2. add a simple function: __attribute__((__section__(".dummySectionName1"))) void FuncA(int x) { x++;x++;x++; return x; }, and call it in the main.

3. in project properties --> c/c++ build -->setting --> tool settings --> MCU linker --> managed link scrip --> click the green "+" button to create an extra input section with name as default *(.dummySectionName1), region as SRAM_ITC, setion type as .dat.

4. build, download and run. Everything is working as expected.

5. Add "BOARD_ConfigMPU();" after main. (without this, the program crashes)

6. Go back to "project properties --> c/c++ build -->setting --> tool settings --> MCU linker --> managed link scrip", and change the (.dummySectionName1) section region to SRAM_OC, build and run.

Now the problem comes out: although the program runs well (LED blinks as expected), but you can not set an effective break point in FuncA, neither can step into FuncA.  I can confirm that function FuncA is in SRAM_OC space (0x20200000, starting space).

The same problem happens if I change the (.dummySectionName1) section region to SDRAM (with some extra steps such as making the debuger connection script, etc)

To reproduce this problem on SRAM_OC is quite simple, just import the example, and do 5 steps modifying, the problem will come out. Could anybody help to fix this problem?

In this practice, flash is NOT used, it is completely "link to RAM". My final goal is to have codes ( debug version) in SDRAM, and no writing flash is involved. (I am essentially trying to accelerate the project downloading time, the 20+ seconds flash downloading is so annoying, I want to get rid of it.

3 Replies

721 Views
ztzstan
Contributor II

Victor, thanks for your replying. The way I found out (later) to fix the problem is comment out "SCB_EnableICache();" in function BOARD_ConfigMPU(). Basically it is the same solution as yours. Is there a solution that cache can still be turned on while code resides in OCRAM and can be stepped into?

0 Kudos

707 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello, 

Unfortunately, there isn't a solution that allows you to debug the OCRAM while having the cache enabled. 

Regards,
Victor 

0 Kudos

725 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello, 

The SRAM_OC is different than the SRAM_ITC and SRAM_DTC. The behavior that you are facing is due to the way that the RT communicates with the SRAM_OC. As a workaround, you can deactivate the IsCacheable feature of this memory. This is done in the function BOARD_ConfigMPU. By default, the OCRAM is configured in the following way: 

 MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 1, 0, ARM_MPU_REGION_SIZE_512KB);

You should have the following instead: 

MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 0, 1, 0, ARM_MPU_REGION_SIZE_512KB);

This will fix the behavior that you are facing. However, the performance of accessing the OCRAM without the cache enabled will be very poor. My suggestion would be that you use the ITC instead of the OCRAM. 

Regards,
Victor 

0 Kudos