RT117x: preserve bits and RAM location across warm reset

[mastupristi]

Hi,

On RT1175, I need to preserve not only some bits across warm reset, but also the contents of OCRAM.

I read:

and

given the note (which indexes are 0-based), can you confirm that I can freely use registers 5 through 8 and 10 through 19, to “communicate” information over warm resets?

Instead, did the OCRAM content persist across warm resets? Does this apply to all OCRAM banks, or only some in particular?

best regards

MAx

[mastupristi]

Is there anyone out there?

I have done some tests.

I wrote GPR10, GPR11, and GPR12, before calling NVIC_SystemReset(). When restarting the FW, in the startup code, I read the same registers, and always find them 0.
Note that only bit 1 (M7_REQUEST_M7) is on in the SRC_SRSR register, not bit 0 (IPP_RESET_B_M7).

Where am I going wrong?

Another test: a FW with default settings (ITC = 256KB, DTC = 256KB, no ECC, M4 turned on but not used, so OCRAM = 1.5MB), which does not use OCRAM at all, writes pattern 0x5a in all available OCRAM (as said 1.5MB) before calling NVIC_SystemReset().
After the reboot I can check the status of OCRAM against pattern 0x5a:

0x20200000 ................
0x20204000 ................
0x20208000 ................
0x2020c000 ................
0x20210000 ................
0x20214000 ................
0x20218000 ................
0x2021c000 ................
0x20220000 ................
0x20224000 ................
0x20228000 ................
0x2022c000 ................
0x20230000 ................
0x20234000 ................
0x20238000 ................
0x2023c000 ................
0x20240000 ......XXX..X....
0x20244000 ....XXXXXXX.XXXX
0x20248000 XXXXXXXXXXXXX...
0x2024c000 ................
0x20250000 ................
0x20254000 ................
0x20258000 ................
0x2025c000 ................
0x20260000 ................
0x20264000 ................
0x20268000 ................
0x2026c000 ................
0x20270000 ................
0x20274000 ................
0x20278000 ................
0x2027c000 ................
0x20280000 ................
0x20284000 ................
0x20288000 ................
0x2028c000 ................
0x20290000 ................
0x20294000 ................
0x20298000 ................
0x2029c000 ................
0x202a0000 ................
0x202a4000 ................
0x202a8000 ................
0x202ac000 ................
0x202b0000 ................
0x202b4000 ................
0x202b8000 ................
0x202bc000 ................
0x202c0000 ................
0x202c4000 ................
0x202c8000 ................
0x202cc000 ................
0x202d0000 ................
0x202d4000 ................
0x202d8000 ................
0x202dc000 ................
0x202e0000 ................
0x202e4000 ................
0x202e8000 ................
0x202ec000 ................
0x202f0000 ................
0x202f4000 ................
0x202f8000 ................
0x202fc000 ................
0x20300000 ................
0x20304000 ................
0x20308000 ................
0x2030c000 ................
0x20310000 ................
0x20314000 ................
0x20318000 ................
0x2031c000 ................
0x20320000 ................
0x20324000 ................
0x20328000 ................
0x2032c000 ................
0x20330000 ................
0x20334000 ................
0x20338000 ................
0x2033c000 ................
0x20340000 ................
0x20344000 ................
0x20348000 ................
0x2034c000 ................
0x20350000 ................
0x20354000 ................
0x20358000 ................
0x2035c000 ................
0x20360000 ................
0x20364000 ................
0x20368000 ................
0x2036c000 ................
0x20370000 ................
0x20374000 ................
0x20378000 ................
0x2037c000 ................

the '.' represents 1KB populated with only 0xa5, while 'X' represents 1KB “dirtied” (by the ROM bootloader)
In my usage scenario, it appears that only 48KB is being used by the ROM bootloader at address 0x20240000 (OCRAM1)

The ROM bootloader is a FW, compiled from source, and it definitely has a linker script where it's indicated what and how much portion of OCRAM is used. All I need is this information

best regards

Max

[mastupristi]

NXP engineers, don't be shy.

I verified that regarding the GPR registers I had made an error in my test. They have indeed persisted.

So the question regarding OCRAM remains open, how much of it should be considered touched by ROM bootloader? 

As I have already stated, you only need to look at the ROM bootloader linker script to answer this question

regards

Max

[diego_charles]

Hi @mastupristi 

Thank you for reaching out and my  apologies for not getting back to you sooner.

Yes, the SRC_GPR registers persist  after reset, you are right. This article from a Chinese colleague shows implementation of SRC_GPR10 register. Pi Ziheng Embedded: Revealing the dual-program alternate boot design of serial NOR Flash on i.MXRT11... (please translate it to English). The GPR10 is also used by Boot ROM, so you need to be careful if you want to use SRC_GPR registers.

As your tests show, the ROM bootloader makes use of the  internal OCRAM1. The below diagram from the RT1170 Reference manual illustrates this. 

I hope this could help you and thank you very much for your patience. 

Let me know if you still have questions regarding this topic. 

Diego

[mastupristi]

Hi @diego_charles 

In the image you shared there is a note

I would need a couple of clarifications.

Can you explain the first sentence better? I mean "The RAM space occupied by ROM cannot be used as part of the boot image"

To make me understand, could you give me an example of a boot image that uses the part of the RAM used by the ROM?

Instead, the last sentence “The above OCRAM1 region must be reserved if the user application needs to call the HAB API/FlexSPI NOR API for image authentication” means that if I use the ROM API I have to reserve the area between 0x20240000 and 0x2024C000, right?

Now I would like to draw attention to one thing that is likely to cause confusion.

You say:

Yes, the SRC_GPR registers persist  after reset, you are right. This article from a Chinese colleague shows implementation of SRC_GPR10 register. Pi Ziheng Embedded: Revealing the dual-program alternate boot design of serial NOR Flash on i.MXRT11... (please translate it to English). The GPR10 is also used by Boot ROM, so you need to be careful if you want to use SRC_GPR registers.

You're referring to GPR10 because in the document you linked, it says so:

what's confusing is 0-based or 1-based indexing.

What is certain is the addresses of the registers

here are shown 1-based (GPR1 is at 0x40C04014, and GPR10 is at 0x40C04038)

There is already a lot of confusion here: in the title they are 1-based, but in the note they are 0-based. In the offset calculation they are 1-based but with a starting offset made specifically to make things right.

By programming (eg, in the SDK examples), GPRs are a 0-based array (so GPR[0] is at 0x40C04014, and GPR[9] is at 0x40C04038)

These also appear to be 0-based, by the way, the description of GPR9 matches the description of GPR10 in the link.

I think a review of the documentation may be helpful in avoiding problems and misunderstandings.

best regards

Max

[diego_charles]

Hi @mastupristi 

Thank you for your comments and effort reporting improvements to our documentation. I am currently addresing this internally. 

Diego