i.MX RT1052 - Bootloader: processor startup fails when SD-Card inserted

christianroedlach · ‎09-27-2022

Hi,

we flash our devices via Flashloader_RT1050_1.1 which works quite fine but came over a very special problem:

With some SD-Cards inserted, the processor does not boot up. The strange thing about is that if the exactly same program code is flashed via either J-Link or LPC-Link 2 (CMSIS-DAP protocol), the device starts just fine, no matter if the debugger is connected afterwards or not, or which SD-Card is inserted. But as soon as the bootloader is flashed via the Flashloader tool AND the wrong type of SD-Card is inserted, the processor does not come up any more. Without SD-Card or other types of SD-Cards, the device works just fine.

As we flash the exactly same program code, this different behaviour seems to be very strange. Do you have any clue what could lead to this problem or how to debug it?

Additional info: We boot into a QSpi NOR flash. The SD-Card is not used for boot up at all.

Thanks in advance,

Christian

christianroedlach · ‎10-04-2022

Hello again,

we digged a little deeper into our issue. As sait before, the failing bootup was not very reproducible. It is occuring randomly instead. But I think, the reason is a different behaviour between flash tool and debug tool as mentioned first. To figure out the origin, we set a pin high at the very beginning of the bootloader main function to trigger a scope. Please find the code here:

void debug_sd_card_pin_init(void)
{
gpio_pin_config_t config = {kGPIO_DigitalOutput, 1, kGPIO_NoIntmode};
IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B0_15_GPIO1_IO15, 0);
IOMUXC_SetPinConfig(IOMUXC_GPIO_AD_B0_15_GPIO1_IO15, ODE_0_Open_Drain_Disabled | DSE_7_R0 | SRE_0_Slow_Slew_Rate);
GPIO_PinInit(GPIO1, 15, &config);
GPIO_PinWrite(GPIO1, 15, 1);
}

//----------------------------------------------------------------------------
void main(void)
{
debug_sd_card_pin_init();

BOARD_ConfigMPU();
BOARD_BootClockRUN();

...

If we flash the bootloader by j-link debug tool, the measurement looks quite fine. (20221004_ch2_SDCMD_cd3_GP0_bootup_j-link.jpg)

If the exactly same file is flashed via flashloader tool, the measurement looks like picture 20221004_ch2_SDCMD_cd3_GP0_bootup_1st_functioncall.jpg .

Channel 2 (green) shows pin GPIO_SD_B1_05/USDHC2_CMD (the CMD pin used for SD-Card)

Channel 3 (red) shows pin GPIO_AD_B0_15_GPIO1_IO15

Do you have any clue what is causing this? We use the default settings in flashloader for flashing into QSPI NOR flash. (files attached)

Additional Info:

Version: Flashloader RT1050 1.1

The SD-Card was not inserted during measurements.

Thanks for your support,

kind regards,

Christian

jeremyzhou · ‎10-07-2022

Hi @christianroedlach ,
Sorry for replying late because of the National Holiday.
Firstly, I'd highly recommend you read out the images which are programmed by either flash load or Jlink, then compare them.
Lastly, I hope you can upload the schematic of your custom board.
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.
-------------------------------------------------------------------------------

christianroedlach · ‎10-10-2022

Hi @jeremyzhou,

thank you for your reply! We read out the images via flashloader tool (blhost.exe) and they differ completely. Please find the attached .zip file containing both readback files. We used following commands to extract the images:

tools\sdphost.exe -u 0x1FC9,0x0130 -- error-status

tools\sdphost.exe -u 0x1FC9,0x0130 -- write-file 0x20000000 "flashloader\ivt_flashloader.bin"

tools\sdphost.exe -u 0x1FC9,0x0130 -- jump-address 0x20000400

timeout 2

tools\blhost.exe -u 0x15A2,0x0073 -- get-property 1

tools\blhost.exe -u 0x15A2,0x0073 -- fill-memory 0x2000 0x04 0xc0000006

tools\blhost.exe -u 0x15A2,0x0073 -- configure-memory 0x09 0x2000

tools\blhost.exe -u 0x15A2,0x0073 -- read-memory 0x60000000 150000 readback_j-link2.bin

The .zip file also contains a detail of our custom board schematics.

Thanks in advance,

Christian

jeremyzhou · ‎10-10-2022

Hi，
Thanks for your reply.
Firstly, after comparing the readback_flash loader.bin and readback_j-link 2.bin, I find the application image is not the same, it's a bit weird and not a normal phenomenon.

Next, for QSPI Flash as an XIP function, to achieve the highest performance it is recommended to left
FLEXSPI_A_DQS（GPIO_SD_B1_05）pin floating and config sample clock source as 01-loopback from DQS pad mode to achieve max 133MHz Flexspi_clk.

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

christianroedlach · ‎10-11-2022

Hi @jeremyzhou,

thank you for your reply. Yes, it looks a bit weird to us as well to see the different images - maybe, they come from additional code generated by the j-link debugger. But we figured out the reason for the toggling CMD pin (GPIO_SD_B1_05 - we already tried to let this pin floating by removing the hw pullups RA300X and RA301X and that did not make any difference, except the idle level of course; the scope pictures I posted earlier actually were taken from the pin floating).

It comes definitely from the differences between 0x0 and 0xFFF (respectively 0x60000000 and 0x60000FFF), which means the code followed by the interrupt vector table at 0x1000. If we overwrite this memory region of readback_flashloader.bin with the content from readback_jlink2.bin and flash the modified readback_flashloader.bin to 0x60000000, everything works fine and GPIO_SD_B1_05 is not toggling any more.

Is there any possibility to influence the content between 0x60000000 and 0x60000FFF when creating the sb file, so that we do not have to edit the .bin file manually?

This manual procedure works for us:

tools\sdphost.exe -u 0x1FC9,0x0130 -- error-status
tools\sdphost.exe -u 0x1FC9,0x0130 -- write-file 0x20000000 "flashloader\ivt_flashloader.bin"
tools\sdphost.exe -u 0x1FC9,0x0130 -- jump-address 0x20000400
timeout 2
tools\blhost.exe -u 0x15A2,0x0073 -- get-property 1
tools\blhost.exe -u 0x15A2,0x0073 -- fill-memory 0x2000 0x04 0xc0000006
tools\blhost.exe -u 0x15A2,0x0073 -- configure-memory 0x09 0x2000
tools\blhost.exe -u 0x15A2,0x0073 -- flash-erase-region 0x60000000 0x30000

flash edited binary:
tools\blhost.exe -u 0x15A2,0x0073 -- write-memory 0x60000000 .\bin\iMXRT1050_Bootloader_test.bin

Please find configuration of the .bd file to create the .sb file attached.

Thanks in advance,

Christian

jeremyzhou · ‎10-11-2022

Hi @christianroedlach ，
Thanks for your reply.
1) The IDEA can generate the executable file BIN file after compiling the demo project, please compare it with the readback_flash loader.bin and readback_j-link 2.bin, it can help you to figure out the image difference.

2) Whether you mean the replace the section from 0 to 0xfff of the readback_flash loader.bin by the related section in the readback_j-link 2.bin, then program the rewrite bin to the QSPI and MCU can boot up from it, meanwhile the issue just disappeared.
3) I'd like to suggest you use the tool instead of inputting the command manually, to check whether can get rid of the issue.
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.
------------------------------------------------------------------------------

jeremyzhou · ‎09-27-2022

Hi @christianroedlach ,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
Actually, I'm not very clear with your question, whether you mean the boot-up is affected by the inserted SD-card if the bootable image is programmed by the flashloader, however, the problem doesn't happen if using the debug tool to program it, is my understanding right?
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.
-------------------------------------------------------------------------------

christianroedlach · ‎10-03-2022

Hi TIC,

thank you for your your comment. Yes, your understanding was right and this behaviour was reproducible first. But now, it looks like that it might have been a strange coincidence. The problem might be caused by a combination of powering up the sd-card and interfere with the processor pins during start up. We have to research deeper to figure out the cause of the problem.

Kind regards,

Christian