• State
  • Replies 9 replies
  • Subscribers 98 subscribers
  • Views 150 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM5708: AM5708 reset sequence

Sadaharu Kanda
Prodigy 20 points

Part Number: AM5708

I am currently developing a system that uses the AM5708, and I would like to ask about the reset sequence.

Regarding the resetn/porz timing requirements described in Section 5.10.3 Power Supply Sequences of the AM5708 Data Sheet, footnote (7) contains the following description:

(7) porz must remain asserted low until all of the following

– All device supply rails reach stable operational levels.

– xi_osc0 is stable and at a valid frequency.

– A minimum of 12P after both of the above conditions are met, where P = 1 / (SYS_CLK1/610), units in ns.

resetn must be high prior to, or rise simultaneous with, porz but not before its power supply, vddshv3, rising.

Our system requires that, after the PMIC powers up the AM5708, the device remain in the reset state until an external MCU deassert AM5708’s reset signal.

Initially, we planned the following sequence: after the PMIC powers up and porz is deasserted, resetn would remain asserted, and then be deasserted based on a start command from the MCU.

However, footnote (7) creates a conflict with this approach.

Therefore, I would like to clarify the following points:

– Why is it not permissible to deassert porz while keeping resetn asserted (low)?

– Assuming that all conditions in footnote (7) are satisfied and porz is kept high thereafter, are there any restrictions on asserting or deasserting resetn while porz remains constantly high?

– Our requirement—keeping the device in reset until an MCU issues a start command—seems relatively common. Does TI offer any recommended circuit approach for this type of design?

Thanks.

S.Kanda

  • 0
    TI__Guru 54615 points

    Please refer to the device errata document (Link).  i862 describes the initial problem with asserting RESETN.  However - this issue was resolved in later silicon.  That errata item also refers to i727 and i729, both are related to warm reset impact on DDR.  There are work arounds for these two items.  If your system can account for these items, the warm reset could be used.

  • 0 in reply to Robert Eschler
    Prodigy 20 points

    Hi. Robert,

    Thank you for your reply.
    We have already completed the prototype and are currently in the debugging phase.
    Since many of the Errata you pointed out have not been implemented, we plan to revise the circuitry, but we first want to determine whether the issues we are currently seeing are caused by i727 and i729.

    I would like to ask the following:

    • My understanding is that the fundamental issue in i727 and i729 is the following:
      “Because asserting a Warm Reset cannot place the DRAM controller into a reset state even on SR2.0 and SR2.1 silicon, the discussion centers on what method should be used to properly reset the DRAM controller.”
      Is this understanding correct?

    • As for the phenomena described in Errata i727 and i729:
      If no hang‑up occurs at the moment of returning from a Warm Reset, can we expect the system to operate normally afterward?

    Thank you.

    S.Kanda

  • 0 in reply to Sadaharu Kanda
    TI__Guru 54615 points

    Based on my understanding - yes to both.

    What issues are you facing?  Is the processor not booting after a warm reset is issued?

  • 0 in reply to Sadaharu Kanda
    Prodigy 20 points

    Our system captures video from a USB 3.0–connected camera via UVC, performs object recognition on the CPU, and outputs the results via HDMI.
    ・The issue is essentially a hang-up, and we are unable to access the console via UART when it occurs.
    ・It occurs in about 1–2 out of 10 units after several hours of operation, most frequently after 5–6 hours.
    ・No noise has been observed on the power supply or reset signals.
    ・After adjusting the image frame rate, the issue is less likely when the CPU load is around 90–70%, while it tends to occur more frequently under medium load of around 50–30%.
    ・When the system hangs, HDMI output is still available, indicating that the frame buffer remains accessible. This has also been confirmed through DDR memory signal waveforms.

  • 0 in reply to Sadaharu Kanda
    TI__Guru 54615 points

    I would not expect the initial issue to be related to power-on reset - simply due to system working for several hours.  Are you trying to recover from the crash and having issues, or are just trying to determine cause of the crash - and trying to rule out power-on reset?

  • 0 in reply to Robert Eschler
    Prodigy 20 points

    Our intention is to identify the root cause of the crash, and we would like to rule out the possibility of a power‑on reset being involved.

  • 0 in reply to Sadaharu Kanda
    TI__Guru 54615 points

    I don't think the issues you are seeing are related to errata items.  You could be able to verify by manually triggering a PORz (and not using RESETn) to reset the processor.  This avoids all errata times which are connected with RESETn. If issue is still present, indicates cause is elsewhere.

  • 0 in reply to Robert Eschler
    Prodigy 20 points

    We have been conducting this trial since last weekend.

    Currently, we are running experiments on eight units, and three of them have been modified to suppress RESETn-based resets and use only the PORz assertion for resetting. Over three days (about 72 hours), the stall occurred on only one unit, and that unit was not one of those with RESETn suppressed.


    Since the occurrence rate of the issue is low, I think it is difficult to draw a definitive conclusion from this result. We will continue increasing the number of trials.

    I will update you again once we have more data.

  • 0 in reply to Sadaharu Kanda
    Prodigy 20 points


    We are still conducting reproduction tests and have not observed any issues so far.
    This is just an idea, but could you please tell me the following?

    In the warm‑reset issue, is the initialization related to EMIF(DDR) IF leveling performed correctly?
    If the leveling does not complete properly and the timing margin is insufficient, is it possible that the system works for a while after the warm‑reset is released, but after several hours it hangs due to some trigger?