Hi NXP team,
I use the customer board with IMXRT1061.
And the QSPI flash is MX25L12833FM2I.
One of my test items is to repeatedly cold reboot the board 100 times.
The interval time between power off and on is 5 seconds, ensuring that there is no electric remaining in the board.
However, there may be 8 to 10 boot-up failure.
Therefore, I started sorting out the information and conducting some experiments, but the root cause has still not been localized.
More details are listed below, following the sequence from beginning to end:
According to this, is there any method or experiment I can do?
If any statement is unclear, please let me know.
Thanks a lot.
Best regards,
Doris
Hi @MCW
' I found FLEXSPI_SetFlashConfig
is completed, but there seems to be an issue between setting the FlexSPI to executing the XIP code.'
--> Would you please help check with more details? it's better to confirm this issue is from FlexSPI or NOR Flash, I suppose that the 100MHz/120MHz setting should be done from MCU FlexSPI side.
Btw, how about the falure rate for the three types of boards(Same HW/SW?)?
B.R,
Sam
Hi Sam,
Thanks for your relay.
Best regards,
Doris
'the issue is that I cannot get the signal of the 120MHz frequency when a cold boot failure occurs'. ’ At this point, the data from IMXRT1060 is still being sent to the QSPI flash cycle during the cycle with 100Mhz. To be honest, I do not know the reason for having this kind of signal after the cold reboot failure.‘ 'The fail rate was reduced from 11% to 0.4% when I changed the FCFB flash clock frequency at 120Mhz.'
-->
I'm worried that MCU doesn't actually work at 120MHz, it's better to confirm it.
BTW, how about the power voltage when issue happened both for MCU and Flash?
It's hard to say where is the root cause, but it seems to be related to the timing.
Hi @Sam_Gao ,
Sorry for the late reply.
I used the logic analyzer to confirm the frequency, which was 120 MHz.
Recently, I changed the optimization level from 'optimize for size' to 'no optimization' during compilation.
All kinds of boards booted up successfully over 1000 times.
However, the size of bin file is much larger than my flash layout.
Is there any method to apply no optimization for certain files?
Best regards,
Doris
It is better to find which step is wrong if you provide more information to me @MCW
1. If the flash is not enough, it is better to use 'optimize for size'', would you please share which kind of optimization to me? '-O0', '-Og' or '-O3'.
2. Please give me which SDK version are you using
3. By the way, would you please check the power timing during booting, especially for the power side? What is the capacitance of NVCC_PLL from your side? it is better to recommended to increase it slightly if these testing is at a lower tempeature which will changes the capacitance value.
4. Please follow the blow screenshot which from QSPI Flash MX25L12833FM2I you mentioned to try.
Hi Sam,
1. If the flash is not enough, it is better to use 'optimize for size'', would you please share which kind of optimization to me? '-O0', '-Og' or '-O3'. -> Normally, -Os. And I have tried to use -O0 for "no optimization".
2. Please give me which SDK version are you using -> In fact, we developed our project based on Zephyr 2.7.1.
3. What is the capacitance of NVCC_PLL from your side? -> I have checked it, there are the same, 0.22uF/25V and 4.7uF/10V, respectively.
Thanks for your help.
Best regards,
Doris
Hi @Sam_Gao ,
I have conducted further experiments and would like to clarify some points.
Apologies for the earlier misinformation.
Firstly, the flash clock frequency did not increase from 100MHz to 120MHz.
Secondly, even with the "compile no optimization" setting, after modifying the code and rebuilding, the cold reboot failure still persists.
As part of my debugging process, I used specific LED indicators after the flash initialization and found that the program is stuck at the point where it attempts to print the first log. After reviewing the UART-related code, I discovered that it is getting stuck in the following while loop, as the TDRE register remains at 0.
Could you please advise what could cause this behavior, where the TDRE register is consistently 0?
Thank you.
Best regards,
Doris
Hi,
From my side, I searched with the key words 'zephyr, 2.7.1, mimxrt1060' your mentioned, https://github.com/zephyrproject-rtos/zephyr/blob/zephyr-v2.7.1/boards/arm/mimxrt1060_evk/mimxrt1060...
- For LPUART_GetStatusFlags(config->base)
& LPUART_STAT_TDRE_MASK, please see below comments.
/*!
* @brief Gets LPUART status flags.
*
* This function gets all LPUART status flags. The flags are returned as the logical
* OR value of the enumerators @ref _lpuart_flags. To check for a specific status,
* compare the return value with enumerators in the @ref _lpuart_flags.
* For example, to check whether the TX is empty:
* @code
* if (kLPUART_TxDataRegEmptyFlag & LPUART_GetStatusFlags(LPUART1))
* {
* ...
* }
* @endcode
*
* @Param base LPUART peripheral base address.
* @return LPUART status flags which are ORed by the enumerators in the _lpuart_flags.
*/
uint32_t LPUART_GetStatusFlags(LPUART_Type *base);
And the definition of LPUART_STAT_TRDE
as below:
#define LPUART_STAT_TC_MASK (0x400000U)
#define LPUART_STAT_TC_SHIFT (22U)
/*! TC - Transmission Complete Flag
* 0b0..Transmitter active (sending data, a preamble, or a break).
* 0b1..Transmitter idle (transmission activity complete).
*/
#define LPUART_STAT_TC(x) (((uint32_t)(((uint32_t)(x)) << LPUART_STAT_TC_SHIFT)) & LPUART_STAT_TC_MASK)
#define LPUART_STAT_TDRE_MASK (0x800000U)
#define LPUART_STAT_TDRE_SHIFT (23U)
/*! TDRE - Transmit Data Register Empty Flag
* 0b0..Transmit FIFO level is greater than watermark.
* 0b1..Transmit FIFO level is equal or less than watermark.
*/
#define LPUART_STAT_TDRE(x) (((uint32_t)(((uint32_t)(x)) << LPUART_STAT_TDRE_SHIFT)) & LPUART_STAT_TDRE_MASK)
Hi @Sam_Gao ,
I apologize for not describing the issue clearly earlier. I would like to clarify the situation regarding the behavior of the UART module's TDRE flag after initialization.
After boot-up and initializing the UART module, the TDRE flag fails to be set to 1 successfully 5-6 times out of 100. I am trying to understand why this happens.
Could you please provide any insights or suggestions on what might be causing this issue?
Thank you for your help.
Best regards,
Doris
Hi,
I am confused again why boot-up problem is related to UART according to your point of view, it seems it boot from XIP(FlexSPI Nor Flash) not serial download.
TC - Transmission Complete Flag, TDRE - Transmit Data Register Empty Flag.
it is needed to check why TDRE is happened from application.
B.R,
Sam
Hi @Sam_Gao ,
Yes, my custom boards are boot from the nor flash. Initially, I suspected that the boot failure issue was due to incorrect flash-related settings. However, after further clarification, I found that during boot failure, the program actually gets stuck in the mcux_lpuart_poll_out function's while loop. The failure always occurs when trying to print the first line of the debug log. This leads me to wonder about the cause of TDRE being 0 after UART initialization, since the reset value of TDRE should be 1.
Additionally, I’ve been experimenting with the SDK sample code and found that disabling the clock gate for UART1-UART8 before setting the UART source clock can prevent the issue. Could you please explain why disabling the clock gate could resolves the issue?
As I mentioned earlier, I also tried introducing a 100 NOP delay before setting the source clocks for all modules, but this solution does not work consistently across all boards.
If any part of the description is unclear, please feel free to let me know. Thank you for your help.
Best regards,
Doris
' disabling the clock gate for UART1-UART8 before setting the UART source clock can prevent the issue.'
I am able to give comments, I try to understand if you can help give the source code to describe in details.
About this boot-fail case, I am still confused if the root casue is from print/UART which seems be 100% issue as your mentioned.
Hi @Sam_Gao ,
I wanted to share an update.
I added a delay time (100 NOPs) before setting the source clock for the UART.
It seems to have fixed the issue of the system getting stuck in the while loop of mcux_lpuart_pool_out during boot-up.
Attached is the code for my clock initialization process.
Thank you.
Best regards,
Doris