imx rt FlexRAM, do I really "need" to define OC ram?

[bp1979]

We are using the imx rt 1024 processor, which has FlexRAM where application code can configure the memory to our needs.

What I would prefer, is a small amount of ITC, and the rest DTC. I can't see any advantage of also specifying OC.

The application note for FlexRAM states

So here, it states we should reserve 64 KB for ROM code.

In the reference manual, I find this bit

So lets say, we are 100% certain we don't need HAP API once we've jumped to our own software, does that mean we can safely get rid of OC sram all together? Because then I will configure 32K for ITC (which is more than enough for the small amount we need to run in ITC), and assign the remaining 224KB to DTC.

Am I going to get in trouble with this configuration? I am a bit concerned that the AN states that 64K must be reserved for OC...

[mjbcswitzerland · Accepted solution]

Hi

See https://www.utasker.com/iMX/RT1024.html where you can try the uTasker loader for the i.MX RT 1024, which automatically configures the amount of ITC required for the application to run in and sets all remaining as DTC (including allowing AES256 IP and clone protection) - and thus zero OCRAM.
Documents and video guides are at https://www.utasker.com/iMX/developers.html including showing how to run and SDK example for optimal speed [i.e. code in ITC and data in DTC with zero wait states] or on-the-fly XiP with almost zero effort, as well as detailed analysis of the techniques.

See also the RAM section of https://www.utasker.com/docs/iMX/i.MX_RT_1024_uTasker.pdf (chapter 17) for more details about FlexRAM.

To the question - OCRAM is not needed but there are some complications (solved in the uTasker loader solution):
- the BOOT ROM needs OCRAM to boot from, but the problem is that the configured FlexRAM configuration is not (reliably) returned to default by a SW (or WDOG) reset and so it can happen that the BOOT ROM fails and the processor hangs (requiring a power cycle to recover)
- this is solved by using a routine to restore the default flex RAM configuration during the SW reset (or WDOG interrupt) process which ensures reliability.
- since there are other causes of hanging in the ROM loader (eg. if a part of the internal QSPI Flash is being deleted and a wdog, HW or SW reset occurs the ROM LOADER may switch to its ISP mode [since the QSPI flash is still busy] and thus require a power cycle to recover).
- to address requirements for 100% reliability the uTasker project has also developed a very low cost power cycling watchdog method in HW which adds various component savings (and practicality) on top which is detailed here: https://www.utasker.com/docs/iMX/uTasker_iMX_WDOG.pdf

Regards

Mark

P.S. We have never used fuse settings to define the FlexRAM since it is a one-shot process and so can cause other issues and lack of flexibility. I don't think that the fuse setting supports zero OCRAM due to the BOOT ROM requirement, which would presumably brick a device if it were possible.
The SW technique has however been used successfully for some years in a varied range of industrial products (although I prefer to also have the external recover circuit for mission critical systems due to other reasons too).


For our discounted i.MX and Kinetis stock availability see https://www.utasker.com/Shop/semi.html

[bp1979]

Wauw! What a super clear answer, thank you very much! I have seen links of uTasker before, but never really played around with it. I will check it out... one day... if time is not working against me for once ;-).

I am also using the "software approach" of configuring FlexRAM, so I will give it a spin, and see if OC=0 works without too many surprises on my side too. I also don't dare to burn fuses for FlexRAM, nor do I need to.

Thanks again for also explaining some of the background and rationales, it helps a lot.