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.

TMS320C6713B: TMS320C6713B

Part Number: TMS320C6713B

In the application of interest, the application program code is copied from external nonvolatile memory into the DSP internal RAM when power is applied. Operation from internal RAM supports fast operation.  To verify a correct copy was made, a checksum value for the RAM code area is compared to an expected value.  During normal operation a checksum of the internal RAM program memory space is periodically calculated and compared with the expected checksum value to verify the code being executed has not been corrupted.  Subsequent calculated checksum values sometimes do not match the expected/verified checksum value indicating the program code has been corrupted.  This is unexpected.  Is it reasonable to expect the RAM copy of the program will not be altered over time, e.g. over months of continuous operation?  If changes are not expected, what are the likely causes of the changes being observed and what suggestions can you offer to address the unexpected changes other than power cycling.

  • The most likely cause is some software issue that results in a change of the "checksummed"  area. 

    You should also check the stability of the power rails.

    How often does this happen?    Is it always the same bit/address that changes? 

    You could also try a dedicated s/w load that does nothing other than run a checksum on a pre-filled pattern in this area of RAM. The code could report which bits changed so you can see of there is a pattern over multiple runs (same bit/address/etc) 


  • Paul, thank you for your response.  Here is some additional information on my question.  There are 16 independent systems that each use four of the digital signal processors.  The systems can be continuously energized for long periods without refreshing the DSP internal RAM program memory space.  48 of the processors execute the same program and the other sixteen execute a different program.  The checksum issue appears on processors executing both applications.  Based on the data I have there are lengthy periods where no checksum faults are logged and then other periods were faults occur on a small number of processors over a relatively short time period.  It is possible that during the long period between the two clusters, the equipment has been deenergized or power cycled for some reason.  It is also possible checksum faults were logged but not recorded.  Over one two year period, an internal RAM checksum fault occurred in 6 of the 64 DSPs and during a 1 year period several years later, 6 faults occurred within a one year period.  Faults were reported for 10 of the 64 DSPs.  For the two DSPs that each had two faults, one occurred in each cluster.  I am not aware of an faults being logged during the four years between the two clusters.   I appreciate insight you can provide.

  • Jay

    these are always a challenge to find root cause. Best I can offer here are some things to consider.

    - Possible power issue that only occurs under a specific set of conditions. Could be external (surge/brownout), could be a weakness in the PDN to supply enough peak power 

    - Although there are two different software images running, is there common code that could be the cause.

    - External event, static or radiated emissions from other equipment.