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.

TMS320F280049: FW update over SCI

Part Number: TMS320F280049

Hi C2000 Gurus,

I am using an ARM host MCU to update my F28004x FW over SCI. I am using the default GPIOs 28 and 29 for SCIA boot up. I am able to load the Kernel file after initiating a C28x reset and boot from SCI. After the Kernel file gets loaded, however, the autobaud lock does not work and gets stuck here (see below).

  

Here’s what I do:

  1. First, let’s make sure I am generating the Kernel file correctly. I use the CPU1_RAM config of the flashapi_ex2_sciKernel project and generate the .txt hex file using the hex2000 utility. Note that this project uses the default SCIA GPIOs 28 and 29.
  2. I then load this Kernel file from the host MCU to the C28x on a C28x SCI boot-up. No issues with Autobaud lock here. It looks like the file generated in #1 is correctly getting loaded because all data bytes that are read back match with the contents of this file exactly. The image you see above is the data received from the host MCU using a separate serial connection to my PC.
  3. I believe I allow enough time for the Kernel to start running. I have experimented with this time being as low as a few 100 ms to as long as 10s.
  4. The Autobaud lock does not happen as I do not receive the ‘A’ byte back after this Kernel file load (assuming Kernel is running at this point).
  5. I tried the BANK0_NO_LDFU config of the flashapi_ex2_sciKernel project. In this case after the ‘Kernel file’ gets loaded, the Autobaud lock works, but I think this is misleading. In this case the ‘Kernel’ seems to just echo back whatever data I send it. For example, if I send the ‘Erase ALL’ packet, it just echoes back the last byte of the packet ‘0xE4’ (i.e. 228d) instead of the correct ACK byte ‘0x2D’. 

Where might I be going wrong?

Thanks,

Hrishi

  • Hi Hrishi,

    Thanks for listing the steps considered. Few questions:

    1) What is the ARM host that you are using?

    2) Are you attempting this firmware update on the F28004 ControlCard or the LaunchPad?

    Once the kernel reinitializes on the F28004 device, it is trying to autobaud back through GPIO28/29 on the host machine. Do you have a visual of the setup that I could use? It would help to better understand the connection.

    Thanks and regards,

    Charles

  • Hi Charles,

    Thanks for the quick reply.

    The host is a nRF52 Cortex-M4 MCU.

    I am using custom hardware. C28x GPIO28 and 29 go to the host pins that are configured as SCI pins.

    The C28x is clearly able to boot from SCI and load the Kernel. Can you confirm that it is correct to use the Kernel file generated using the CPU1_RAM config of flashapi_ex2_sciKernel project?

    I cannot share schematics on the forum but I can share them directly with you, if that helps.

    Thanks,

    Hrishi

  • Hi Hrishi,

    Yes you can use Kernel file generated using the CPU1_RAM config of flashapi_ex2_sciKernel project but you have to crosscheck clock frequency and modify it as per yours.

    Regards,

    Rajeshwary

  • Hi Rajeshwary,

    Yes, fixing the clock config in the flashapi_ex2_sciKernel project seems to solve the Autobaud lock issue after Kernel download. However, the process seems to get stuck after this when I transmit the first byte of the ERASE ALL send packet (0xE4 i.e. 228d). Please see below. I will continue working on this to see what might be causing this issue but please let me know if there is something obvious (like the clock config) that I might be missing. 

    I will mark this post as resolved and submit a new post for the sendpacket issue with a link to this thread, if I do not make any progress on my own.

    Thanks!

    Hrishi