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.

TMS320F28035: Flash corruption issue

Part Number: TMS320F28035

Hello,

we experience a strange problem with the TMS320F28035 flash. We are sporadically getting back devices out of the field with one or two corrupted data blocks in the program memory. For the corrupted memory sections it seems that somethink like this have been happen:

First, a 33 Bytes block of data has been read out from the flash, which is then shifted by a few bytes. This causes the first bytes that have been shifted "out of the block" to be lost. Then a certain pattern of data is appended to the remaining block which fills it up to again 33 Bytes. The data is then written back to the flash. The picture below shows a comparison to a valid FW with the corrupted one on the right.

The positions of the corrupted blocks within the program flash alters from device to device and there seems to be no pattern. The data pattern which is appended to the block seems to be always the same, just varying in length to refill the block.

The devices are flashed via JTAG and we have a function test for all devices prior to sending it to our customer. Hence, there should be no error when they are leaving our house.

  • Roman,

    Does you application have flash API embedded in it? Do you try updating updating flash contents in your application code?

    Regards,

    Manoj

  • The application itself does not use the flash API in order to conduct a software update. It just copies the InitFlash() routine into RAM and executes it to configure the Flash control registers.

    The field update task is accomplished by our bootloader which is linked to its own flash sector. Prior to write contents into flash it conducts a flash erase which overwrites all application sectors with ones => When the update is broken, we see that the remaining memory is filled with Fs (in difference to the above described symptomes of the issue). Additionally, a checksum is compared to verify the update process.

    As I wrote earlier, the problem seems to occur after initially program the device via JTAG. At that point, the Flash API routines have not been called by the bootloader.

  • Roman,

    Given the failure signature (shifted memory contents) shown in figure, my initial suspect is this might be happening when flash is re-programmed. I don't think this a device issue.

    Regards,
    Manoj
  • Indeed, the problem was not a device issue. Thank you for your time anyway!

    Best regards,

    Roman