This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM2634: Under what criteria, does the UART fallback boot-mode revert to UART?

Part Number: AM2634

Tool/software:

This question is in regards to the Supported boot modes table. Is there a flow-chart or a specific definition of the conditions required to declare the CAN secondary SBL failure? This is statement in the TRM as "If Secondary SBL also fails then boot from external host via UART interface.". Is a CAN-protocol timeout (no CAN activity) included in this switch to the UART interface?

Thanks,

Jim

  • Hi Jim,

    Struggling to follow the exact question here but since you mention the CAN protocol timeout, I don't see a way that'd trigger a switch as the ROM boot loader modes available don't include a CAN boot loader with UART fallback option.

    Are you using the CAN bootloader as a secondary boot loader here? If so the fallback details would come from SDK documentation, not TRM. The TRM is only going to cover hardware boot loaders, namely the ROM boot loader.

    Best Regards,

    Ralph Jacobi

  • I am trying to understand the different QSPI boot-modes. We will be using the 4-parallel-data-line external flash, so there are 2 QSPI(4S) boot-modes: 

    QSPI (4S) - Quad Read Mode

    QSPI (4S) - Quad Read UART Fallback Mode

    The difference between these 2 modes is the fallback-mode has this sentence "If Secondary SBL also fails then boot from external host via UART interface.". What isn't clear, is what condition(s) would cause the secondary SBL to fail, or is it up to me to code those failure conditions?

    Thanks,

    Jim

  • Hi Jim,

    Ahh okay now I understand the main question.

    This is covered in the Redundant Boot Support chapter in the TRM but for quickness I'll post the details here:

    Redundant boot is supported on QSPI flash boot modes. ROM tries to boot SBL at 0x0 address and if it fails to boot, then ROM tries to boot from 0xF0000 location. Following are the failures which can lead to redundant boot:

    1. Certificate corruption, ex. Image size, hash of the image, extension IDs, signature etc.
    2. Image corruption, ex. bit corruption, byte corruption due to aging of the flash, external interferences etc.

    Best Regards,

    Ralph Jacobi

  • Thanks.