• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 324 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.

TMS320F28054F: programming via bootloader

Jan Huijser
Prodigy 190 points
Part Number: TMS320F28054F


I am trying to program the flash via the bootloader.

I am using the serial_flash_programmer on a PC and the f28055_flash_kernel from the C2000 examples.

I have rebuild this kernel with the 28054f_RAM_lnk.cmd because of the secured L0 RAM.

The output of the serial_flash_programmer looks like:

After the message "Application Autobaud Successful" the program hangs and should be terminated with Ctrl_C.

After the Application AutoBaud check, 5 seconds after loading the kernel, two blocks of data are transmitted of abaud 1067 and 2065 bytes (calculated from transmission time).

After the Application Autobaud check, 22 bytes are transmitted but no response follows, if the flash contains a valid program, this program is started on this point.

To select the SCI bootmode GPIO_34 is high and GPIO_37 is pulled low during reset, how long should this boot loader selection pins be hold in this state ?

Whats going wrong ?

  • 0
    TI__Mastermind 32995 points

    Hi,

    The Boot Mode select pins only need to be held in that state long enough for the boot mode to be selected. If you have made it to SCI boot mode then that is long enough.

    I am a little confused by your description and screen shots because they aren't labeled for me.

    You said first that after the Application autobaud is successful you see two large blocks of data sent. 

    But then you said after the Application autobaud is successful, only 22 bytes are sent with no response.

    I am not sure which of these statements is accurate.

    Four things you can do in the mean time...

    1) Look at the flow of communication between the kernel and the PC. Make sure you understand this. It will help us in debug.

    2) Please make sure the flash application you are trying to program is entirely linked to load to flash.

    3) Make sure your kernel is being loaded properly to unsecure RAM which can then be executed. Also, make sure the kernel which is running from unsecure RAM is attemption to program flash which is also unsecure. Also, make sure the data the kernel is receiving is being written to a buffer in unsecure RAM. Since it appears you are using the CSM, you need to check your security settings and make sure it is possible to accomplish what you are doing.

    4) Make sure that your kernel is erasing all the flash sectors first which you are trying to program. The default kernel may not be erasing all the sectors available on your device.

    sal

  • 0 in reply to Sal Pezzino
    Prodigy 190 points

    Hi Sal

    thanks for your quick response, I had already monitored the communication between the CPU and PC as shown in the screen shots.

    I have changed the flash sectors to be erased and now I am able to load the application into flash.

    Only the application is not started after the flashing, it seems the CPU becomes in a reset state, after a reset the program is running.

    Green is data from to PC and yellow to the PC, after the acknowledge of he last block, it looks lite the PC send to bytes with zero's and then the output of the SCI drops to 1.5V. It looks like the port is switch to an input. The application is using this port too so the output should stay's high.

    It is not a real problem because after updating the software the CPU gets always a reset.

    Regards,

    Jan

  • 0 in reply to Jan Huijser
    TI__Mastermind 32995 points

    Hi,

    It appears as you have said. The firmware is getting updated and completing. The PC is sending zeros to indicate there is no more data. But the device is not executing the updated firmware.

    Can you check what the entry address is when loading the flash application?

    You may need to debug using CCS to check the entry address. Also, you could set a breakpoint after the flash application has been received and programmed to see where the CPU goes next. It should branch to the entry address of the application. But, it appears to me that is not working properly for you.

    sal