MIMXRT1064 boot from fuses - internal QSPI flash

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MIMXRT1064 boot from fuses - internal QSPI flash

1,328 Views
ale1
Contributor II

Hi NXP

We have a problem booting our custom MIMXRT1064DVJ6A board from the internal QSPI flash. Some of the GPIO_B0_00 thru GPIO_B0_15 pins are used as inputs and 3 of them are driven high by external circuitry. Hence we try to program the BT_FUSE_SEL and set the BOOT_MODE[1:0] = 00b on GPIO_AD_B0_04 and GPIO_AD_B0_05. But the board does not boot up and in the debugger we can see that it is running the internal ROM code.

Snippet of the code we use to program the BT_FUSE_SEL:
  src_sbmr1 = SRC_GetBootModeWord1(SRC);
  src_sbmr2 = SRC_GetBootModeWord2(SRC);
  OCOTP_Init(OCOTP, CLOCK_GetFreq(kCLOCK_IpgClk));

  if ( !(SRC_SBMR2_BT_FUSE_SEL_MASK & src_sbmr2) )
  {
    OCOTP_ReloadShadowRegister(OCOTP);

    // read CFG5 at offset 0x460
    fuseValueCfg5 = OCOTP_ReadFuseShadowRegister(OCOTP, offsetof(OCOTP_Type, CFG5));
    if ( !(fuseValueCfg5 & 0x00000010) )
    {
      status = OCOTP_WriteFuseShadowRegister(OCOTP, offsetof(OCOTP_Type, CFG5), fuseValueCfg5 | 0x00000010);
      while(status)
        ;
      fuseValueCfg5 = OCOTP_ReadFuseShadowRegister(OCOTP, offsetof(OCOTP_Type, CFG5));
    }
  }


From the debugger we have read the following values:
src_sbmr1 = 0
src_sbmr2 = 0x9
fuseValueCfg5 = 0x10

Question 1: In src_sbmr2 the BT_FUSE_SEL bit is not set, but when we read the fuse shadow register at address 0x460 the BT_FUSE_SEL is set to 1. How come?
Question 2: On the boards that are not booting src_sbmr1 is 0, so the boot ROM should execute the SW image in the QSPI flash. Why is it stuck in the boot ROM?

After burning the BT_FUSE_SEL we have modified one board to BOOT_MODE[1:0] = 10b and all the GPIO_B0_00 thru GPIO_B0_15 pins are low. This board boots correctly from the QSPI flash, so the application in the flash is OK. On this board we have read the following values from the debugger:
src_sbmr1 = 0
src_sbmr2 = 0x02000009
fuseValueCfg5 = 0x10

The BOOT_MODE is reflected in src_sbmr2, but also here the value of the BT_FUSE_SEL is not.

Best regards
Arne

0 Kudos
Reply
5 Replies

1,317 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
To provide the fastest possible support, I'd highly recommend you use either
NXP-MCUBootFlasher or MCUXpresso Secure Provisioning tool to burn the BT_FUSE_SEL and BOOT_CFG bit to enable boot from the Fuses.
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.
-------------------------------------------------------------------------------

0 Kudos
Reply

1,306 Views
ale1
Contributor II

Hi

Our custom boards are flashed using a Segger J-Link Pro and we have neighter USB nor UART connection to the MCU. Hence we cannot use NXP-MCUBootFlasher or MCUXpresso Secure Provisioning tool to program the BT_FUSE_SEL.

Br

ale1

0 Kudos
Reply

1,302 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,
Thanks for your reply.
According to your testing, I think the BT_FUSE_SEL bit had already been burned, even I've no idea why SRC_SBMR2 doesn't indicate it.
BTW, I still recommend your customer to try to modify the board's hardware to support USB or UART, then he can NXP-MCUBootFlasher or MCUXpresso Secure Provisioning tool to confirm.
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.
-------------------------------------------------------------------------------

0 Kudos
Reply

1,279 Views
ale1
Contributor II

Hi NXP

The code for programming the fuse is based on the ocotp_example.c in the SDK. Do you see any problems with the code?

Is is possible to blow a fuse "half way" so that it has different value during boot and later reading with the OCOTP_ReadFuseShadowRegister function?

We will include a UART or USB connection on the next revision of the board, but we would still like to be able to program the fuses in our own code rather than using NXP-MCUBootFlasher or MCUXpresso Secure Provisioning tool

Br,

ale1

0 Kudos
Reply

1,273 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,
After double-checking, I don't think the below function code passes the right address parameter.

fuseValueCfg5 = OCOTP_ReadFuseShadowRegister(OCOTP, offsetof(OCOTP_Type, CFG5));


I'd like to suggest you use the code, which is validated by myself.

    status_t status   = kStatus_Success;
    uint32_t fuseData = 0U;

    status = OCOTP_ReadFuseShadowRegisterExt(OCOTP, (offsetof(OCOTP_Type, CFG5)-0x400)>>4, &fuseData, 1);

    if (status != kStatus_Success)
    {
        PRINTF("Could not read fuse data\r\n");
        while (1)
            ;
    }

    PRINTF("The origin value of fuse address 0x%02X is 0x%08X\r\n", offsetof(OCOTP_Type, CFG5), fuseData);

jeremyzhou_0-1638255062489.png

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

0 Kudos
Reply