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,