• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 136 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM2431: Timing of Bootloader_socResetWorkaround() Execution After Pinmux_init()

Kanno Itsuki
Prodigy 70 points

Part Number: AM2431

SDK Version: mcu_plus_sdk_am243x_08_03_00_18

To comply with the watchdog timer (WDT) feeding constraints, I would like to confirm whether it is acceptable to execute Bootloader_socResetWorkaround() after the following initialization functions in System_init():

Dpl_init()
PowerClock_init()
Pinmux_init()

The intention is to perform Pinmux_init() first, then feed the WDT once, and after that, trigger a warm reset by calling Bootloader_socResetWorkaround().

In the original SDK flow, Bootloader_socResetWorkaround() is called after Bootloader_profileReset() in the main() function. I would like to know if changing the timing to execute it later (after Pinmux_init() and WDT feeding) could cause any issues with SoC state or initialization consistency.
Are there any TI-recommended practices or precautions regarding this change?

  • 0
    TI__Guru 51898 points

    Hello Kanno,

    I am looking at your queries and you may expect reply in one or two days .

    Regards,

    Anil.

  • 0 in reply to Swargam Anil
    TI__Guru 51898 points

    Hello Kanno,

    Our recommendation is to call the Bootloader_socResetWorkaround() before System_init() (Dpl_init() , PowerClock_init(),Pinmux_init()).

    If you invoke this API after System_init(), the API internally performs a Warm Reset of the SoC. In this case, since System_init() already took x microseconds before the reset, the same initialization sequence has to run again after reset — effectively doubling that setup time.

    Additionally, if your SBL is accessing CPSW registers, make sure to perform the Warm Reset first, and then call the System_init().

    As per TI’s recommended flow, the SoC reset should occur immediately, without running System_init() first. This approach helps you save the redundant initialization time.

    Regards,

    Anil.

  • 0 in reply to Swargam Anil
    Prodigy 70 points

    Hello Anil,

    Thank you for your detailed explanation.

    I also aim to minimize redundant processing and reduce boot time as much as possible. However, due to constraints from the WDT IC, we must send a signal via GPIO within 450ms. Unfortunately, this becomes impossible if we perform Bootloader_socResetWorkaround() too early, as it causes a warm reset and delays GPIO signaling.

    Therefore, even though it introduces some redundancy, we are forced to feed the WDT via GPIO before calling Bootloader_socResetWorkaround().

    Currently, our flow is as follows:

    Bootloader_profileReset()
Bootloader_socIsMCUResetIsoEnabled()
Bootloader_socResetWorkaround()
Bootloader_socWaitForFWBoot()
Bootloader_socOpenFirewalls()
System_init()

    We are considering changing it to:

    Bootloader_profileReset()
Bootloader_socWaitForFWBoot()
Bootloader_socOpenFirewalls()
System_init()
Bootloader_socIsMCUResetIsoEnabled()
Bootloader_socResetWorkaround()

    Since CPSW register access is not involved at this stage, we believe this change should not cause any issues. Could you please confirm if this understanding is correct?

    Best regards,
    KANNO, Itsuki

  • 0 in reply to Kanno Itsuki
    TI__Guru 51898 points

    Hello Kanno,

    Kanno Itsuki said:
    Bootloader_profileReset() Bootloader_socWaitForFWBoot() Bootloader_socOpenFirewalls() System_init() Bootloader_socIsMCUResetIsoEnabled() Bootloader_socResetWorkaround()
    If you are using any MCU domain peripherals, then the above sequence will be a problem.
    However, if you are not using the MCU domain peripherals, then there is no problem.
    If you look at the inside of this check, Bootloader_socIsMCUResetIsoEnabled, we are enabling the MCU PLLs.
    So, before you set the clock frequencies to MCU peripherals, you may see an issue.
    If you are not using any MCU domain peripherals and MCU pins, then there is no issue.
    Please do testing at your side as well.
    Our suggestion is that you need to stick with the TI SBL flow, but this approach is specific to your requirement.
    TI has not verified this approach.
    Regards,
    Anil.

  • 0 in reply to Swargam Anil
    Prodigy 70 points

    Hello Anil,

    Thank you for the clarification.

    In our development, we do not use any MCU domain peripherals or pins. We only use Main domain cores and peripherals. Therefore, from a theoretical standpoint, I understand that the proposed change should not cause any issues.
    We will still perform testing on our side to confirm the behavior.

    Thank you very much for your support.

    Best regards,
    KANNO, Itsuki

  • 0 in reply to Kanno Itsuki
    TI__Guru 51898 points

    Hello KANNO, Itsuki,

    Once you complete the testing, please share the Test Results with us.

    Regards,

    Anil.