• State Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 5 replies
  • Subscribers 84 subscribers
  • Views 393 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.

Original question:

TMS320F2800157: C2000 firmware updates over SPI

TMS320F2800157: C2000 firmware updates over UART

TollMan
Intellectual 485 points
Part Number: TMS320F2800157
Other Parts Discussed in Thread: C2000WARE

Tool/software:

This is a follow-up question to the one I posted earlier here.

TMS320F2800157: C2000 firmware updates over SPI - C2000 microcontrollers forum - C2000Tm︎ microcontrollers - TI E2E support forums

I am considering changing the inter-processor communication to UART (from SPI). I expect this may simplify loading of the flash kernel, and hopefully, flash kernel implementation/ (or availably).

1) Is it true that a firmware updates over UART is a simpler solution?

2a) Is does the flash kernel need to be built from source code in the SDK?

2b) If so, is this the source code path? {$SDK_INSTALL_PATH}\driverlib\f280015x\examples\flash

  • 0
    Intellectual 485 points

    UPDATE

    After the original post I continued reading into the SCI bootloader. Below, I have pasted excerpts from documents SPRUIY4B and SPRABV4H that relate to the following questions.

    1) Am I correct in interpreting the documentation to mean that a host microcontroller can implement the protocol used by hex2000.exe?

    2) Does this solution avoid needing to use a 'flash kernel'?. 

    Reference1

    SPRABV4H  Serial Flash Programming of C2000 Microcontrollers (Rev. H)

    Section "5 Flash Kernel B"

    "Flash Kernel B runs on: • TMS320F2807x • TMS320F2837xD • TMS320F2837xS • TMS320F28004x • TMS320F2838x • TMS320F28002x • TMS320F28003x • TMS320F280013x • TMS320F280015x • TMS320F28P65x"

    "Flash Kernel B is more robust than Kernel A. It communicates with the host PC application provided in C2000Ware (C2000Ware_x_xx_xx_xx > utilities > flash_programmers > serial_flash_programmer) and provides feedback to the host on the receiving of packets and completion of commands given to it."

    Reference2

    SPRUIY4B TMS320F280015x Real-Time Microcontrollers Technical Reference Manual (Rev. B)

    5.8.1 Bootloader Data Stream Structure

    "This section details the data transfer protocols or stream structures that allow boot data transfer between boot ROM and host device. This data transfer protocol is compatible to the respective bootloaders on C2000 devices."

    "Table 5-50 and Example 5-2 show the structure of the data stream incoming to the bootloader. The basic structure is the same for all the bootloaders and is based on the C54x source data stream generated by the C54x hex utility. The C28x hex utility (hex2000.exe) has been updated to support this structure. The hex2000.exe utility is included with the C2000 code generation tools. All values in the data stream structure are in hex. Refer to Section 5.8.2 for more details on using the C28x hex utility to convert a project to this format."

  • +1 in reply to TollMan
    TI__Genius 11895 points

    Hi,

    TollMan said:
    1) Am I correct in interpreting the documentation to mean that a host microcontroller can implement the protocol used by hex2000.exe?

    Yes, the serial_flash_programmer.exe run by the host sends the kernel and application hex files in the format generated by the hex2000 utility.

    The ROM loader requires data to be presented as a data stream and boot table. The structure is common to all ROM loaders and is described in detail in the Bootloader Data Stream Structure section of the device-specific TRM.

    TollMan said:
    2) Does this solution avoid needing to use a 'flash kernel'?. 

    If you wish to program the device's flash, then you need to use a flash kernel (or use a custom bootloader executing in the flash). This is because the bootloaders included in the ROM can only load code into the RAM.

    Please refer to this user's guide for more details on the hex utility and flash kernels: https://www.ti.com/lit/sprujh3

    Best,

    Matt

  • 0 in reply to TollMan
    Intellectual 485 points

    UPDATE2

    After the previous update I continued reading into the SCI bootloader. 

    For a 'host microcontroller' to update a TMS320F280015x,  it seems that one could:

    • port the utility "serial_flash_programmer.exe" to the host microcontroller
    • route the Boot Mode pins needed to enter SCI Bootloader Mode to the host microcontroller
    • route the XRSn through an open drain (e.g. MOSFET) output of the host microcontroller to allow it to control reset of TMS320F280015x.

    For porting, the C++ project can be used. It is at path:

    {$VMWARE_INSTALL_PATH}\utilities\flash_programmers\serial_flash_programmer\serial_flash_programmer.sln

    Questions:

    1) Is the solution above accurate?

    2) The solution above as straight-forward as it seems, or are there any caveats I am missing?

    3) It seems that this solution would be common to other projects. If so, maybe there is already a C port for serial_flash_programmer.sln. Is the one?

  • +1 in reply to TollMan
    TI__Genius 11895 points

    Hi,

    I do not believe it is possible to port the serial flash programmer executable to a host MCU due to its dependence on the Windows API. The executable is expected to be run on a Windows machine. There is not a C port for serial_flash_programmer.sln.

    Best,

    Matt

  • +1 in reply to Matt Kukucka
    Intellectual 485 points

    Hi Matt,

    Maybe "porting" wasn't the best term. I meant that I would use serial_flash_programmer.sln as a reference and the description or the protocol in the Technical Reference Manual to create a C module to execute on the host microcontroller what "serial_flash_programmer.exe" is doing.

    Regards,

    Tollman