• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 82 subscribers
  • Views 591 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.

TMS320F28379D: Firmware upgrade in CPU1 and CPU2 using USB

varada pavani
Intellectual 520 points

Part Number: TMS320F28379D

Hi Team,

I am working in TMS320F28379D based custom board.We are doing firmware up-gradation on both the cup's using  usb_flash_programmer.exe.

Configuration:

1. F2837xD_usb_flash_kernels_cpu01.dat configured for DUAL and created .dat file using hex2000 utility.

2.Blinky_dc_cpu01.dat configured for CPU1_FLASH_STANDALONE.

3.F2837xD_usb_flash_kernels_cpu2.dat  configured for CPU2_RAM

4.Blinky_dc_cpu02.dat configured for CPU2_FLASH

Working case:

usb_flash_programmer.exe  F2837xD_usb_flash_kernels_cpu01.dat  Blinky_dc_cpu01.dat  F2837xD_usb_flash_kernels_cpu2.dat Blinky_dc_cpu02.dat

With the above command i can upgrade image successfully using USB , and able to  boot the board with updated images.

Failure Case:

usb_flash_programmer.exe  F2837xD_usb_flash_kernels_cpu01.dat  Blinky_dc_cpu02.dat F2837xD_usb_flash_kernels_cpu2.dat Blinky_dc_cpu01.dat

if we are interchanging both the images it is showing success logs, but board is not able to boot with updated images.

How can we avoid such cases? If we are passing arguments in a wrong way for  usb_flash_programmer.exe is there any way to throw failure logs?

Thanks&regards,

pavani.

 

 

  • 0
    TI__Mastermind 32995 points

    Hi,

    You have the images in an incorrect order, that is why it is failing. I hope the procedure of the firmware update is understood. The CPU1 kernel first gets loaded and then expects an image for the CPU1 flash to program using the flash API. If you send it a CPU2 image with CPU2 flash memory addresses and data, then the CPU1 kernel will be unsuccessful in programing the CPU2 flash because CPU1 does not have access to it.

    There is no way to throw failure logs in the usb flash programmer as it is today. You can modify it as needed. You can send the host pass/fail data from the kernel trying to program the flash or you can check the data range in the usb flash programmer itself before sending the image.

    sal

  • 0 in reply to Sal Pezzino
    Intellectual 520 points

    Hi Sal,

    We understood the firmware procedure. What actually our doubt is even if we are trying to flash images in incorrect order usb_flash_programmer.exe is programming successfully.

    According to your point "If you send it a CPU2 image with CPU2 flash memory addresses and data, then the CPU1 kernel will be unsuccessful in programing the CPU2 flash because CPU1 does not have access to it". It should fail while programming itself.

    I tried with same in control card. Still it is programming successfully.

    Thanks&regards,

    pavani.

  • 0 in reply to varada pavani
    TI__Mastermind 32995 points

    Hi pravani,

    What do you mean it is programming successfully?

    Do you mean the flash is correctly programmed? or do you mean that the usb flash programmer is not returning an error?

    These are two different things.

    sal

  • 0 in reply to Sal Pezzino
    Intellectual 520 points

    Hi Sal,

    Do you mean the flash is correctly programmed? or do you mean that the usb flash programmer is not returning an error?

    Usb_flash_programmer is not returning an error.

  • 0 in reply to varada pavani
    TI__Mastermind 32995 points

    There is no diagnostic feature in the usb flash programmer to detect and report this.

    You are free to modify the source code and the communication to do this if you wish, or you can just input the files as it expects.

    I believe this thread to be resolved.

    sal