i.MXRT101x FlexRAM Configuration kept across software/WD reset

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MXRT101x FlexRAM Configuration kept across software/WD reset

Jump to solution
470 Views
TheUncle
Contributor III

Hello,

it seems that FlexRAM "software" configuration (i.e., done via GPR14/16/17) is retained across software and watchdog resets. I'm wondering if this is by design, because it causes some troubles in case the FlexRAM is allocated fully to TCM - no  OCRAM. This has been tested on RT1011 and RT1015 device, but I suppose it might be the same on other family devices.

It is clear that the ROM boot code requires a certain amount to OCRAM for stack and variables - 64k, as per AN12077, although this requirement "can be device dependent". This is certainly true at boot, but once user code has taken control, the OCRAM is definitely no longer used by ROM code. It is then possible to allocate the FlexRAM only to I/DTCM, which may a requirement in scenarios where the memory shall be tuned for high performances.

Allocating FlexRAM entirely to TCM via software (no fuses), with no blocks for OCRAM, works just fine - until software reset or watchdog are used. Since GPR16 contents (specifically FLEXRAM_BANK_CFG_SEL bit) is not reset by neither a software nor a watchdog reset (while it is on POR or hardware reset), the system hangs at startup in a non-recoverable way - sometimes not even inside ROM code. A POR is needed to restart the device.

This is definitely a weird behaviour, which prevent the FlexRAM to be used in full as TCM - and this might be an issue especially with smaller devices like 101x, which have four 32K banks. Probably a better implementation would be either to reset the related GPR bits also on software/watchdog reset or to let ROM code take care of reconfiguration to  allocate some OCRAM as needed.

I'm looking for a workaround - found none so far. We need to use the watchdog and software reset while using all the FlexRAM as TCM, leaving out OCRAM. Any suggestion?

Thank you in advance,

Stefano

Labels (1)
0 Kudos
1 Solution
291 Views
FelipeGarcia
NXP TechSupport
NXP TechSupport

Hi Stefano,

 

First of all, thank you for your detailed report and information provided. As you mentioned, GPR16 contents are not reset by neither a software nor a watchdog reset, this is because IOMUXC is only reset by hardware POR reset. Please check the following image from Reference Manual.

pastedImage_2.png

We previously have been asked to reconfigure GPR bit at the start of ROM code so it can allocate some OCRAM as needed. Unfortunately, we don't have GPR setting that can impact ROM function at this moment.

 

The workaround that comes to my mind is that you set the default FlexRAM settings before the reset.

 

Best regards,

Felipe

-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------

View solution in original post

0 Kudos
4 Replies
291 Views
TheUncle
Contributor III

Hello Felipe, hello Mark,

thank you for the confirmations and suggestions. I considered the option of handling tthe WD interrupt to restore the FlexRAM configuration. The fact is - as Mark pointed out - that when the system "seriously" hangs, then only an external WD can guarantee 100% a safe system recovery in case the OCRAM size has been set to zero. In such a case, the WD ISR may not be serviced, leaving the FlexRAM in a state not valid for the bootloader.

+1 for a ROM code change in future masks...

Regards,

Stefano

291 Views
mjbcswitzerland
Specialist V

Stefano

I agree with you entirely. There is quite a serious flaw in the present ROM loader that could presumably be corrected with a singe line of code....hopefully it will be done at some point in the future or in newer devices.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

0 Kudos
292 Views
FelipeGarcia
NXP TechSupport
NXP TechSupport

Hi Stefano,

 

First of all, thank you for your detailed report and information provided. As you mentioned, GPR16 contents are not reset by neither a software nor a watchdog reset, this is because IOMUXC is only reset by hardware POR reset. Please check the following image from Reference Manual.

pastedImage_2.png

We previously have been asked to reconfigure GPR bit at the start of ROM code so it can allocate some OCRAM as needed. Unfortunately, we don't have GPR setting that can impact ROM function at this moment.

 

The workaround that comes to my mind is that you set the default FlexRAM settings before the reset.

 

Best regards,

Felipe

-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------

View solution in original post

0 Kudos
291 Views
mjbcswitzerland
Specialist V

Hi

These problems have been solved in the uTasker project for i.MX RT 1010, 1015, 1020, 1050, 1060 and 1064.
Eg. for 1010 and 1015:

https://www.utasker.com/iMX/RT1010.html
https://www.utasker.com/iMX/RT1015.html

See also the following for details of FlexRAM configuration https://community.nxp.com/thread/523554 which allows optimal DTC and ITC without OCR. It also allows persistent variables to be maintained across resets and different flex RAM configuration (whereby the default is to always use only ITC for program code and remaining DTC [dynamically configured to match application sizes] for data in order to achieve fastest operation (and lowest power consumption and radiation), with the code being saved in AES256 form in external Flash).

The references allow software resets and watchdog resets to operate successfully with zero OCR applications, as well as communicating between application and boot loaders:

The concept is used in its loaders: https://community.nxp.com/thread/527844


uTasker developer's information: https://www.utasker.com/iMX/developers.html

There is also a watchdog discussion here: https://community.nxp.com/message/1286755?commentID=1286755#comment-1286755 whereby it is also concluded that the i.MX RT really needs an external HW Watchdog in mission critical systems due to the fact that its ROM loader cannot guarantee recovery!

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

0 Kudos