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: If code crashes by going to a flash that has been re-programmed, can it brick the DSP?

Part Number: TMS320F28335

Hello,

This is a follow-up from my recent posts:

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

I noticed that the bootloader code after it completes programming the new software eventually returns to a function that is in flash.  The Flash has been re-programmed though, so the code that was supposed to be there may not be there anymore.  My expectation is that the code will just crash, but when I reset the board it will run again.   Unfortunately what happens is the DSP gets bricked, the password location ends up being all zeroes. 

Anyone has run into this issue?  Can anyone explain what happened?  Somehow the program that is in the flash ended up programming the flash (unintentionally)?

Thank you.

  • Stefani,

    There are two possibilities for the device brick:

    1. The updated application image is actually mapping all 0s or some non-all 1s password to password locations.  Please check your latest application map file to confirm if this is the case.

    2. When the control went back to a flash address, it can be that the code in there got executed and triggered an embedded Flash API to program the password locations.  Please check your application/flash-address to know what exists in that space and what can happen if that is executed.

    Thanks and regards,
    Vamsi

  • Hi Vamsi,

    1. The new application image is good.  here is the snippets for the password area in the Motorola S-record format:

    The .m00:

    S20633FFF6738DD1
    S20C33FFF8FFFFFFFFFFFFFFFFD1
    S80433BECA40

    The .m01:

    S20633FFF600C011
    S20C33FFF8FFFFFFFFFFFFFFFFD1
    S80433BECA40

    So they are all ones (0xFFFF).

    2. I need to install the debugger to be able to see what and where it returns in Flash.  It is in CC5.2 and XDS200 doesn't work with it.

    Thank you.

  • Stefani,

    Can you use latest CCS versions?  

    Thanks and regards,

    Vamsi

  • Vamsi Gudivada said:

    Stefani,

    Can you use latest CCS versions?  

    Thanks and regards,

    Vamsi

    I guess I can just load the symbols?  I won't be able to compile it without several changes, and I suspect the bits and bytes need to line up to generate this problem.  Let me try it..

  • Stefani,

    Yes, you can load symbols.

    If you know the name of the function to which the boot is jumping to, maybe you can look at the map file of your boot program and your latest application and figure where it is returning to.

    Thanks and regards,

    Vamsi

  • Vamsi,

    When I run the debugger (Signum JTAG) somehow I cannot stop at the breakpoint.   This is of course using the modified code because testing with the original code is very expensive (needing to replace the DSP).

    I think at the moment we are going to let this go.  By not allowing the code to return back to flash after it has been programmed it does not brick the DSP anymore.  While I have not been able to pinpoint what exactly happens I think we should go with preventing the code from randomly return to reprogrammed Flash.

    Thank you so much for your help.