i.MX RT10xx state after boot ROM

[johnadriaan]

Below is a description of my understanding of the i.MX RT10xx boot process, with a numbered list of discoveries/assumptions, and a lettered list of questions.
Could someone please confirm (or otherwise) the numbered assumptions, and have a go at answering the lettered questions?

ARM Cortex-M Processors

Upon power on, an ARM Cortex-M based MCU is in the following state:

• CPU clock set to some value - usually (much) less than the available maximum;
• Clocks to most peripherals gated OFF;
• On-chip RAM (in whatever format) ON;
• Interrupts from all peripherals DISABLED in the Nested Vectored Interrupt Controller (NVIC);
• Interrupt and Fault flags ON;
• Vector Table Offset Register (VTOR) pointing to ROM - usually at 0x00000000.

Its first actions are to:

• Read the initial Stack Pointer (SP) from VTOR[0x0000];
• Read the initial Program Counter (PC) from VTOR[0x0004];
• Start executing instructions.

i.MX RT10xx Processors

NXP ship boards using this range of processors with the on-chip ROM already programmed.
The ROM configures the board, then examines various switches and settings to decide what to actually boot.
The important thing here is that it has already used the ARM-defined initialisation, and the programmer has to organise to have the System Code booted independently of the above.

For simplicity, assume that my System Code resides in the NOR Flash, and that the Flash Control Block (FCB) and Image Vector Table (IVT) are correctly initialised.
The boot ROM works out what the very first System Code instruction of mine to execute is,
and jumps to it. At that instant...

Investigations show that:

1. The documentation says that the clock is at 396MHz.
2. The Interrupt and Fault flags are Enabled.
3. No NVIC interrupt is enabled.
4. VTOR is at the base of ROM.
5. SP is in OCRAM, approximately 1K from the start.
6. The OCRAM is divided as follows (i.MX RT1010):

1. ITCM is set to 32K - but 32K+1 is accessible*;
2. DTCM is set to 32K - but 32K+1 is accessible*;
3. OCRAM is set to 64K - but 128K(!)+1 is accessible*.
   

   * Note that one byte past the #K block seems to be accessible by the debugger.

Unclear is the following:

1. Are any ARM System Core Interrupts configured - especially SysTick?
2. Have any MCU peripheral clocks, other than those specified in the documentation, been gated on?
3. Which watchdogs are (still?) enabled, such that I have to refresh them?
   

   The documentation for RTWDOG(WDOG3) states:
   47.3 ... The timeout period, window mode, and clock source are all programmable but must be configured within 255 bus clocks after a reset.
   47.3.3.1 ... All watchdog control bits, timeout value, and window value are write-once after reset within 255 bus clocks.
   47.3.3.2 ... By setting CS[UPDATE] to 1 on the initial configuration of the watchdog after a reset, you can reconfigure the watchdog at any time by executing an unlock sequence.

4. Given that the Boot ROM will take more than 255 clocks, I assume it has programmed CS[UPDATE] to 1.
   What modes has it set?
5. The documentation says that OCRAM needs to have a minimum of 64K for ROM to use:

1. If my System Code isn't going to call the ROM, why?
2. If the ROM needs 64K of the OCRAM, what parts of that 64K can my System Code use?
3. Frankly, for my RT1010 I want 128K of DTCM and nothing for ITCM and OCRAM - but the docs say I can't.

With thanks for any and all input!

[jeremyzhou]

Hi  John Adriaan,

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1) Are any ARM System Core Interrupts configured - especially SysTick?
-- No.
2) Have any MCU peripheral clocks, other than those specified in the documentation, been gated on?
-- No, I'm afraid not.
3) Which watchdogs are (still?) enabled, such that I have to refresh them?
-- RTWDOG (WDOG3)
4) Given that the Boot ROM will take more than 255 clocks, I assume it has programmed CS[UPDATE] to 1. What modes has it set?
-- Note: The developer should better be aware of that the ROM code won't change the default state of the peripherals actually.
5) Does the documentation say that OCRAM needs to have a minimum of 64K for ROM to use?
-- Yes, even it supports to reconfigure the memory allocation after jumping from the ROM code, it still can't break the restriction.

Have a great day,

TIC

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

[johnadriaan]

jeremyzhou‌

Thank you for the answers to 1) through 4) above. They make sense to me, and it is nice to have confirmation.

My concern is with your answer to 5) above:

1. Are you only saying "Leave 64K assigned to OCRAM for use after Reset"?
2. Or are you also saying "Leave 64K assigned to OCRAM, and do not use any part of that 64K since the Boot ROM needs it for its own".

[jeremyzhou · Accepted solution]

Hi  John Adriaan,

I mean that you should keep the OCRAM equal or exceed the 64 KB all the time.

Hope this is clear.

Have a great day,

TIC

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