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.

DM3730 reset sequence

Other Parts Discussed in Thread: TPS65920, TPS65930, DM3730, OMAP3530

The Technical Reference Manual (TPS65930/TPS65920 OMAP™ Power-Management and System Companion Devices) describes a number of example power-up / reset sequence examples to be used with OMAP processors. Newer versions of the upstream Linux kernel appear to implement one of these sequences as a generic example.

See this for an example patch: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/251571.html

In our design using a DM3730 but an older kernel we have now implemented a similar reset sequence because we experiencing boot problems after a warm (software) reset or one triggered by the TPS watchdog. Our sequence looks like this (my comments added):

{ MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2 }, /* Triton off */

{ MSG_SINGULAR(DEV_GRP_P1, 0x0f, RES_STATE_WRST), 15 }, /* VDD1 warm reset */

{ MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15 }, /* VDD2 warm reset */

{ MSG_SINGULAR(DEV_GRP_P1, 0x07, RES_STATE_WRST), 96 }, /* VPLL1 warm reset */

{ MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2 }, /* HFCLKOUT active */

{ MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2 }, /* Triton active */

Although we can observe the power supply rails and can confirm that we have implemented this sequence correctly we still see occasional hangups after a reset. What we see is that the sys_nrespwron signal (CPU input) is pulled active and is subsequently released. But the sys_nreswarm signal (used as an output from the CPU as input to the TPS) very occasionally remains in the active state instead of going inactive. The system will then not boot.

My questions are:

(1) Is the example really to be used as a generic reset sequence and, specifically, is it valid for OMAP DM3730 CPUs?

(2) The used sequence brings a vast improvement for us; would it make sense to experiment with the length of the delays within the sequence to try to improve things even more?

(3) What other suggestions to improve the sequence (for OMAP DM3730) can be made?

Thankyou very much in advance for your help.

  • Hi, these sequences are not examples: they are fixed inside the PMU. There is no possibility to change them.

    Best regards, Alain.

  • Alain,

    Thank you for your reply. Either I am missing something here or I have failed to explain things adequately. Please let me try again.

    We have a system with a DM3730 + TPS65920 companion chip.

    Referring to the document:

    Powering OMAP™3 With TPS65930/20:
    Design-In Guide (swcu059b.pdf)

    I read in section 3.1.1.1 Power On and Reset Management...


    The TPS65930/20 companion IC is the system power on and reset manager:
    · A push-button debouncing starts the state-machine (master configuration).
    · It controls the reset release of the OMAP3530.
    · It controls the warm reset steps when instructed to do so by the OMAP3530 or the user.
    · It can control power on of an auxiliary subsystem.


    and in section 4.3.1.3 nWARMRESET


    nRESWARM is an active low input reset signal to the device. Depending on the application, this signal can
    be connected to a reset button, an RC cell, or the warm reset output of the OMAP application processor.
    This reset signal can be used to put the device into a known stable state. For the warm reset signal to be
    functional there should be a predefined sequence programmed in the device memory. For details about
    this sequence,see the TRM.


    So we want the nRESWARM signal to start this "predefined sequence programmed in the device memory".

    If I refer to the TRM e.g.

    TPS65930/TPS65920 OMAP™
    Power-Management
    and System Companion Devices
    Silicon Revision 1.2
    Version D
    (SWCU052D)

    I read in section 

    5.3.2 Resets and Power Management
    5.3.2.1 Resets


    Warm reset: The device can be configured to perform a warm reset of the system to bring the system
    to a known defined state. The device detects a request for a warm reset on the nRESWARM pin. The
    SmartReflex I2C accesses are canceled. The minimum duration of the pulse on the nRESWARM pin is
    two 32-kHz clock cycles.
    A warm-reset sequence can be programmed in device spare memory spaces by writing to the
    MEMORY_DATA and MEMORY_ADDRESS registers. The starting address of this sequence can then
    be programmed in the SEQ_ADD_WARM register.


    A table follows which is marked as "Table 5-3. Sample Warm Reset Sequence".

    So it looks very much as if I should be able to program the sequence "by writing to the MEMORY_DATA and MEMORY_ADDRESS registers" and that the sequence in the table is only a "sample" sequence.

    By patching our Linux kernel in a similar way to the patch I mentioned in my 1st post we can observe that the warm reset sequence is being started. We can also change this sequence; e.g. remove the part that handles one of the voltage rails. Using the "sample" sequence we observe VDD1 and VDD2 being removed, coming back up and our system handles warm resets much better than before (thousands instead of hundreds of resets). However, for our application this is still not reliable enough - we still see occasional hangups where the CPU power up sequence is not completed. Note: a cold reset of the system is reliable.

    Hence my question once again: is this "sample" warm reset sequence a valid one to use for the DM3730?

    If your answer is still the same as before, please explain to me the error in my logic.

    Thanks very much,

    --

    Howard

  • Sorry Howard, I misinterpreted your question; I was referring to power up sequences while you are discussing about warm reset programmable sequences: these are different.

    But how the seuqence is affecting OMAP device this I cannot comment; I think the sequence given in the example is a valid one but I cannot verify it as I'm not accountable for OMAP support. You should post this question to OMAP forum as there is nothing I can do from PMIC side.

    Best regards, Alain.

  • Alain,

    Thank you. That explains it. I will find the correct forum and post again there.

    Regards,

    --

    Howard