Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 102 subscribers
  • Views 1848 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

OMAP 4460 hardware reset issue (NRESPWRON)

Suhas M
Prodigy 215 points
Other Parts Discussed in Thread: 4460

Hi,

We are working on a battery operated custom board with OMAP 4460 processor and we are facing an issue with cold reset (NRESPWRON) input.

In our system configuration, boot strap is set as 000101 (PRIORITY: USB MMC1, MMC1 is permanent boot). We have two revisions of boards, alpha and production with no hardware changes related to OMAP between the two revisions of boards.

In alpha boards, the system reboots as expected when a hardware reset is given(trigged through NRESPWRON switch).

But in production boards, we observe that after first hardware reset, system will not boot from MMC1. Even though MMC1 is set as permanent boot source, the boot ROM code will be continuously check for USB boot source.

Subsequent second hardware reset, the system boots from MMC1 as expected.

We want to understand why there is anomaly between the two versions of OMAP. Alpha boards were built in 2012 and production boards were built in July/August 2013.

One more observation is that the hardware reset works as expected in production boards without battery (first hardware reset triggers the board to reboot). here we do not understand the relation between battery and OMAP reset.

Regards,

Suhas M

 

  • 0
    TI__Genius 10965 points

    Hi Suhas,

    What kind of pmic are you using, and is it possible to be soldering defect  somewhere around it?

    If you have another production board and  still experiences the same effect and as you said the wiring is same as the alpha version then perhaps the problem is caused by the assembly process.

    Regards,

    Boyko

  • 0 in reply to Boyko Kazakov
    Prodigy 215 points

    Hi Boyko,

    Thanks for the reply, we are using TWL6030B1AACMR PMIC. We do not suspect assembly issue because, every second time the reset works as expected. This pattern is consistent across a set of production boards(which we are currently testing).

    As i explained earlier, every reset triggers reboot  but first reset after power on system will not boot from MMC1. Even though MMC1 is set as permanent boot source, the boot ROM code will continuously check for USB boot source.

    Subsequent second hardware reset, the system boots from MMC1 as expected.

    Is there any way verify the boot ROM code version? since only boot ROM code has control over boot source selection besides strap pins.

    Regards,

    Suhas M

  • 0 in reply to Suhas M
    TI__Genius 10965 points

    Hi Suhas,

    According to Silicon errata,this problem may be observed because of VDD Ramp-up Delay

    "In that case, the ROM code checks the SDMMC1_VDDS voltage too early, reads a bad level, and then jumps to 1.8-V configuration while the PMIC was configured to 3 V"

    I can suggest you scope this voltage at the time of reset and observe if it truly is due to this delay.

    Regards,

    Boyko

  • 0 in reply to Boyko Kazakov
    Prodigy 215 points

    Hi Boyko,

    We monitored the SDMMC1_VDDS on reset and found that it is set to 3.0V and it does not dip to 1.8V.

    We did some more investigation by probing CMD and clock lines on SDMMC interface where boot SD card is present. In normal units, we observed that initialization is happening at 390KHz on reset and then it boosts to 3MHz while loading the contents.

    But in the units which does not reboot, the initialization begins at 390KHz  but it fails at some instant. So, the boot rom code resets. By this we concluded that the problem is with certain sdmmc interface and not with SDMMC1_VDDS.

    We tested with different cards(speed grade and capacity) and observed that the following cards are consistently failing:

    1. SanDisk ulttra 64GB card.

    2. Kingston class 10 8GB card.

    Is there any card compatibility issue with OMAP4(boot rom code)? how can we validate this? 

    Regards,

    Suhas M

  • 0 in reply to Suhas M
    TI__Genius 10965 points

    Hi Suhas,

    Have you tried observing the booting sequence with logic analyzer? Perhaps if the card takes too much time to respond the rom code time-outs and resets. If we can monitor the sequence perhaps we could find a potential solution for it.

    Regards,

    Boyko

  • 0 in reply to Boyko Kazakov
    Prodigy 215 points

    Hi Boyko,

    Thanks for your response. Unfortunately we do not have logic analyzer setup to monitor the MMC command sequence. 

    We would like to know if there is restriction in using sandisk ultra sdxc (64GB) card as boot source for OMAP4? as we have observed this reset issue consistently in three cards that we have.

    Also we would like to know if there is any relation between boot rom code and battery. Because we observe this issue only when the battery is present.

    Regards,

    Suhas M