• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 223 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.

AM2612-Q1: boot from flash

Jenney Ni
Intellectual 2510 points

Part Number: AM2612-Q1
Other Parts Discussed in Thread: LP-AM261

Hi all,

The revision of AM261-LP board as below:

customer used the watchdog to warmrst the board which boot by flash mode. But the board cannot boot from flash. customer need use the coldrst(like power on) which can boot board from flash. 

Also customer found the OSPI0_RESET_OUT0 keep low. Customer force this pin high, everything is ok.

Regards,

Jenney

  • 0
    TI__Expert 4650 points

    Hi Jenney,

    Apologies for the delay!

    Could you please tell me which Revision of LP-AM261x are you using?

    Jenney Ni said:
    customer used the watchdog to warmrst the board which boot by flash mode. But the board cannot boot from flash. customer need use the coldrst(like power on) which can boot board from flash. 

    Also, could you please help me find the BOOTMODE switch level SOP[3:0].?

    Jenney Ni said:
    Also customer found the OSPI0_RESET_OUT0 keep low. Customer force this pin high, everything is ok.

    This is due to the existing AM261x errata i2479 - OSPI Boot Issue with GPIO61 Reset Pin Configuration

    Thanks & Regards,
    Rijohn

  • 0 in reply to Rijohn Pius
    TI__Expert 4650 points

    Hi Jenney,

    Attaching below the image you shared in offline.

    • The LP-AM261 Revision A board is currently configured for xSPI / OSPI 8D boot mode via the BOOTMODE switch position (SW[3:0] = 0011).
    • This Rev A board is populated with the default Macronix flash.
    • Note that the ROM Bootloader (RBL) executes during both warm resets (WARMRSTn) and cold power-on resets (PORz).
    • Additionally, I noticed a hardware modification—an extra blue wire jump—near the RESETZ push-button buffer circuitry (U62).
      • Could you please clarify the purpose of this hardware rework?

    Thanks & Regards,
    Rijohn

  • 0 in reply to Rijohn Pius
    TI__Intellectual 2510 points

    Hi Rijohn,

    According the version of LP, you mean this phonomenon is not because of  errata i2479 - OSPI Boot Issue with GPIO61 Reset Pin Configuration, right?

    Regards,

    Jenney

  • +1 in reply to Jenney Ni
    TI__Expert 4650 points

    Hi Jenney,

    Jenney Ni said:
    According the version of LP, you mean this phonomenon is not because of  errata i2479 - OSPI Boot Issue with GPIO61 Reset Pin Configuration, right?

    To clarify: Yes, this issue is caused by Errata i2479.
    A Warm Reset (WARMRSTn) after the first cold boot will fail to boot on all three board revisions (E1, E2, and Rev A). This is because the underlying silicon bug (Errata i2479) exists in all of them.
    Once the software drives BP_BO_MUX_EN HIGH during the first run (the I2C expander configuration might be done in the SBL or the Application), any subsequent warm reset traps the Flash memory in a reset state across all boards.
    Here is the simple breakdown of how the revisions handle different resets:
    1. Initial Cold Boot Scenario (All Revisions)
    • The Setup: At power-up, the signal BP_BO_MUX_EN is pulled LOW by default. This keeps the level translator (U25) turned off.
    • The Result: Because U25 is off, the Flash memory's reset line is safely isolated and stays HIGH. The ROM Bootloader (RBL) executes, and the system boots normally.
    2. The Runtime Change (All Revisions)
    • After the system boots (i.e., the first RBL run completes), the software (SBL or Application) configures the I2C expander (U23) and drives BP_BO_MUX_EN HIGH.
    • This turns on the level translator (U25), directly connecting the MCU reset line to the Flash reset line (intended to allow the application to reset the flash).
    3. Subsequent Reset Scenarios (PORz vs. WARMRSTn)
    • On E1 and E2 Revisions:
      • Warm Reset & Internal PORz: The I2C expander (U23) reset pin is tied directly to the VSYS_3v3 power line. Because a warm reset or an internal software PORz does not cut the 3.3V power, U23 never resets. BP_BO_MUX_EN stays latched HIGH, the level translator stays on, the Errata i2479 bug drives the line LOW, and the boot fails.
    • On Rev A:
      • Warm Reset (Watchdog): The U23 reset pin is tied to the MCU's hardware PORz line. However, a Warm Reset does not trigger a full PORz. Therefore, U23 does not reset, BP_BO_MUX_EN stays latched HIGH, and the boot fails exactly like E1/E2.
      • Internal Software PORz: This succeeds on Rev A because a software-triggered PORz successfully toggles the hardware line, clearing U23 and turning off the level translator before the RBL re-executes.

    What the Ideal Hardware Design Should Have Been
    The schematic change in Rev A only helps during a software-driven PORz, but it does not fix the warm reset/watchdog boot failure.
    Ideally, to fix this issue completely in hardware, the Flash memory should have been reset using a different pin instead of GPIO61 (OSPI0_RESET_OUT0). Since the ROM bootloader misconfigures GPIO61 during startup, using any other general-purpose pin for the Flash reset would have completely isolated the Flash from this ROM bug.
    I hope this explanation makes the root cause clear! Let me know if you have any questions.
    Best regards,
    Rijohn