AnsweredAssumed Answered

i.MX RT10xx state after boot ROM

Question asked by John Adriaan on Dec 30, 2019
Latest reply on Jan 8, 2020 by jeremyzhou
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!

Outcomes