• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 63 subscribers
  • Views 334 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.

CCS/UCD3138064: What reason will make UCD3138064 reset ?

user5779721
Intellectual 525 points
Part Number: UCD3138064

Tool/software: Code Composer Studio

Hello；

     Reacently in a project ,my IC reset repeatly. i want to know all the reason about  resetting UCD3138064 inculding software and  hardware reason.

     As I konw in hardware : VCC and BPI8 supply if not stable will make IC reaseted.

     And i catched  the wave about  vcc and  bp18 .Didn't found any promble?

     Have any manual introudce about ucd3138064 reaset ? 

Thankyou verymuch!

  • 0
    TI__Genius 17090 points
    If the program is written properly, the normal problem is noise on the power supply. This can be fixed by proper board design, grounding and filtering. We do have a design guide online for this:

    www.ti.com/.../slua779b.pdf

    Our open loop boards don't meet the guidelines, so sometimes they will reset as well. Unless you are using them to drive a power supply, they generally only reset if you do something like switching all the DPWMs on synchronously. On any board, we don't recommend that. We recommend putting DPWM edges with an offset of a few nanoseconds, so only one DPWM is switching on or off at a time.

    There are lots of ways to reset the ARM core with a program issue, so if it is resetting consistently, even without power running, that is a possibility.

    If a program is incorrectly written, for example with pointers which point to illegal memory, then the ILLADR bit will get set as well.

    The little bits of assembly language in the load.asm and the start of the software interrupt are likely to cause this if they get changed incorrectly.

    Also, stack overflow can cause this by putting incorrect data into registers which are then used for addressing.

    I think it is also caused by accessing protected locations in user mode, so trying to write to protected registers or to data flash in user mode, instead of doing it in a hardware or software interrupt, this could also be an issue.

    So if it is happening every time a program is run, even without the power supply running, I would blame the program. Otherwise it is probably noise.

    There are even cases where some processors will reset and some won't . With noise, due to production variation, some processors will be more sensitive than others. This is why it is important to follow the design guidelines.

    Programs can also be sensitive to memory initialization if all variables are not initialized. Our load.asm clears all the RAM, so that should not be an issue. Some of our programs rely on that function, so if it is removed, there could be issues with some chips and not with others, depending on how the RAM comes up at power up. RAM generally comes up with a random pattern, but the same chip will tend to have the same pattern every time.