• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 4 answers
  • Subscribers 62 subscribers
  • Views 439 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.

Original question:

CCS/UCD3138: Change parameters with Fusion Degital Power Studio

CCS/UCD3138: Weritten parameters

user5952325
Intellectual 455 points
Part Number: UCD3138


Tool/software: Code Composer Studio

Currently using the code of this URL.

http://www.tij.co.jp/tool/jp/ucd3138fw-psf

Suddenly, the following address value was rewritten to 0xffffffff.

00018880  _pmbus_dcdc_cal_constants             
0001888c  _pmbus_dcdc_cal_nonpaged_constants    
00018890  _pmbus_dcdc_config_constants          
000188d0  _pmbus_dcdc_config_nonpaged_constants 
00018900  _pmbus_checksum                       

Parameters are not rewritten in Fusion digital power studio.

Are there any possible causes?
Can you think of the effects of noise?

  • 0
    TI__Genius 17090 points

    There is a noise related cause that will erase data flash.  In the background loop, there is code like this:

    if (erase_segment_counter > 0)
    {
           erase_task(); // Handle the DFlash segment erases
    }

    We have seen cases where system noise and inadequate grounding and filtering of the UCD power supply can cause the processor bit to be changed so that the erase segment counter will be seen as non-zero when it is actually zero.  The end effect of this is that most of the dflash is erased.  

    Our recommended way of dealing with this is twofold:

    1.  Fix the layout so that the noise level is low enough so that this doesn't happen

    2. Put the lock value for the dflash lock in RAM, and have a PMBus command to write to it.  Otherwise, keep it at zero.  That way if a spontaneous data erase or other issue happens in the field, it won't destroy the data.  If you want to actually change the data, for example at production test and calibration, you need to write the lock value.  

  • 0 in reply to Ian Bower
    Intellectual 455 points
    Thak you for your reply
    .
    I have three questions.
    1.Due to fix the layout , Should I refer to the following documents ?
       www.tij.co.jp/.../slua779b.pdf
    2. Is the lock value the value of flash interlock register (FLASHILOCK)?
    3. Under normal circumstances, when will the erese segment counter be non-zero?
        Does erase_task() calls case1 of software_interrupt? Correct?
  • 0 in reply to user5952325
    TI__Genius 17090 points

    Yes to all three questions.  

  • 0 in reply to Ian Bower
    Intellectual 455 points

    Thank you for your reply.

    I have additional questions.

    Are there other noise-related causes of erasing the data flash except the following code ?

    if (erase_segment_counter> 0)
    {
             erase_task (); // handle erasure of DFlash segment
    }

    What part of the layout should I modify to prevent the processor bits from changing due to noise? Part that is particularly effective

  • 0 in reply to user5952325
    TI__Genius 17090 points

    That's the only noise caused data flash erase we have seen.  It's by far the most likely, since it gets called so often.  I'm sure there could be others, but they are much less likely and we haven't seen them.  

    We haven't done any analysis on which part of the layout has the most effect on this particular issue.  I think it would be difficult to pinpoint it.  It's a good idea to follow all the layout guidelines, to have some margin for production variation.  

  • 0 in reply to Ian Bower
    Intellectual 455 points

    Thank you for your reply.

    I have another question about data flash.

    In cofugure_functions.c, there is code like this:

     if(   (pmbus_checksum == 0x87654321) // Hardcoded exception for parms written directly to data flash
      // (GUI download tool does not calculate checksum)
      ||((checksum != 0) && (checksum == pmbus_checksum)) ) // Checksum is valid and matches.
     {
      // Checksum A Good: Use default values from DFlash A
      filter0_pmbus_regs_ptr  = &filter0_pmbus_regs_constants;
      filter1_pmbus_regs_ptr  = &filter1_pmbus_regs_constants;
      dcdc_config_ptr          = &pmbus_dcdc_config_constants[0];
      dcdc_config_nonpaged_ptr = &pmbus_dcdc_config_nonpaged_constants;
      dcdc_cal_ptr             = &pmbus_dcdc_cal_constants[0];
      dcdc_cal_nonpaged_ptr   = &pmbus_dcdc_cal_nonpaged_constants;
     }

     else
     {
      // Look in Data Flash B for valid values
      checksum = calculate_dflash_checksum((Uint8*)&filter0_pmbus_regs_constants_b, (Uint8*)&pmbus_checksum_b);
      // A zero checksum only occurs when the segment is all zeroes, which is not valid.
      // If the calculated checksum is nonzero and matches the checksum in the DFlash, 
      // that segment is good, so use it.
      if ((checksum != 0) && (checksum == pmbus_checksum_b))
      {
       // Checksum B Good: Use default values from DFlash B
       filter0_pmbus_regs_ptr  = &filter0_pmbus_regs_constants_b;
       filter1_pmbus_regs_ptr  = &filter1_pmbus_regs_constants_b;
       dcdc_config_ptr          = &pmbus_dcdc_config_constants_b[0];
       dcdc_config_nonpaged_ptr = &pmbus_dcdc_config_nonpaged_constants_b;
       dcdc_cal_ptr             = &pmbus_dcdc_cal_constants_b[0];
       dcdc_cal_nonpaged_ptr   = &pmbus_dcdc_cal_nonpaged_constants_b;
      } 
     }

    I think cpu is reading parameters of data flash at this code.

    What happens if both" if ((pmbus_checksum == 0x87654321) "and "if ((checksum! = 0) && (checksum == pmbus_checksum_b))" are not true?

  • 0 in reply to user5952325
    TI__Genius 17090 points

    It would be better if you put new questions in a new forum question.  It makes it more searchable that way.

    I'm not sure what all the codes do, but I looked at the PFC code, and it has hardcoded default parameters that it points to for loading the parameter set:

    pfc_config_ptr = &pfc_config_hardcoded;

    Remember that the EVM code is just that - an evaluation code.  So it's good to ask questions like the one you are asking here, and make your own decision on what to do with your code.  For example, if you know that the calibration is vital and sensitive, you may want to not even start the power supply at all if the data isn't valid.  

  • 0 in reply to Ian Bower
    Intellectual 455 points

    Thank you for your reply.

    I would like to ask again about the phenomenon caused by noise.

    Is the phenomenon that the data flash is erased by noise reproducible?

    Also, is there a possibility that it will occur when irradiated with radio waves in a specific frequency band?

    Have you ever seen other areas of the data flash (such as PFLASH) erased by noise? (Part or all of the area such as PFLASH)

     best regards,

  • 0 in reply to user5952325
    TI__Genius 17090 points

    Our customers have been able to make the phenomenon happen more often by making their boards noisier.  I'm not sure what they did.  Also low temperature will make it more likely to happen.  

    I'm sure that it could be caused by a high enough level of radiation.  However, with noise, other failures will also occur in the logic, and as the noise increases the level of failures increases to the point where individual failure mechanisms are very hard to detect.  This case is actually the only one where we have been able to get this much detail.   It's important to follow the design guidelines.  

    We have also seen the code to clear the checksum in program flash appear to get executed.  We never have found the path it travels to get there.  If this is a concern, you can use the same code change for it as well.  That's all we've see on these devices.