• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 3 answers
  • Subscribers 83 subscribers
  • Views 451 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28377D: Why does incorrectly initialized data in CLA to CPU message RAM most often read back “NaN” in 0x148C?

Sheldon He
Expert 8585 points
Part Number: TMS320F28377D

Hi all,

My customer is developing using F28069 and they meet a strange problem. Though the problem has already been solved by correctly initialize the variable in CLA to CPU message RAM. They are highly demand to know why this problem mostly happens on the same address(0x148C) and the rate of occur differs among chips made in different batch. Thanks! 

Here is a related question on E2E

https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/625112

  • 0
    TI__Mastermind 32995 points
    If the data isn't initialized properly, then it may appear as a NaN when represented as a floating point number. It depends on the value of the RAM.

    Please see: en.wikipedia.org/.../IEEE_754-1985

    You should also initialize variables. Also, initializing the entire message RAM may be a good idea as well. You can see this in the CLA examples and the CLA math library examples.

    Regards,
    sal
  • 0 in reply to Sal Pezzino
    TI__Expert 5240 points
    Sheldon,

    I agree with Sal's reply entirely. The non-initialized state of RAM will vary between devices and between batches, it is absolutely required that an application initialize variables before use.

    You also seem to have some question as to why some batches show a higher rate of certain uninitialized values than others. This is common and typical of all RAM devices. This is one reason that uninitialized variables are so problematic, things can seem fine for a while (by bad luck) and then show up as a problem when a system ramps to production volume.

    Normal process variation can tend to run 'hot' or 'cold' and this can vary both on a device to device and batch to batch basis. You may see a set of devices tending towards uninitialized 'zeroes' for a long time and then later batches trend towards uninitialized 'ones'. There are many many factors involved in this normal variation and it is not possible to generalize any expectation on the initial condition for any RAM bit on power up.

    I hope this helps your customer understand a bit more. Using uninitialized variables is a problem that most developers of embedded systems will encounter once at some point in their careers (but usually not twice).

    Best regards,
    Jason
  • 0 in reply to Jason Whiles
    TI__Expert 5240 points

    Sheldon,

    The below article is in a related field, but contains some additional information related to variation of SRAM bits.  You might find this interesting.

    Best regards,

    Jason

    D. E. Holcomb, W. P. Burleson and K. Fu, "Power-Up SRAM State as an Identifying Fingerprint and Source of True Random Numbers," in IEEE Transactions on Computers, vol. 58, no. 9, pp. 1198-1210, Sept. 2009.

    doi: 10.1109/TC.2008.212

    Abstract: Intermittently powered applications create a need for low-cost security and privacy in potentially hostile environments, supported by primitives including identification and random number generation. Our measurements show that power-up of SRAM produces a physical fingerprint. We propose a system of fingerprint extraction and random numbers in SRAM (FERNS) that harvests static identity and randomness from existing volatile CMOS memory without requiring any dedicated circuitry. The identity results from manufacture-time physically random device threshold voltage mismatch, and the random numbers result from runtime physically random noise. We use experimental data from high-performance SRAM chips and the embedded SRAM of the WISP UHF RFID tag to validate the principles behind FERNS. For the SRAM chip, we demonstrate that 8-byte fingerprints can uniquely identify circuits among a population of 5,120 instances and extrapolate that 24-byte fingerprints would uniquely identify all instances ever produced. Using a smaller population, we demonstrate similar identifying ability from the embedded SRAM. In addition to identification, we show that SRAM fingerprints capture noise, enabling true random number generation. We demonstrate that a 512-byte SRAM fingerprint contains sufficient entropy to generate 128-bit true random numbers and that the generated numbers pass the NIST tests for runs, approximate entropy, and block frequency.

    URL:  http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4674345&isnumber=5176044:0:0

  • 0 in reply to Jason Whiles
    TI__Expert 8585 points
    Hi Jason,
    Many thanks to your detailed reply!
    But there still one question not been solved. They find the uninitialized RAM always give "NaN" on address 0x148C. So they want to know why the uninitialized data is not a random number? Why this problem always occurs on the same address?
    How could we convince them this is not a hardware problem?
    Thanks!
  • 0 in reply to Sheldon He
    TI__Mastermind 32995 points
    Sheldon,

    NaN can be represented many different ways. Please see the Wikipedia article I posted. NaN isn't an actual value, it is represented by many actual values.

    Regards,
    sal