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.

TMS320F28022: flash value changed with unknow reason

Part Number: TMS320F28022

Hi Team,

My customer are using F28022 for automotive application, they have bootloader code and APP code, for each time power on, software will check one flag stored in flash to decide whether jump to the bootloader code or to APP code, that is when this flag is 0x55BB, then it will jump to the APP code, otherwise will jump to bootloader code.

in normal application, when run in APP code and receive update code command by Uart from other MCU, then will change the flag from 0x55BB to 0x55AA by using FLASH API function in software, then will do watchdog reset. after reset, the code will jump to bootloader code.

The issue is that actually when there is no update code command by Uart from other MCU, there also have possibility that the flag which should remain 0x55BB was changed to 0x55AA. they found about 5 cases have this issue in the hundred of thousand product that work in several months, it is not easy to reproduce this issue.  in the Uart communication, there have a lot of safety mechanism like CRC, cmd id check, data length check to ensure the data communication is safety.

customer do not know how to fix this issue, did we have any other customer that have similar issue? any suggestion for this? 

Strong Zhang

  • Hi Strong Zhang,

    Could you provide some more information on this issue to assist.

    Strong ZHANG said:
    The issue is that actually when there is no update code command by Uart from other MCU, there also have possibility that the flag which should remain 0x55BB was changed to 0x55AA.

    When this issue occurs, are there other commands being received over UART? The commands being received are just different than the one that initiates the flash write from 0x55BB to 0x55AA? Or you mean there are no comms being sent over UART during this time?

    For the flash section to change from 0x55BB to 0x55AA like your saying I'd imagine the flash_program routine implemented must have executed. Is there any log available of the UART command received/sent right before this occurrence, either on the C2000 or host device side? I assume not on the C2000 side since a reset happened after.

    Strong ZHANG said:
    they found about 5 cases have this issue in the hundred of thousand product that work in several months, it is not easy to reproduce this issue.  in the Uart communication, there have a lot of safety mechanism like CRC, cmd id check, data length check to ensure the data communication is safety.

    This issue occurred after months of being in use? Is that correct?

    Best,

    Kevin

  • Hi Kevin,

    When this issue occurs, are there other commands being received over UART? The commands being received are just different than the one that initiates the flash write from 0x55BB to 0x55AA? Or you mean there are no comms being sent over UART during this time?

    --> Yes, other commands still being receive over Uart. Uart are always working. 

    For the flash section to change from 0x55BB to 0x55AA like your saying I'd imagine the flash_program routine implemented must have executed. Is there any log available of the UART command received/sent right before this occurrence, either on the C2000 or host device side? I assume not on the C2000 side since a reset happened after.

    --> Yes, I agree that  flash_program routine implemented must have executed, there is no log in available of the UART command as this issue may occur once in several month,  after the flash section to change from 0x55BB to 0x55AA a reset will happen, then it will jump to the bootloader code and stop at this mode, the product can't work any more until reprogramming the code.

    This issue occurred after months of being in use? Is that correct?

    --> Yes, it occur at random.

  • Hi Kevin,

    I just post the code from customer here, I will send you the password by email, TEST_CODE.7zcould you help review the code if any possible issue?  I know it is hard to do analysis as it can not be reproduced, it will be appreciated if you can give some suggestion to customer, Thanks a lot.

    Strong Zhang

  • Hi Strong Zhang,

    Thank you for providing these details and the code. Discussion has been taken off-forum at this time.

    Best,

    Kevin