• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 63 subscribers
  • Views 1021 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.

UCD90160 flash corruption

Katherine Foote
Intellectual 280 points
Other Parts Discussed in Thread: UCD90160

Hello,

I have been working on drivers for a UCD90160 sequencer.   It is behaving as expected for the most part, but recently we have had several units that appear to be blank following a reset/power cycle.

I have recently added code that clears the faults when they are detected, as the Vout status warnings/faults appear to be 'sticky'  We would like to use the over/under voltage warnings in our application, but we only want the warning to indicating when the condition is occurring.

Until this was added, we hadn't noticed the sequencer ever booting with a blank memory so I'm wondering what the mechanism is....  I hadn't expected that doing anything with the faults/logs could corrupt the data flash containing our configuration.

Is is possible/likely that the clear faults command (0x03) being executed at the same time a reset is done could corrupt the flash integrity word so that the next time the part boots up, it appears as a blank unit?

Is it possible the clearing the detailed fault logs or the peak readings could?

Is it possible that the unit could be writing a fault to its own log, and a reset occurs, causing the corruption?  I've also recently changed the fault log so that it always logs the newest faults - previously it would hit the maximum and stop until the log was cleared.

What else could do this?   I realize one way would be to put the unit into ROM mode, but that is not being done....  at least not in an intentional way.

Thank you for any suggestions!

-Katie

  • 0
    TI__Genius 9845 points
    If reset/power cycle occurs when the device is writing flash, the flash may be corrupted. The configuration and log are in the same physical flash.

    To avoid this, do not reset/power cycle the device when it is writing flash. You can use the brownout circuit and function suggested in the datasheet to provide long enough time for the device to finish logging before the V33D is lost. Do not pull the reset pin as a way to disable rails -- use CONTROL pin to disable rails instead.
  • 0 in reply to Zhiyuan Hu
    Intellectual 280 points
    I had a feeing that was going to be the answer.

    Right now, we don't have the brownout circuitry in our hardware, so I need to work around this with software.

    Does the clear_faults command (0x03) cause a flash write, or is that just clearing volatile memory? I am wondering whether it is safe to use this command if the brown out circuitry is not present and we can have a power cycle at any time that we have to handle without corrupting flash.

    I guess I need to turn off all logging on the part until we can get the brownout circuitry added. Once that is done, I've seen the settings in the Fusion tool to enable.

    Avoiding the issue on reset is going to be the trick since the hardware brownout doesn't help that situation. Is there any way to prevent flash corruption if a flash operation is occurring and the reset pin is asserted?

    Thank you very much,
    Katie
  • 0 in reply to Katherine Foote
    TI__Genius 9845 points

    Disabling fault log can help. But there is still Peak log you cannot disable. So the chance still exists, but much less.

    Why do you want to pull the reset pin? There must be another way to do it.

    Regards,

    Zhiyuan

  • 0 in reply to Zhiyuan Hu
    Intellectual 280 points

    In our design, reset does something very similar to a power cycle in function, but prevents the main power supplies on the board from turning of and on, allowing a quicker turn-on.  

    We were using the reset pin to reset the sequencer, because then it went back through the configuration routine, turning on rails in the sequence we desired.


    You mentioned a CONTROL line in an earlier post, but I didn't see that pin upon quick perusal of the datasheet.  Does that pin go by another hardware name and it is something we can configure in Fushion?  Did I just overlook it?

  • 0 in reply to Katherine Foote
    TI__Genius 9845 points
    The PMBus CONTROL pin is Pin28 of UCD90160. It can be used as a master switch to sequence rails on and off. The On/Off Config of all rails can be set to CONTROL pin, which allows CONTROL pin to initiate sequences to turn them on and off. In comparison, if you pull the reset pin, all rails will be off immediately and there is no sequence. Also, when you release the reset pin, you need to wait additional time for the UCD to finish initialization. By using the CONTROL pin, you save the initialization time.The UCD is intended to be a system manager, it should be on all the time.