• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 64 subscribers
  • Views 493 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.

Does RESTORE_DEAFULT_ALL have restrictions on UCD9240?

Ken Chapman
Prodigy 100 points
Other Parts Discussed in Thread: UCD9240

I am communicating and controlling a pair of UCD9240 devices using my own embedded scheme. I know that will raise alarm bells and I’m happy to accept that I may have made a mistake but so far everything has been 100% successful. I can read the DEVICE_ID, select each PAGE and read rail voltages, currents and various other parameters as expected and in each case I implement the PEC byte within the transaction.

 

Recently I made some adjustments to the VOUT_OV_FAULT_LIMIT value associated with page 2 on one of my devices. I could write different values and verify them by reading them back. However, this change is only taking place in the ‘operating memory’ so the next step was to see that I could use the STORE_DEAFULT_ALL (11hex) to update the Flash memory with the new value.

 

First, I attempted to use the RESTORE_DEAFULT_ALL (11hex) ‘partner command’ to restore the VOUT_OV_FAULT_LIMIT back to the default value. Unfortunately, however much I read the documentation and checked my implementation I could not get it to restore the value to that which it gets following a power cycle. I confirmed the ACK was valid following the PMBus transaction and tried with and without a PEC byte.

 

Feeling a combination of brave, foolhardy and desperate I tried the STORE_DEAFULT_ALL command anyway. I modified my VOUT_OV_FAULT_LIMIT value and then cycled the power supply. To my relief everything was still Ok, and better still, when I read the VOUT_OV_FAULT_LIMIT it returned the new value that I had set.

 

So I have confirmed that I can successfully issue a STORE_DEAFULT_ALL command but I can’t see why RESTORE_DEAFULT_ALL is not restoring the value of VOUT_OV_FAULT_LIMIT in the same way as a power cycle. Both commands have exactly the same transaction format except for the byte code (11hex verses 12hex) so even on a bad day I really can’t see what could be wrong with my implementation.

 

Which all leaves me thinking that the RESTORE_DEAFULT_ALL  command doesn’t really do what is claimed in the documentation or at least it has some restrictions over what parameters it does actually restore.

 

Looking forward to any advice, pointers and additional information. I can achieve what I need to for now but I don’t like loose ends!

  • 0
    TI__Prodigy 240 points

    Ken,

    Are any of the output Rails running when you try to issue the RESTORE_DEFAULT_ALL?  The UCD9240 will accept the RESTORE_DEFAULT_ALL command, but post a CML error for INVALID DATA if any of the outputs are running when it receives the command.

    Our PMBus Command Reference document needs to be updated to say that this is not allowed.

    Karl Northrup

  • 0 in reply to Karl Northrup
    Prodigy 100 points

    Dear Karl,

    Many thanks for your prompt response.

     

    Indeed, the rails are running in my situation. A big relief that I wasn’t doing something silly and hadn’t missed something in the current documentation. It certainly would be a good one to add to the PMBus Command Reference document. As you predicted, I have now read the STATUS_CML register and can see that bit6 (Invalid or unsupported data) does get set by the RESTORE_DEFAULT_ALL attempt. Even if I had read that status before it would have confused me given that the command doesn’t have any ‘data’ associated with it.

     

    In my ‘embedded application’ it is not possible to turn off the rails because I need to maintain power to keep my PMBus controller and other logic alive. My workaround will be to make a local copy of the ‘default’ values of interest following initial power up such that I can manually restore them to ‘operational memory’ as and when required.

    Regards,

    Ken

  • 0 in reply to Ken Chapman
    TI__Genius 13700 points

    Applying an input voltage rail sufficent to power the controllers but below the level set to turn on the rails should allow you to update the configuration for systems set as "Always Converting".  This value is found on the IOUT, VIN,TEMP CONFIG tab on the CONFIGUE page of the Fusion Digital Power Designer GUI, see below.

    Or alternately increasing this value to prevent turn-on.

    This assumes the system doesn't have any voltage sequencing restrictions which would be violated by holding off the rails controlled by the UCD92xx device.