MCUXpresso and RT1050 download and debug in SDRAM

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

MCUXpresso and RT1050 download and debug in SDRAM

2,824 Views
w2vy
Contributor V

My application is larger than the on chip SRAM, so I am working on building a debug version that will load and run in SDRAM.

I found a few useful threads and I may be down to the last issue. RT1050_BriefOverview_v201.pdf was very helpful

To summarize some of the changes I made

I updated the MCU Settings to add the SDRAM, and added a region for the last 2MB which is said to be uncached.

I made the SDRAM first in the list, I also adjusted the stack not to be at the exact top of SDRAM

I set XIP_EXTERNAL_FLASH=0 and I also added SKIP_SYSCLK_INIT

I added RT1050_SDRAM_Init.scp as a connect script for the debugger to init SDRAM controller

ISSUE> I can not step over a break point, I can't even remove a BP I have hit without reloading the image.

It feels like a cache issue, almost like the Debugger is not updating/flushing Instruction Cache

If I load a project with a BP already enabled and before I run it I remove the BP, then it is not hit.

If I hit a BP I can use the debugger to move past it, skipping a statement.

I would rather not disable cache for the SDRAM, I am hoping there is a way to fix it in the debugger

Any suggestions?

Tom

Labels (1)
0 Kudos
5 Replies

2,359 Views
w2vy
Contributor V

I am seeing the opposite, Not disappearing BPs but ones I can't get rid of

I can try Hardware BPs. but those are typically limited in number.

Can you debug in SDRAM with software BPs?

Tom

0 Kudos

2,359 Views
jorge_a_vazquez
NXP Employee
NXP Employee

Hi Tom Moulton

Yes, sorry for my mistake, what I mean was the breakpoints DOESN'T disappears and you can't get rid of them.

Yes, I'm seeing the same as you, but the alternately for this is using HW BP.

Regards

Jorge Alcala

0 Kudos

2,359 Views
w2vy
Contributor V

I went into board,c and modified BOARD_ConfigMPU(void)

From:

#if defined(SDRAM_IS_SHAREABLE)
/* Region 7 setting: Memory with Normal type, is shareable, outer/inner write back */
MPU->RBAR = ARM_MPU_RBAR(7, 0x80000000U);
MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 1, 1, 1, 0, ARM_MPU_REGION_SIZE_32MB);
#else
/* Region 7 setting: Memory with Normal type, not shareable, outer/inner write back */
MPU->RBAR = ARM_MPU_RBAR(7, 0x80000000U);
MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 1, 0, ARM_MPU_REGION_SIZE_32MB);
#endif

TO

#if defined(SDRAM_IS_SHAREABLE)
/* Region 7 setting: Memory with Normal type, is shareable, outer/inner write back */
MPU->RBAR = ARM_MPU_RBAR(7, 0x80000000U);
MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 1, 1, 1, 0, ARM_MPU_REGION_SIZE_32MB);
#else
#if defined(SDRAM_IS_CACHEABLE)
/* Region 7 setting: Memory with Normal type, not shareable, outer/inner write back */
MPU->RBAR = ARM_MPU_RBAR(7, 0x80000000U);
MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 1, 0, ARM_MPU_REGION_SIZE_32MB);
#endif
/* Region 7 setting: Memory with Normal type, not shareable, no cache */
MPU->RBAR = ARM_MPU_RBAR(7, 0x80000000U);
MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 1, 0, 0, 0, 0, ARM_MPU_REGION_SIZE_32MB);

#endif

I matched the settings of the last 2MB which the docs describe as being non cached.

I still have the same issue with not being able to step through BPs

So maybe I was wrong about the real issue...

Tom

0 Kudos

2,359 Views
jorge_a_vazquez
NXP Employee
NXP Employee

Hi Tom Moulton

This is related to the cache and the access to the SDRAM. If you place the code in the SDRAM section that is noncacheable, you will see that this issue of stepping and breakpoints disappears.

A Breakpoint by default is a software brkp, which is saved in the default RAM, you alternately could use a hardware breakpoint (right click and add breakpoint->type: hardware).

Hope this helps
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
-------------------------------------------------------------------------------

0 Kudos

1,832 Views
robert_s
Contributor III

Hi,

I have a very similar problem to this but using an RT1170, with MCUXpresso v11.4.0.
My program appears to run but:
- a) once a breakpoint is hit the program is not debuggable afterwards.
- b) I notice that my (ethernet) interupt callback function is not longer being called.

Before creating my own forum post, I have a few questions about the above.
w2vy says:
- "I updated the MCU Settings to add the SDRAM, and added a region for the last 2MB which is said to be uncached".
- How do I do this? I can split-off some SDRAM using the IDE's MCU Setting dialog, but how to make it uncached? Is that done via a linker script? Or via a code change?
- "I added RT1050_SDRAM_Init.scp as a connect script for the debugger to init SDRAM controller"
- I can't see an example of this for the RT1170, so I presume this is something we need to generate ourselves? Unfortunately that's not something I know how to do.
- Add "/* Region 7 setting: Memory with Normal type, not shareable, no cache */", etc. to BOARD_ConfigMPU().
- When I add a similar set of lines of code I get a SIGSTOP in MemManage_Handler().
- Note: If I replace the existing Region 7 lines (appears to be Region 9 on the RT1170) instead of adding them I don't get the crash.

I would be grateful for any help you can provide.

Thanks,

Robert

0 Kudos