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.

TMS320F2812: Bootloader and MCU losing application program

Part Number: TMS320F2812


Hello Team,

Our Customer recently have an issue with the DSP get wipe out the Bootloader during operation for several hgours!

We review and see the TI bootloader is still existence. Do you have any idea where to look for the problem?

Thank in advances.

  • There isn’t enough information in your post to start debugging the issue.

    • What do you mean by “DSP get wipe out the Bootloader during operation for several hgours”? Are you referring to a custom bootloader in flash?
    • Effectively, are you saying the flash contents are getting erased?
    • If so, does this happen when you are trying to reprogram the flash? Or does it appear to happen spontaneously?
    • How do you reprogram the flash?

    Please answer all the above questions carefully and we can start debugging the issue.

     

    By “TI bootloader”, I presume you are referring to the on-chip boot-ROM. This cannot be "erased" by any means and will always be there (unless the chip is damaged).

  • Yes our Bootloader in flash get erase and the TI bootloader is still there ( using JTAG to check)
    This happen during our Customer operate their system for several hours ( robot arm) and not during burning firmware.
    It means the drive originally have our bootloader and firmware which working fine.
    We either use JTAG to reprogram the Flash or reset back to TI bootloader and then reload our Bootloader.

    Thank in advances.
  • How was it confirmed that the flash has been “erased”? Did you check the flash contents via CCS? In how many boards has this issue been seen?
  • We used CCS to check the flash contents. There were 10 drive that experiencing this issue :
    5 units lost Bootloader + main firmware
    3 units still have bootloader but lost Main firmware
  • Have you ever see this problem before?
    If yes, please list some scenario that this issue can happen? ESD, spike voltage?
  • Please answer each one of these questions carefully:

    1. In the 5 units that lost the bootloader + main firmware, is the flash completely erased? Can you download the flash contents as a hex file and look for any data that is not 0xFFFF?
    2. In the 3 units that still have the bootloader but lost the main firmware, is the bootloader completely intact? It is critical to ascertain if the erasure of flash happened in clearly defined sections or if random locations have been affected.
    3. How long have these 10 boards been working in the field? It is a bit strange that 10 boards have failed suddenly.
    4. ESD or voltage spikes can affect any part of the device, not just flash. Is the rest of the device OK?
    5. Are you able to reprogram the flash?
    6. How do you re-program the flash using your bootloader? Meaning which port of the device do you use?
  • In the 5 units that lost bootloade+main firmware, their flash completly erased ( attach picture)

    As you can see the password key to secure also get erased!

    In the 3 units that still have the bootloader . Yes the bootloader is still intact ( we can connect in bootloader mode)

    These 10 boards been working in the field for 2-3 days and failed.

    All the failed units get reprogram either by JTAG or RS232 and they all work fine. We tested all by using our automate test and all the devices good. .

  • Tai Trinh said:

    In the 5 units that lost bootloade+main firmware, their flash completly erased ( attach picture)

    As you can see the password key to secure also get erased!

    In the 3 units that still have the bootloader . Yes the bootloader is still intact ( we can connect in bootloader mode)

    These 10 boards been working in the field for 2-3 days and failed.

    All the failed units get reprogram either by JTAG or RS232 and they all work fine. We tested all by using our automate test and all the devices good. .

  • OK, so this is what we know about the issue:

    A total of 10 boards have failed in the field after working for 2 or 3 days. The flash is protected by passwords and are either programmed via JTAG or through the SCI port. The boards were working normally in the application and no effort was made to reprogram the flash, yet the 10 boards show differing levels of flash corruption.

    5 units – Flash is completely erased.

    3 units – The custom bootloader in flash is intact, but the rest of the flash is erased

    2 units – What is the status of this?

    All the failed units work fine after they are reprogrammed.

    Let me know if any of the above is incorrect.

  • Can you confirm if your custom bootloader has the Flash_Erase API function? If so, it was likely that it was inadvertently executed and erased the flash. I cannot think of any other way to explain what you are observing.
  • Yes. It does have Flash_Erase API function and uses Flash281x_API_Library.h
  • What are you suggest for the resolution here if this is the case?
  • OK, that explains it. You need to figure out why/when the API was called.
  • Hi Hareesh,

    This API that I found on our bootloader and do you think it may affect the erase. Please review and feedback with your suggestion?

  • We have password key in our bootloader, Is that possible to erase the bootloader and the password key?
  • This API that I found on our bootloader and do you think it may affect the erase. Please review and feedback with your suggestion?


    Yes, it can. As mentioned before, you have to review your code and figure out when the API may be called inadvertently, which is what appears happened. I unfortunately won't be of much help here, since it requires a thorough knowledge of your application code.

    We have password key in our bootloader, Is that possible to erase the bootloader and the password key?


    Yes.