DAPLink cannot connect to iMXRT1011 with remapped FlexRAM

[benedek_kupper]

I have an EVKMIMXRT1010 board with a project with the following modifications, which remaps FlexRAM memory to use DTCM only:

in startup_mimxrt1011.cpp:

// remap flexram to all DTCM
IOMUXC_GPR->GPR17 = 0xaa;
IOMUXC_GPR->GPR16 = (IOMUXC_GPR->GPR16 & (~0x1)) | 0x4;
IOMUXC_GPR->GPR14 = IOMUXC_GPR_GPR14_CM7_CFGDTCMSZ(0x8);

// set stack pointer after remap
__asm volatile ("MSR msp, %0" : : "r" (&_vStackTop) : );

in fsl_flexspi_nor_boot.h:

#define IMAGE_ENTRY_ADDRESS ((uint32_t)&ResetISR)

I can flash and debug this project in MCUXpresso IDE, but only if the previously flashed image didn't contain these modifications (so the FlexRAM is in the default layout). I cannot however reconnect to the core with DAPLink, it cannot find the target when its FlexRAM is remapped. So what I'm forced to do is to power cycle the MCU and force it to serial bootloader mode, flash a non-remapped image on it, power cycle again to boot from external flash, and flash my real project image.

There has to be a way to get this fixed, what do I need to change on my setup to be able to directly reflash a FlexRAM remapped image with DAPLink Server?

[kerryzhou]

Hi benedek_kupper

    Except modify the startup_mimxrt1011, you also need to add the .scp, give you an example in the attachment.

  Then in your Linkserver debugger, please also add it:

Beside this, the MPU configuration code also need to modify the related OCRAM, ITCM and DTCM size.

When you find your debugger can't be connected, you can enter the serial download mode, then erase all the external memory.

Then you can connect it again.

Wish it helps you!
If you still have questions about it, please kindly let me know!
Best Regards,
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.
-----------------------------------------------------------------------------

[benedek_kupper]

This doesn't work in general, since this connect script already reports that it cannot connect to the target, when it starts. So the solution must be done somewhere else.

[kerryzhou]

Hi @benedek_kupper ,

   What's the debugger you are using? the script is used for the CMSIS DAP in the MCUXPresso.

   I have tried it in the RT1050/RT1060/rt1020.

  Please tell me your debugger, do you also check the application note:

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

 Now, you just want to use all the flexRAM as DTCM, ITCM and OCRAM all is 0, right?

Please confirm the questions, then I will find time to help you to test it.

Wish it helps you!
If you still have questions about it, please kindly let me know!
Best Regards,
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.
-----------------------------------------------------------------------------

[benedek_kupper]

We're currently using Particle Debugger with our own hardware, but the same phenomenon occurs on EVKMIMXRT1010 boards' onboard debugger. We're using MCUXpresso IDE and LinkServer debugging.

That is correct, we need all available RAM for data purpose, that's why we allocate all of it to DTCM.

Thanks for looking into this, we're looking forward to your conclusions.

[kerryzhou]

Hi benedek_kupper,

   My colleague already write the related document:

https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/Reallocating-the-FlexRAM/ta-p/1117649

You can refer to it, whether you do all the related items on your side.

Please check this document at first, if you still have issues, just kindly let me know.

Wish it helps you!
If you still have questions about it, please kindly let me know!
Best Regards,
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.
-----------------------------------------------------------------------------

[benedek_kupper]

Yes I've used that document to do the remapping (the second time at least, the first time I had to figure it out myself). In fact everything is running well on the target, the only problem is with connecting to the core with the debugger afterwards.

[kerryzhou]

Hi benedek_kupper，

  Do you mean, even the MIMXRT1010-EVK board with the CMSIS DAP also have the debug issues, even you already modify the .scp?

  If yes, please share with me your MCUXpresso test project, then I will help you to test it.

  Please also give me your modified .scp file, I need to check it.

Best Regards,
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.
-----------------------------------------------------------------------------

[benedek_kupper]

Here's an example project, to which I imported all FlexRAM related changes we have made. The zip also contains the RT1010_reconnect.scp script, that sets the same FlexRAM configuration, but fails to attach even before that.

[kerryzhou · Accepted solution]

Hi benedek_kupper,

  Seems you didn't read the application note:

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

OCRAM at least leave 64KB, used for the ROM.

So you can't disable the OCRAM, you can see in the table, your configuration is not supported.

Best Regards,
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.
-----------------------------------------------------------------------------

[benedek_kupper]

This is most unfortunate. Do you by any chance know why OCRAM is preferred over DTCM for the ROM code? My understanding is that DTCM provides faster access, while I'm not aware of any benefit for using OCRAM.

[mjbcswitzerland]

This is the restriction that I noted in my two posts made a week ago.
Also I repeat that I believe that this is a short sight in the ROM loader and I agree that OCR is not useful in most use cases.
The restriction can be worked around (also as detailed) and also debugging is possible (also explained).
It is also not restricted to i.MX RT 1011 but is true for all i.MX RT parts, but the i.MX RT 1011 is the hardest hit due to its limited number of FlexRAM banks.

Regards

Mark

[mjbcswitzerland]

Hi

If your only real problem is connecting to the debugger you could probably add the same technique that the uTasker project uses - see page 17 of https://www.utasker.com/docs/iMX/MCUXpresso.pdf "What to do when things go Horribly Wrong". The MCUXpresso debugger is rather sensitive and cannot handle various situations (plus the ROM loader doesn't handle some things that the application may have changed that cases it to the fail) so that technique is built into the loader to ensure that there is recovery and attachment capability in all circumstances.
Basically use a (hopefully) free input to allow your startup code to spin on its WAIT state before any initialisations are made that case problems.
- Set this input to the WAIT state and power cycle the board
- Now connect the debugger which will find the code spinning
- Now remove the inputs wait state and the code can continue normally (with the debugger connected)

That may be all that is needed (to solve debugging problems) but you probably still have an issue that if your code crashes it can't restart, even if there is a watchdog in operation (in mission critical systems an external watchdog controlling the power cycle is the only really fail-safe solution for the i.MX RT due to its ROM loader issues). A workaround for most products that are not super critical is to use the watchdog timer's interrupt capability to reset the RAM configuration just before the reset occurs so that the ROM loader can subsequently restart.

Regards

Mark
uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training or product development requirements

[benedek_kupper]

On our own HW samples we don't really have the luxury of adding a pin just to control this behavior. One solution I've been using is put a debug variable that the ResetISR loops on until I change it with the debugger, with that trick I only need to power cycle the MCU between debugging sessions. (So the same logic as with the pin, but using the IDE only.)

[mjbcswitzerland]

Hi

Yes, there are many ways to control a start-up delay but it is this time that is important (before changing FlexRAM settings) so that the debugger can 'grab' the processor.
I can also do it with an application command that leaves a message in a RAM mailbox to the loader that then adds such a delay in case there is no input to wait on.

Regards

Mark

[mjbcswitzerland]

Hi

Software resets and watchdog resets maintain the FlexRAM settings and the BOOT LOADER will fail if you have programmed OCR size to 0 - this may be the general issue that you have.

In my opinon it is an 'error' in the BOOT ROM because it also caused complications in the uTasker project, which dynamically allocates the ITC / DTC at run time and tends not to use OCR. This could be worked around by forcing the default FlexRAM configuration immediately after every reset and also during watchdog and software reset handling.

I believe that it is 'illegal' to set only DTC in the eFUSEs because that would/may cause ROM LOADER failure and so a bricked board (therefore I wouldn't try it).

Take a look at the uTasker project since it may solve your issues and allows code compatibility between the 1011 and other parts (1020..1064), as well as chip simulation and has dynamic FlexRAM allocations (hopefully) all solved in its loader concept.

i.MX RT 1011:
- https://www.utasker.com/iMX/RT1010.html

Boot Loader concept flow chart: https://www.utasker.com/docs/iMX/Loader.pdf and usage reference https://www.utasker.com/docs/iMX/uTaskerLoader_TestDrive.pdf
Serial Loader features: https://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf
Building the loader with MCUXpress: https://www.utasker.com/docs/iMX/MCUXpresso.pdf (and video guide https://youtu.be/p_eUGo6GypY ) - the guide document explains how to use with any application (eg. SDK) and to enabling its operation with On-The-Fly decryption in 5 minutes
Building the loader with IAR: https://www.utasker.com/docs/iMX/IAR.pdf (and video guide https://youtu.be/XPCwVndP99s )
Building the loader with VisualStudio and GCC: https://www.utasker.com/docs/iMX/GCC.pdf (and video guide https://youtu.be/0UzLLSXABK8 )

Regards

Mark
uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training or product development requirements