• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 445 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.

TMS320F2810: TMS320F2810 flash error

Aviinaash S
Prodigy 50 points

Part Number: TMS320F2810

I have a TMS320F2810 device on the field. We did a field upgrade using another micrcontroller transferring data to the TMS320F2810 via UART. It finishes the upgrade and then restarts. The new application starts and we see few msgs sent to us, but after sometime we find the device completely not working. When we got the device to check we connected the JTAG and saw several sections of data in the FLASH is missing. Also the .boot section inside 0x3E8000 is missing, so the device never starts after that. We are unable to figure out what could have caused this section of data missing. Also we are confused, why it started after upgrade and sent several messages back and then stopped working. Any idea how contents of the flash could have been erased?

  • 0
    TI__Mastermind 45606 points

    Hi,

    Aviinaash S said:
    When we got the device to check we connected the JTAG and saw several sections of data in the FLASH is missing.

    When you say sections were missing you mean they were in an erased state (i.e. memory reads 0xFFFF)? Do the "sections" of missing data match up with the flash sectors defined in the device datasheet? Note that the Flash API erase function will erase the entire sector, that is why I'm asking.

    Is the F281x Flash API  library stored on the device?

    Best,

    Kevin

  • 0 in reply to Kevin Allen18
    Prodigy 50 points

    Hi Kevin,

    Missing sections i meant they were in erased state (0xFFFF) We checked each sector and the .map file in compile to compare the data. Starting at 0x3e8000 entire .boot section was 0xFFFF. 0x003f7ff6 where codestart.asm is present had 0xFFFF. Only  .text section had only 0x740 locations filled with data and rest of them with 0xFFFF.

    The flash library is located in H0RAM to ensure the flashing runs from RAM.

    The biggest question was after upgrade it started executed few functions to send messages back and then after sometime it failed. After hard reset several times it did not start, so we took the hardware and checked with JTAG and saw these erased sections. We have no idea how it got erased.

    Is there any possibility the PC pointing to H0RAM starting another upgrade while application is running?

    Thanks and Regards,

    Aviinaash S

  • 0 in reply to Aviinaash S
    TI__Mastermind 45606 points

    Hi Aviinaash.

    It's difficult to say what exactly happened right now.

    What flash sectors A through E below are in a completely erased state (all 0xFFFF) after the reset? Can you also check the values of the passwords starting at 0x3F7FF8?

    Best,

    Kevin

  • 0 in reply to Kevin Allen18
    Prodigy 50 points

    Hi Kevin,

    We are not using the CSM currently and those locations are default at 0xFFFF. Even the location of 0x3F7FF6 with the codestartbranch.asm is filled with 0xFFFF.

    There is little data in Sector C from location 0x003F8046 and also in Sectore E starting from 0x3E8080 there is data upto 0x740 locations rest are all 0xFFFF.

    We are still not able to figure out, If it was a problem during upgrade i would have expected it to not come out of the upgrade module. But in this case it did restart after the upgrade, we were able to see the correct upgraded version number in the messages it sent. But after 5 mins there was no more messages and when we check the hardware large sections of memory has been erased.

    Thanks and Regards,

    Aviinaash S

  • 0 in reply to Aviinaash S
    TI__Guru* 85850 points

    Aviinaash,

    I'm going to take over for Kevin on this thread.  I'm assuming from the above that this is an isolated return from your field(i.e. no other devices are showing this), but want to make sure.

    While not normal behavior the device could have called the flash API erase function, which would result in the above.  Again, this wouldn't normally happen, unless the device was not behaving per specification.

    Is there a check in your code after the download of the new image to verify it is correct before re-programming the flash.  What I mean here is by the process of the upgrade we know at one point in time that the flash contents were good before they started to erase?

    When you see sections of code go to 0xFFFF, can you comment if it is an entire sector that is 0xFFFF or just a portion.

    Best,

    Matthew