• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 972 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.

DM8168 reset problem

Carl Blake
Expert 1160 points

We've been struggling with a problem with the DM8168 reset for some time.  Our solution was to implement hardware that performs a power cycle rather than a reset, but we need to get this problem solved.

If we do a reset (e.g. with reboot -f) while running in linux, we can see the RSTOUTn signal activate for approximately 800ns and the system restarts, but many times the I2C interface will not function properly.  We can see this problem with the I2C interface in uboot by running the uboot command i2c md.

If we do a reset in uboot, we can see the RSTOUTn signal activate for approximately 800ns (the same as in linux), but the I2C interface always works properly.  In fact many times to get the system working again, we'll stop the boot in uboot and execute the reset command.

Does anybody know a solution to this problem?

  • 0
    Prodigy 210 points

    This may seem tangential, but do make sure the values of your pull-up/pull-down resistors on the BOOTMODE (and other boot related pins) are proper.  The values in the EVM schematic are too weak and I've seen a few warm-boot anomalies with peripherals as the value latched into the boot registers on cold boot differed from warm boot.

    This may not solve your issue, but do take a few moments to rule it out for your own sanity.  (Check out the SPRUGX8 manual and verify that your switch settings match the register values from 0x48140040 under the different circumstances... cold/warm...)   (devmem 0x48140040)

    Along the same line, there are different levels of "warm" boot depending on what causes the reboot, i.e. POR/RESET/Watchdog.  (See "System-Level Reset Sources section of the datasheet).  In the absence of finding a valid solution in you application, you may be able to use this as a better workaround than a power cycle.  (Also note that the EVM's resistors for the watchdog POR circuit are not functionally usable values either.)

  • 0 in reply to Tate Schaar1
    Expert 1160 points
    We've confirmed that the BOOTMODE is correct and the same as the register 0x48140040. We're using 10k pull downs and 1k pull ups for BOOTMODE. We don't see anything wrong there.

    Both uboot and linux set the cold boot reset bit (bit 1) in the PRM_RSTCTRL (0x481800a0) register when doing a machine reset. The only other choice for a reset seems to be the warm boot reset bit (bit 0). We aren't using the watchdog capability. I would think that a cold boot would be better than a warm boot for our purposes.

    I have noticed that a power on reset never seems to exhibit this problem.
  • 0 in reply to Carl Blake
    TI__Guru**** 170625 points
    Carl,

    Do you have issue to reset the DM816x I2C module or external chip attached to the i2C bus?

    See also if the below e2e threads will be in help:

    e2e.ti.com/.../228610
    e2e.ti.com/.../506250
    e2e.ti.com/.../360513
    e2e.ti.com/.../1755334

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    Expert 1160 points

    Originally we thought that the problem was an I2C device in our system that could not be reset unless it was powered down.  That is why we implemented a hardware change to power the system down.  However, further testing has shown that this I2C device is not the problem.  We believe that we have narrowed the problem down to the DM8168's I2C interface.  One reason we believe this is because when the problem occurs the I2C interface will work with some I2C devices, but not others.  Different I2C devices will work and others will not work every time the problem occurs.  Most of these devices are reset when the system resets.  Another reason we believe it's the DM8168 is because doing the reset while in uboot causes the system to work every time.  We've started to wonder if it has something to do with the initialization of the coprocessors.

    I've looked through the threads you linked, but none of them seem to be related to this problem.

    I tried having uboot reset the i2c interface with the command "i2c reset", but it did not help.  Not even uboot is able to access the i2c bus correctly.

  • 0 in reply to Pavel Botev
    Expert 1160 points
    We've been investigating further and it looks like the external chip does cause a problem on the i2c bus. We've discovered that if we tell the external chip to power down and then reboot the system that the system reboots without a problem and the i2c bus works. We're going to try changing the reboot sequence to first tell the external chip to power down and then do the standard reboot to see if it works properly.
  • 0 in reply to Carl Blake
    TI__Guru**** 170625 points

    Carl Blake said:
    However, further testing has shown that this I2C device is not the problem.  We believe that we have narrowed the problem down to the DM8168's I2C interface.  One reason we believe this is because when the problem occurs the I2C interface will work with some I2C devices, but not others.  Different I2C devices will work and others will not work every time the problem occurs. 

    How this prove that DM816x I2C module is the problem? If DM816x I2C module is broken, how it will work fine for some of the external I2C chips?

    Check if DM816x I2C module registers are in reset/default state after reset.

    See if the below wiki page will give you some hints:

    Carl Blake said:
    We've started to wonder if it has something to do with the initialization of the coprocessors.

    What do you mean by co-processors? Is this PMIC?

    Carl Blake said:
    I tried having uboot reset the i2c interface with the command "i2c reset", but it did not help.

    What do you think this command should do? Do you think this command will reset the DM816x I2C module?

    Regards,
    Pavel

  • 0 in reply to Carl Blake
    TI__Guru**** 170625 points

    Carl Blake said:
    We've been investigating further and it looks like the external chip does cause a problem on the i2c bus.

    This is also what I suspect.

    Regards,
    Pavel

  • 0 in reply to Pavel Botev
    Expert 1160 points

    What do you mean by co-processors? Is this PMIC?

    Huh?  I'm asking about the DM8168 which has 3 coprocessors.

    What do you think this command should do? Do you think this command will reset the DM816x I2C module?

    Yes, I thought "i2c reset" would reset the DM8168 i2C module.

  • 0 in reply to Pavel Botev
    Expert 1160 points
    I'm pretty certain now that the ADV7511/AD9389B was causing the problem. I tested all day last friday where I tell the external chip to power down before doing a reboot and the reboot was successful every time. Thanks for your help. I'm in the process of changing our reboot procedure to ensure the external chip is powered down first.