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.

TMS320F28335: Page 1 RAMM1 memory intermittently being initialised in zero during secondary bootloader operation

Part Number: TMS320F28335
Other Parts Discussed in Thread: C2000WARE

We have a board that is using the 335 DSP and is loading the bootloader via SPI from an EEPROM. Page 1 RAMM1 addresses 0x7F0 and 0x7F1 are read initially in the secondary bootloader and they sometimes equate to rubbish which is understandable (unitialised RAM) but sometimes on power-up they are both equal to zero. This happens on some boards and not on others (boards are identical).

If this was occurring all the time, I'd blame software but it's intermittent. I've looked at the primary bootloader and our secondary bootloader and this area of memory or variables are not referenced.

Anyone have any ideas or seen anything like this before?

thanks

Graham

  • Graham,

                I didn’t quite understand what you mean by “and is loading the bootloader via SPI from an EEPROM”. Are you leveraging the SPI-boot option of the on-chip boot-ROM to transfer contents from the external EEPROM? What are your boot-mode-select pins configured to?

  • Hareesh,

    Yes boot from SPI-A, so load our secondary bootloader from EEPROM. GPIO 84 - high, 85 - low, 86 - high, 87 - high.

  • So you have some boards where you don't see this issue (i.e. those two RAM locations always contain random values, no matter how many time you run this experiment) and some boards where you do see this issue (i.e. those two locations contain 0x0000 sometimes and random values other times)? Does the secondary bootloader use the values in these locations to determine what to do? Is this the correct sequence: 

    1. Power-up
    2. SPI-boot option in the on-chip boot-ROM is invoked (what you refer to as primary bootloader)
    3. The secondary bootloader in the external EEPROM is transferred to RAM and control is passed to the secondary bootloader.
    4. The secondary bootloader checks these two RAM locations and that is when you see the problem.
  • Correct. The secondary bootloader uses the RAM variables for calculating a checksum. When random values in RAM then the checksum fails which is correct, however when zero then checksum passes which is not what we want.

    I can easily fix this problem but we'd like to understand the rot cause of the memory getting set to zero. 

  • There were 3 different questions in my previous post. I don’t know to which one your response of “Correct” applies to. The most important question for me is “So you have some boards where you don't see this issue (i.e. those two RAM locations always contain random values, no matter how many time you run this experiment) and some boards where you do see this issue (i.e. those two locations contain 0x0000 sometimes and random values other times)?” If my understanding is correct, on the boards that exhibit this problematic behavior, how often does this happen? If you change the ambient temperature and/or operating voltage, do you see any difference? 

    I checked the linker command file and the map file in C:\ti\c2000\C2000Ware_2_01_00_00\libraries\boot_rom\f2833x\v2_0\rom_sources. These locations are not used by anything (including the stack) 

    STACK     : origin = 0x006, length = 0x200 

    I am trying to ascertain if the transistors used to implement the RAM may be pre-disposed to assume a particular state at power-up.

  • I checked with a design expert and got the following feedback: 

    "...RAM will tend to have a bias to a given value at a specific voltage, temperature and individual unit process variation. For any given set of devices the RAM may tend to ‘default’ to a specific value.  However under different voltage or temperature conditions (or with different devices) this ‘default’ can and will change.  This default power up state should not be depended on in an application rather than performing proper RAM initialization prior to use...."