• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 63 subscribers
  • Views 970 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/UCD3138064A: Bootloader Code of UCD3138064A

user5779726
Prodigy 245 points
Part Number: UCD3138064A
Other Parts Discussed in Thread: UCD3138064, UCD3138

Tool/software: Code Composer Studio

Dear TI，

I wanna know if there is any bootloader code in UCD3138064A.I have already started to read the Technical Reference Manual.However,I think an example is better,which would let me know how it works.

Thanks,

Larry

  • 0
    TI__Genius 17090 points
    I'm not sure what we have specifically for the UCD3138064. There's not that much call for bootloader, so we don't have a publically available one.
    So I can ask for the right thing, can you tell me what kind of bootloader you want:

    PMBus or UART (or SPI or I2C from EEPROM)

    Are you using half the program memory to run the power supply and then download a new program to the other half? If so, you don't want a bootloader, but an on-the-fly switch addition to your main program.

    Just as a note, the 064 and 064A should be exactly the same as far as bootloaders go. There are no changes from the point of view of the bootloader.
  • 0 in reply to Ian Bower
    Prodigy 245 points
    Mr Bower，

    Hello,I am a rookie about bootloader.After reading Technical Reference Manual,my conception of it is still vague.I would like to understand the practical functionality.So I really need to know how to upgrade by using PMBus bootloader,if I could.

    when you mention on-the-fly switch,I don't know what it is.But I know UCD3138 has 1*32k PFLASH,while there are 2*32k PFLASH blocks in UCD3138064(A).Is on-the-fly switch used for selecting one of the blocks?

    Thanks,

    Larry
  • 0 in reply to user5779726
    TI__Intellectual 1245 points

    Hello Larry

    The function of a bootloader is to allow field updates of your application firmware. So you can update your application firmware after the microcontroller has left your production facility. It runs as a separate program on the device, so you will have a bootloader program, and a separate application program , which contains the code to run your power supply, for example.

    The bootloader just runs a communications handler to translate commands from an external host (for example PMBUS, SPI, I2C, UART) into actions that are required for application program updates, like flash erase, flash programming and verification of flash updates. Thus, the host can update the application program firmware via the bootloader, by sending commands to the bootloader that it understands.

    Say for arguments sake that you are using the UCD3138. You have 32kB of program flash available to store firmware on the UCD3138, and you have allocated the first 2kB to a bootloader program. The remaining 30kB is then available to store your application program.

    During normal operation, after a power-on/reset, the bootloader program will execute before the application program. It would need to test the integrity of the 30kB of application program, via a checksum test, for example, then if the checksum test passes, the bootloader will pass control to the application program. So during normal operation the bootloader executes once at startup after a power-on/reset, adding a small delay before the application program starts to run, but it is hardly noticeable.

    For example, say that the application program is running and the host needs to upgrade the application program firmware, as you want to add some feature to the firmware, or you have found a bug that must be fixed. The host will send a command to the application program instructing it to pass control to the bootloader program. The application program will shutdown the power supply, then pass control to the bootloader program.

    The host will

    - send a command to the bootloader instructing it to erase the 30kB application program. The bootloader will translate this command into the action of erasing the 30kB of flash memory.

    - send a bunch of "write flash" commands containing the new binary for the application program. The bootloader will take then action of translating these commands into the action of updating the 30kB of flash with the new binary.

    - send a command to the bootloader to run an integrity test (for example, a checksum or CRC test) on the application program after it has been updated, as a way of verifying the update 

    Assuming this test passes, finally the host will send a command to the bootloader to instruct it to run the new application program.

    The UCD3138 series contains a bootloader stored in ROM (we call this the "boot ROM" program). The boot ROM works with the Fusion PMBus GUI (which also has a version which is designed for production environments). The boot ROM and PMBus GUI are used by many of our customers. It gives you the advantage of not having to write the bootloader yourself. Plus you have all of the program flash is available for the application program. This is definitely is easiest route from a development effort perspective. See http://www.ti.com/lit/ug/sniu028a/sniu028a.pdf  page 437 for more details.

    Alternatively, if you want to write a custom bootloader, we have some examples using PMBus and UART which I can share if you want to travel this route.

    As Ian mentioned, we also have an "on-the-fly" solution which doesn't even require that the power supply is turned off during a firmware upgrade.

    Let me know if you have more questions or comments.

    Best Regards

    Cormac

     

  • 0 in reply to Cormac Harrington
    TI__Intellectual 1245 points
    hello again Larry
    Regarding the "on-the-fly" solution - as I mentioned, this allows upgrades without turning off the power supply at all.

    In this solution, you will have two identical copies of the application program stored on the device, in the case of the UCD3138064A, one copy is in program flash block 0 (32kB in size), the other in program flash block 1 (also 32kB in size).

    If you want to upgrade the firmware, the host will send a command to pass control from the first copy of the application program to the second, then send commands to update the first copy while the second copy is running, then after the first copy is updated, the host will instruct the second copy to pass control back to the first copy, and then will send commands to update the second copy while the first copy is in control.

    The key thing is that the power supply firmware is continuously running, it doesn't need to be shut down during updates.

    The communications handler in the UCD that translates the commands from the host into actions (such as erase flash & write flash) runs in the background process of both copies, so the application firmware can interpret such commands sent from the host, just like a bootloader program does. So the bootloader program is "sewn into" the application program, this solution doesn't require a separate area of flash dedicated to a bootloader program.

    Best Regards
    Cormac
  • 0 in reply to Cormac Harrington
    Prodigy 245 points
    Dear Cormac,

    Owing to your detailed explanations,I come to know what bootloader is.The PC (as the host) can send commands via PMBus to the bootloader.Then bootloader interprets the corresponding command and operates the application program.This is what I used to do with UCD3xxx Device GUI,although I was unaware before.

    And I finally understand the boot flash and the boot ROM.I thought they both existed until I noticed "The boot ROM and PMBus GUI are used by many of our customers. It gives you the advantage of not having to write the bootloader yourself. Plus you have all of the program flash is available for the application program. "

    However,I really want to have a try after reading Technical Reference Manual.But I have trouble developing from nothing.I'd appreciate it if you could provide me the examples using PMBus and UART.

    Thanks,
    Larry
  • 0 in reply to user5779726
    TI__Intellectual 1245 points
    Hi Larry
    I am glad that your have a better understanding of this now.
    Can you share you email address with me, and I will send you some example code?
    Best Regards
    Cormac
  • 0 in reply to Cormac Harrington
    Prodigy 245 points
    Dear Cormac,
    Thanks for your help.My email is larry.he@wpi-group.com.
    Thanks,
    Larry
  • 0 in reply to user5779726
    TI__Intellectual 1245 points
    Hi Larry
    No problem at all.
    I will prepare some example code and explanations and will email you early next week.
    Best Regards
    Cormac
  • 0 in reply to Cormac Harrington
    TI__Intellectual 1245 points
    hi Larry
    I am working to prepare a generic bootloader project that works for all devices and a number of different boot types.
    Upon further reflection, I believe it is better that I share this with you when it is ready, as my work in progress version will have bugs and is undocumented, I think it will confuse more than enlighten at this point.
    It may take a few weeks to be finished.
    In the meantime, could you contact your local TI sales representative with this request, so we can take offline?
    Best Regards
    Cormac
  • 0 in reply to Cormac Harrington
    Prodigy 245 points
    Hi Cormac,
    Did you mean I can press the button "This resolved my issue" and ask sales representative for help?May I take it that you will provide me support after a few weeks by personal mail?
    Thanks,
    Larry
  • 0 in reply to user5779726
    TI__Intellectual 1245 points

    Hello Larry

    Yes, it would be best if you contact a local sales representative, I will also get in touch with you once the project if fit for purpose, if this is okay with you.

    And you can open another thread if you need more assistance in the meantime.

    Many thanks

    Cormac