RT1050, RT1060 demo apps don't run from RAM

[gpontis]

I have been working with the 1050 EVKB, 1060 EVK in MCUXPresso 10.3.0 with SDK 2.5.0. Both USB and LWIP applications build, load, and run fine. However, if I change the Managed Linker option by checking "Load to RAM", and move IT and OC ram to the top, then they both fail.

The don't fail completely. One can still start the app in the debugger and step through code. I traced down into the USB initialization and found that everything breaks when the code attempts to write a 0 to the USB Device Address register. By breaking, I mean that the debugger loses control and the app is not running ( so far as I can tell ).

I was able to duplicate the breakage by attempting to write that register using the debugger, earlier in the program flow. However, when running the image from flash, there does not seem to be any problem writing that register. So, something in the environment is different in these two cases, and I am hoping someone knows or can suggest some place to look for that difference.

I have tried disabling specific interrupts and even all interrupts globally before writing that register, but to no effect. I also tried not enabling the MMU, also without effect.

[victorjimenez]

Hello George,

Could you please tell me with which example did you see this behavior? I tried to reproduce it using the following tools:

• i.MXRT1050-EVK
• SDK 2.5.0
• MUCXpresso IDE 10.3
• dev_cdc_vcom_bm example

I linked all the application to RAM by checking "Link application to Ram" on the Managed Linker Script (same as you) and I tried with the three regions of RAM, I didn't face any errors while debugging. Could you please tell me which example are you using so I can reproduce your findings on my side?

Looking forward to your reply!

Regards,

Victor

[gpontis]

Hi Victor,

Good to hear that it worked for you.

I have the IMXRT1050-EVKB board and was trying the example from SDK 2.5.0 "evkbimxrt1050_dev_composite_cdc_msc_bm".

I moved SRAM_OC to the top of the list and the summary output after building shows that everything is located there.

I might also mention that I am using a Segger JLink. Also related to debugging and debuggers, I experienced a case where the MCUXpresso + JLink would not successfully load a program to RAM. It said that it did, but the code was partly corrupt. I could load the same .axf file with Segger's Ozone debugger and it seemed to work fine.

George

[victorjimenez]

Hello George,

Sorry for the late response. I tried to reproduce the behavior that you mentioned, first I move all the application to SRAM_OC:

And when I enter the debug session I was able to debug all the application without any problems. Also, I checked that I was, in fact, executing from the SRAM_OC:

For this, I used the same example as you, the i.MXRT1050-EVKB and the openSDA that comes with the evaluation kit with the CMSIS firmware. If I understood correctly you are not using the OpenSDA instead, you are using an external JLink debugger right? What about the RT1060-EVK are you also using an external JLink debugger? Could you please confirm this so I can try to reproduce the behavior you are facing.

Looking forward to your reply!

Victor,

[gpontis]

Hi Victor, You are correct in that I have done all my work with the Segger JLink. I loaned the 1060 Eval board to a colleague who is using a JTrace and experiencing the same issues.

In addition to the 1050 EVKB I have some custom hardware for the 1062. So far it is looking like my custom hardware and the 1052 both fail to run the USB demo code when running out of RAM. The custom board only has the Cortex-M debug connector so there is no OpenSDA option. Also, the custom hardware doesn't have the HyperFlash, it has HyperRAM and the flash is on LPSPI3. It has been tricky to get that flash programmed so I can't try running from flash on that board yet. But I am working on it ...

I wanted to try OpenSDA to see if I could duplicate your results but cannot even get started with it. It seems to load the app and halt at the first line, BOARD_ConfigMPU. But I can't run from there or even step into the function.

George

[victorjimenez]

Hello George,

Thanks for clarifying. I was able to reproduce the behavior you mention. I used a J-Link plus debugger version 10.1 with the i.MXRT1050-EVK and i.MXRT1060-EVK.
This behavior is due to the J-Link debugger since it doesn't appear if I debug with the OpenSDA/LPC-LINK2 or other external debuggers. I'm already checking this directly with Segger, I will let you know when I receive any feedback from them.

Best regards,

Victor.

[Daniil]

Dear Victor,

do you have any resolution for this problem? This issue is still there with MIMXRT1011 too for instance and J-Link EDU.

Best regards,

Daniil.

[thomas_k1]

Hello Victor,

we have the same Problem. Do you have any News about the Segger topic? Is there already a work-around?

Thank you

Thomas

[gpontis]

Hi Victor,

Thanks for trying the JLink and bringing it up with Segger. I ordered a couple of LPC-Link2 boards to try with MCUXpresso. It would be fantastic to have USB or ethernet working, and get back to the mainstream app development.

George