rt1064 EVK/MCUXpresso debugging from RAM unstable

[GlennSikkema]

I am using the rt1064 EVK (SDK version 2.7) and debugging using MCUXpresso IDE v11.1.1. My group is working on an application that does some specialized flash management, and requires us to use the FlexSPI interface directly. Because of this, when our app is running we cannot have XIP going on. This requires us to develop and run our application while it is running in RAM.

I have everything set up... using a flash simulation stub of our own design, within the IDE I am able to successfully build, download, run, debug and test our application. But we need to start using the real flash now, which means linking and debugging our application in RAM.

To accomplish this, I did the following:

• Set up SRAM_OC to be the first RAM region listed in the memory configuration table (this region is large enough to hold our application... SRAM_ITC is not).
• Set up the BOARD_SDRAM to be operational and placed the heap there (in some forms our application needs to allocate significant amounts of memory). This is working fine.
• Set up the stack to be in SRAM_DTC.
• Checked the "Link application to RAM" checkbox in the managed linker script.
• In the LinkServer tab of the 'Edit Launch Configuration' dialog, set "reset handling" to "SOFT".
• I do not modify any other settings, including XIP.

When I try to download this through the debugger, the behavior is not stable. Sometimes it seems to work. Other times it seems to successfully download but crashes when I launch it. Other times it crashes during the download process. Once crashes start to happen, I can sometimes reduce them by cycling power on the target, but other times not even that works. When I revert to running XIP, I can get it working in a stable way again.

Using the debugger to change the application currently programmed into the flash seems to affect the behavior when I move to trying to link the application to RAM. It's almost as if the debugger is trying to start a debug session with the application in RAM, while at the same time the target is trying to run some other application previously programmed in flash, and the two conflict.

The question is, am I missing any settings? It seems to me that when told to link and debug an application in RAM, the IDE would tell the target not to run any code (other than the low-level stuff that gets run before "main()") not to run anything out of flash. How do I tell the target to ignore any applications stored in flash? Do I have to do something to explicitly disable XIP? Or, am I way out to lunch with that theory? I'm pretty new to the rt1064 and this IDE.

[kerryzhou]

Add the project attachment, FYI.

Wish it helps you!

If you still have questions about it, please kindly let me know.

Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[GlennSikkema]

One thing I should say is that I have XIP_BOOT_HEADER_DCD_ENABLE=1. I found this to be necessary to enable the BOARD_SDRAM. Is it possible this has other effects?

[kerryzhou]

Hello Glenn Sikkema.

  Maybe you misclick the status as assumed answered.

  Please don't worry, I will help you to answer it.

  At first, I suggest you refer to this document:

https://www.nxp.com/docs/en/application-note/AN12107.pdf 

https://www.nxp.com/docs/en/nxp/application-notes/AN12183.pdf 

  If you want to download the code to the flash, you need to enable:

Please enable it and try it again.

If you still have questions, please also share me your MCU settings in the project properties:

Wish it helps you!

If you still have questions about it, please kindly let me know.

Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[GlennSikkema]

Okay we're running into a different problem.

When downloading and running from RAM, the debugger functions don't seem to work. I can launch the application by clicking the "resume" button, but I can't single-step (it just runs the program as if the step function failed to set a breakpoint on the next line of code), and if I set a breakpoint, the debugger hits it, but I cannot continue. It seems to just restart and hit the exact same breakpoint again.

Any ideas?

[kerryzhou]

Hi Glenn Sikkema,

  Double confirm your question.

  1. With windows MCUXPresso IDE, rt1064 EVK, sdk2.7.0, now, let's take the led_blinky project as an example.

  Then modify your RAM like this:

Right?

Seem my debug status:

The address is 0X20200580, it is the OCRAM area.

So, my modification is correct, after exit the debug mode, my led is still blinking.

I also attach my project for your reference.

2. About your colleague linux version, please create a new question post about it, we will also help him to check details.

Wish it helps you!

If you still have questions about it, please kindly let me know.

Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[GlennSikkema]

I've seen other resources that say this is a caching problem. How do I disable the cache for SRAM_OC, or more to the point, for the .text section? I don't propose that as any sort of permanent solution, but for us to continue development we need a functional debugger.

[kerryzhou · Accepted solution]

Hi Glenn Sikkema,

    Please add the --no-packed --cachelib libm7_cache.so in your linkserver debugger. Then you will can enter the breakpoints and the step into.

My test result:

This issue has been write in this post:

Overview of using the MIMXRT1050-EVK(B) with MCUXpresso IDE 

Check document chapter Debug performance and the Data Cache.

Please try it again.

If you still have questions about it, please kindly let me know.

Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[bowerymarc]

Where would you put those parameters "--no-packed --cachelib libm7_cache.so" when using the Segger J-Link debugger?  I'm assuming it has the same issue?

[GlennSikkema]

@Kerry-

Thank you very much, that did the trick! We now have a functional debugger.

For a word of advice, this is ABSOLUTELY the sort of information that MUST be put into the IDE user's guide, in the sections dealing with running applications from RAM. The fact that it's not is a pretty serious omission, because debugging from RAM can't work without it. The post you referred to me is over two years old. It's hard for me to believe that the information needed for customers to get through this issue is still so hard to find.

Still, I thank you for your help. We are in business now!

To finish up, there are still two questions from my earlier posts that I would like to have addressed, namely these:

1. I would like to get more guidance on why I had to select "Reset on Connect" in the launch configuration. Without it, my "link application to RAM" setup was unstable. With it, it runs fine (except for the debugger facilities as described above, of course).
2. I would like to know why we have to do workarounds to get the boot header programmed when linking applications to RAM. Why doesn't that happen automatically? Why is it necessary? I know the boot ROM consults the boot header when booting, but if applications that are linked to RAM still require boot headers to be programmed into flash, why does the debugger not do that for us?

These issues are not blocking us since we have found workarounds, but I would like to know more about them.

Thanks again.

[kerryzhou]

Hi Glenn Sikkema,

  1.  I would like to get more guidance on why I had to select "Reset on Connect" in the launch configuration. Without it, my "link application to RAM" setup was unstable. With it, it runs fine (except for the debugger facilities as described above, of course).

  Do you mean the following reset on connect?

  I even didn't select it.

2. I would like to know why we have to do workarounds to get the boot header programmed when linking applications to RAM. Why doesn't that happen automatically? Why is it necessary? I know the boot ROM consults the boot header when booting, but if applications that are linked to RAM still require boot headers to be programmed into flash, why does the debugger not do that for us?

Please let me know which detail header? It's better to add some picture about it. 

 XIP_BOOT_HEADER_DCD_ENABLE=1, this one?

 Do you add the SDRAM in your code?

If you use it, you need to initialize the SEMC, as you know SDRAM is the external memory.

Wish it helps you!

If you still have questions about it, please kindly let me know.

Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[GlennSikkema]

@Kerry-

For what it is worth, here are my settings for Managed Linker Script, MCU settings and launch configuration.

[GlennSikkema]

@Kerry-

So, here's what I did. I know this is kind of long and detailed, but I want to be sure not to leave anything out:

1. I installed the blinky sample project from the SDK.
2. I made all the adjustments as you suggest above:
   • Adjust "SRAM_OC" to be the first RAM region listed in the table in the "MCU Settings" dialog, and applied the changes.
   • Checked the "Link application to RAM" in the "Managed Linker Script" dialog, and applied the changes.
   • Adjusted the launch configuration of the MCUXpresso IDE LinkServer probes "Reset handling" to "SOFT".
3. Cleaned and rebuilt the application.
4. Started a debug session. I noted that the debugger skipped the programming of flash. It came up and placed me at the first line of code in "led_blinky.c"... a call to 'Board_InitPins()'. No problems to this point.
5. Tried to "step over" the 'Board_InitPins()' procedure using the step-over button in the IDE's interface.
6. It crashed with "imprecise bus error" on line 70 of 'pin_mux.c'. This is the sort of problem my colleague was having up until late last evening. Based on what we found out about that, I then:
7. Terminated the debug session.
8. Deselected "Link application to RAM" checkbox on the "Managed linker script" page, set the "Reset handling" in the launch configuration to "Default", cleaned and rebuilt the project and restarted the debugger session.
9. Watched the debugger program the flash, presumably including the boot header.
10. It came up at 'Board_InitPins()' again.
11. This time I can debug... step-into, step-over, step-out and breakpoints all work as expected. The application runs as expected.
12. Terminate the debug session. Set up to link application to RAM again, and adjust the "Reset handling" of the launch configuration to "SOFT". Cleaned, rebuilt and restarted the debugger session.
13. Verified that this time the debugger did not reprogram the flash.
14. It comes up again at the same point.
15. Tried again to step over the 'Board_InitPins()' function.
16. This time, the application did NOT crash. Obviously steps 7 to 11 have programmed something into flash that fixes that.
17. However, the debugging facilities do NOT work correctly. When I tried to step-over 'Board_InitPins', it did NOT stop on the next line of code, and the application just ran. I'm watching the LED blink as I type this. I did NOT hit the "resume" button, I hit the "step-over" button. "Step-into" and "step-out" show the same incorrect behavior. Breakpoints to NOT behave as expected.

I haven't done it yet, but I will bet anything that when I return to my application, I will have to go through this process again to reprogram the boot header.

I am willing to bet that most if not all of your sample apps use the same stuff in the boot header, and so you don't have to reprogram it when switching between sample apps or trying to link to RAM. I would make a suggestion... try an application that uses different settings in the boot header (e.g. setting XIP_BOOT_HEADER_DCD_ENABLE=1), go through your procedure and try to verify application and debugger functionality when you run that application from RAM, and see what happens. I'll bet you run into trouble.

[GlennSikkema]

@Kerry-

P.S. Would you like me to open a separate ticket about the difficulties with the debugger facilities?

[GlennSikkema]

@Kerry-

Thanks very much for the reply. We do have an update this morning on my colleague's situation. What we think we have found is that if you make any changes that affect the boot header, we have to reflash it even if we are linking the application to RAM. Thus, we worked around his situation by:

1. Temporarily clearing the "Link application to RAM" button for our application;
2. Cleaning and rebuilding our application;
3. Downloading our application through the debugger (which then gets flashed, including the boot header);
4. Turning "Link application to RAM" back on, cleaning and rebuilding;
5. Terminating and restarting the debugger session.

After this, my colleague's difficulties with getting the application to run were cleared up. I had already done this myself as a sanity check when I was having stability problems, and in so doing had incidentally reprogrammed the boot header. My colleague hadn't done so when he first tried linking to RAM. So, I don't think we will need to post a separate question.

As for the remainder of your answers, we've already done all that with our application, and as I say we can get it to run now. We just can't use the debugger facilities (step-into, step-out, step-over, breakpoints) because they misbehave. So, this ticket is coming down to three requests:

1. I'm going to try "blinky" and see if the debugger works when running from RAM. But I would like confirmation... when you set up your "blinky" project as per your instructions, did you actually try the debugger facilities (like step-into, step-over, step-out and setting breakpoints)? Did they work for you? I have guidance from other resources who say they also have had this problem, and we may have to make adjustments to MMU configuration or make the .text section non-cacheable. Can you confirm this?
2. I would like to get more guidance on why I had to select "Reset on Connect" in the launch configuration. Without it, my "link application to RAM" setup was unstable. With it, it runs fine (except for the debugger facilities as described above, of course).
3. I would like to know why we have to do workarounds to get the boot header programmed when linking applications to RAM. Why doesn't that happen automatically? Why is it necessary? I know the boot ROM consults the boot header when booting, but if applications that are linked to RAM still require boot headers to be programmed into flash, why does the debugger not do that for us?

[GlennSikkema]

Kerry-

Yes, you are right I must have mistakenly clicked on "Mark as assumed answered"... my bad. I am new to this development environment and to this forum.

And thanks very much for your reply. Certainly I will take a look at the documents you link.

However, downloading into flash was not my problem. I never had any difficulty using the debugger to download, run and debug my application as XIP. My difficulty was when I tried to switch over to downloading, running and debugging my application in RAM. I did it by: 1) selecting the "Link application to RAM" checkbox on the "Managed Linker Scripts" page; 2) adjusting the memory configuration so that SRAM_OC was the first RAM region listed in the table; and 3) adjusting the "Reset handling" to "SOFT" in the MCUXpresso IDE LinkServer debugger launch configuration. When I did that, at first it seemed to work but I quickly got into a situation where when I tried to start a debug session, it would fail in various ways that made it look like the board was already busy doing something else that interfered with the debugger downloading and running our application.

I am, however, pleased to say that I stumbled on something that seems to have addressed this issue. Part of the instruction for debugging an application in RAM was to adjust the MCUXpresso launch configuration to use "SOFT" for "Reset handling", which I did, as mentioned above. However, on the same dialog box there is a button that says "Reset on connect". Out of the box, that button was not selected. On the idea that the board may already be doing something when I try to connect the debugger, I selected this box and the instabilities went away. I am now able to run and debug my application from SRAM_OC.

I do have a colleague who is still having this difficulty. He is using the Linux version of MCUXpresso. I am trying to assist him through his difficulties by comparing configuration files with him. So far he seems to be doing the same things I am (he even copied my .cproject file into his project and verified that our lauch configuration files were substantially the same), but he continues to have this difficulty.

The good news is that this seems to have addressed my issue. The bad news is that it does not seem to have addressed it for my colleague, at least not yet. The other disturbing news is that nowhere in the documentation have I found anything that says I have to have "Reset on connect" selected when setting up to link my application to RAM. I only did it as a semi-educated guess. That could be made clearer.

I would ask that we leave this ticket open until my colleague has addressed his difficulty.

[GlennSikkema]

What does "assumed answered" mean? I have not received a reply yet...