Where can I find default settings for boot clock fuses and how to make sure the GPIOs are in a safe state after XTAL fails?

[mitterha]

Hello,

this table shows different core clock frequencies for different fuse settings

so BOOT_FREQ is setting CORE to 396 MHz or 528 MHz and the Bus frequency always to 132 MHz.

Then there are the divider LPB_BOOT fuses

My questions are:

• Is there somewhere a table for RT1020 which specifies which fuses are burned by default and which are not? I want to know which clock frequencies the Boot ROM is setting.
• Does LPB_BOOT divide core and bus, only the core frequency or does it set the divider from core clock to bus clock (e.g. 132 MHz bus clock is not possible for 396 MHz core clock because that would need LPB_BOOT div by 3)?
• Does bus clock mean ipg_clk_root?
• Which clock source will be used for the first start after power was removed e.g. will it use the external 24 MHz XTAL from the beginning or will it use the internal RC oscillator and switch to XTAL as soon as the XTAL is stable? I can't find information about that in the reference manual.

Kind regards,

Stefan

[jeremyzhou]

Hi Stefan Mitterhauser,

Thank you for your interest in NXP Semiconductor products and
for the opportunity to serve you.
1) Is there somewhere a table for RT1020 which specifies which fuses are burned by default and which are not? I want to know which clock frequencies the Boot ROM is setting.
-- The default value of 0x460~0x470 area is 0.
2) Does the bus clock mean ipg_clk_root?
-- No, I don't think so, as the below figure shows.

3) Which clock source will be used for the first start after power was removed e.g. will it use the external 24 MHz XTAL from the beginning or will it use the internal RC oscillator and switch to XTAL as soon as the XTAL is stable? I can't find information about that in the reference manual.
-- I'm not very clear with the question, in my opinion, the MCU won't run yet without the power supplies.

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

[mitterha]

Hi Jeremy,

thank you for your answer!

2) The picture shows a lot of dividers. Which of these dividers will be affected by the LPB_BOOT fuses?

3) I mean after I connect my board to a power supply, which clock, and at which frequency, will be used to start executing BOOT ROM code? Because I think that the BOOT ROM code will evaluate the boot clock fuses and set the clock system according to it.  Will the core boot with an internal RC oscillator or will it use the external XTAL (24 MHz or 32 kHz). If it uses the external XTAL how does it make sure that the XTAL oscillator is up and running stable?

Kind regards,

Stefan

[jeremyzhou]

Hi Stefan Mitterhauser,

Thanks for your reply.
1) The picture shows a lot of dividers. Which of these dividers will be affected by the LPB_BOOT fuses?
-- Actually, we don't know.
2) In my opinion, the MCU would boot up with internal RC oscillator: 40 MHz.

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

[mitterha]

Hello jeremyzhou‌,

do you have any more information?

Kind regards,

Stefan

[mitterha]

Hello jeremy,

I have got an answer to a different support ticket question today which gives some information to the boot too:

The lower-power RC oscillator module is available on-chip as a possible alternative to the
24 MHz crystal oscillator after a successful power-up sequence. And the RC oscillator canpt for boot.
So RT can't normally work if 24 MHz crystal oscillator failed. 

Could you please check with the design team the following:

• Which dividers will be set with the fuse LPB_BOOT?
• For security reasons it is important to place the processor in a known safe state (reset state) after the 24 MHz XTAL fails.
  - How can we make sure that the GPIOs will be set in reset state (without POR) in this case? A watchdog reset is considered as cold which will not reset IOMUXC.
  - Will the processor automatically switch from 24 MHz XTAL to internal 24 MHz RCOSC if XTAL fails as it does for the 32 kHz XTAL and is it possible to detect it?
• Is there somewhere more documentation to the internal 24 MHz RCOSC? The RCOSC gets mentioned in reference and electrical characterisitcs manual and MCUXpresso Config Tools generate code for it in clock_config.c but I can't find any documentation.

Kind regards,

Stefan

[jeremyzhou · Accepted solution]

Hi Stefan Mitterhauser,

Thanks for your reply.
1) Which dividers will be set with the fuse LPB_BOOT?
-- It's about the details of the IP module, so it's confidential to the clients, in addition, it doesn't interfere clients to develop.
2) Will the processor automatically switch from 24 MHz XTAL to internal 24 MHz RCOSC if XTAL fails as it does for the 32 kHz XTAL and is it possible to detect it?
-- No, I'm afraid not.
3) How can we make sure that the GPIOs will be set in the reset state (without POR) in this case? A watchdog reset is considered as cold which will not reset IOMUXC.
-- When the clock source lost suddenly, the code will crash.
4) Which clock source will be used for the first start after power was removed e.g. will it use the external 24 MHz XTAL from the beginning or will it use the internal RC oscillator and switch to XTAL as soon as the XTAL is stable?
-- I'm a bit confused, how the MCU to boot up after the power remove.

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

[mitterha]

Hello Jeremy,

thank you for your answers.

4) After enabling power again which clock source will be used for booting? Will the external 24 MHz XTAL be stable as soon as power is connected to the device or will it first use the internal RC oscillator and switch to XTAL later.

Kind regards,

Stefan

[jeremyzhou]

Hi Stefan Mitterhauser,

Thanks for your reply.
1) After enabling power again which clock source will be used for booting? Will the external 24 MHz XTAL be stable as soon as power is connected to the device or will it first use the internal RC oscillator and switch to XTAL later.
-- The external 24 MHz XTAL will be stable as soon as power is connected to the device.

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

[mitterha]

Thank you Jeremy!

[mjbcswitzerland]

Stefan

Don't forget that the ROM LOADER will be setting things up and in case of double it is best to set a break point on entry into your code and look at register values so that you can see exactly which settings are used.

You can also read the eFUSE settings from their shadow registers in the OCOTP controller. This is what I read (from a command in the code) on an i.MX RT 1021 which hasn't had any fuse settings changed)

eFUSEs
======
LOCK
 0x40128003
CFG
 0x65f824a4
 0x1b2119d2
 0x50000004
 0x00420002
 0x00000000
 0x00000000
 0x00000000
MEM
 0x00000000
 0x00009400
 0x000000f3
 0x00000000
 0x00000000
ANALOG
 0x00000000
 0x5294b75f
 0x00000000
SRK
 0x00000000
 0x00000000
 0x00000000
 0x00000000
 0x00000000
 0x00000000
 0x00000000
 0x00000000
SJC
 0x00000000
 0x00000000
MAC
 0x00000000
 0x00000000
GP
 0x00000000
 0x00000000
 0x00000000
SW GP
 0x00000000
 0x00000000
 0x00000000
 0x00000000
 0x00000000
MISC
 0x00000040
 0x00000000
REVOKE
 0x00000000

You can also read the eFUSE values with the NXP MCU Boot Utility tool.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[mitterha]

Hello Mark,

thank you for sharing your results!

How do the values read from the shadow registers correlate with the fusemap? Is the offset shown in the ocotp memory map:

the address row of the fuse map?

Kind regards,

Stefan

[mjbcswitzerland]

Stefan

The register offsets are the same as the eFUSE offsets (note that Beware: I updated the output in my previous post because I had made a mistake there.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[mitterha]

Thank you very much mark!

[mjbcswitzerland]

Stefan

eFUSES are almost all 0 in the shipped state. See section 8.4.1. for a table with the shied state:

Any eFUSEs shipped in '1' state cannot be changed since burning a fuse (setting to '1') is not reversible.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[mitterha]

Hello Mark,

thank you again! You are right that table shows most of the eFuses for Boot (e.g. BOOT_FREQ is missing but this one can not be blown because that would configure the core at a frequency which not all derivates are specified for).

As you mentioned and asked in another question the state '1' cannot be changed so most of the eFuses will be not blown by default or the customer would not be able to change the settings. I still think that a table which shows the default for every eFuse in the fusemap (not for all are the shipped values shown) or a sentence like "every fuse listed here is not blown when shipped" would be nice to have so that I can be sure that the setting is correct for our use case without having to read back every fuse needed and check the value.

Kind regards,

Stefan