• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 84 subscribers
  • Views 1105 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.

TMS320F280025C: Programming and Firmware Update Questions

Meredith Turner
Prodigy 360 points

Part Number: TMS320F280025C
Other Parts Discussed in Thread: C2000WARE, TIDM-02011

Hi!  I have a customer with questions below....please help advise.

We have of questions regarding MCU TMS320F280025C SCI firmware update would like to seek for your advice on.

  1. Is there any Linux driver/library available that we could use to facilitate the firmware update task??
  2. From Serial Flash Programming of C2000Tm Microcontrollers , we found that the MCU is not listed in the list neither Flash Kernel A nor B. May I know which exactly the MCU support?

3. From the table 3-1, to enable firmware program via UART, we could see that we must force HIGH for GPIO32 while LOW to GPIO24, then followed by a power reset.

When MCU is boot, the SCI loader in ROM will start executing and waits to autobayd lock with host. May I know whether this is the only setup we should take care on in order to use SCI loader in ROM?? Did I missout any setup to enable firmware programming via UART??

On top of the above questions, we would like to know also whether there are a way the host controller able to send a reset command to MCU via UART during normal operation as well as during SCI firmware update taking place?? Or it is a must we need another GPIO line from host controller to trigger a reset to MCU (in order to change boot mode before and after firmware update)??

Thank you!

Meredith

  • 0
    TI__Mastermind 27145 points

    Meredith,

    1. We have a F28002x SCI Flash Kernel + Windows host side executable that can be used. We don't have Linux side support in the executable, but the customer can create this.

    2.Yes, sprabv4 needs to be updated with F28002x  (Flash Kernel B). The F28002x Flash kernel was developed recently, and is still not released in C2000Ware.

    3. Yes, just also note that the default GPIOs used for SCIRX/TX are GPIO28/29.

    Yes, the host can send a Reset command to the MCU via UART while in SCI Boot mode. The SCI Flash Kernel supports a number of commands - Reset/Erase/Verify/Firmware update etc.

    Your last question is more an implementation choice, and is up to the customer i.e. whether they want to normally boot in Flash boot mode, and switch to SCI boot only for Firmware updates, or always boot only in Flash boot mode. In the latter case, they will need certain extra steps e.g. the Flash kernel will need to be in the device's Flash.

    Thanks,

    Sira

  • 0 in reply to Sira Rao80
    TI__Prodigy 360 points

    Hi Sira,

    Thanks for the quick inputs!  Follow-up questions below....

    Input 1: “We don't have Linux side support in the executable, but the customer can create this.”

    Question 1: Are there any source code or documentation that we can refer to?

    Input 2: "The F28002x Flash kernel was developed recently, and is still not released in C2000Ware.”
    Question 2: Is there any way we could get the kernel? We need it to perform some evaluation testing.

    Input 3: “Your last question is more an implementation choice, and is up to the customer i.e. whether they want to normally boot in Flash boot mode, and switch to SCI boot only for Firmware updates, or always boot only in Flash boot mode”

    Question 3: Our plan is normally boot in Flash boot mode, and switch to SCI boot mode only for firmware update.
    During flash boot mode, when the MCU firmware/application is running – is the firmware/application capable to issue a reset?

    Question 4: Since our host will communicate with the MCU firmware/application through UART, if the MCU application is capable to issue reset then the host could send a UART message to the MCU application and ask it to issue a reset.
    By doing so, we will not need a physical GPIO line (from host to MCU reset pin) to trigger MCU reset, is my understanding correct?

    Thanks,

    Meredith

  • 0 in reply to Meredith Turner
    TI__Mastermind 27145 points

    Meredith,

    1. I'd like to understand the Linux side request better. What is the customer trying to do? Update the software from a Linux host? If yes, like I mentioned, the current serial flash programmer executable is a windows only application. I don't have too much insight into this.

    2. Yes, I am in the process of creating a MySecure Software release for this. You can email me for details. It should be ready by mid next week.

    3. Help me understand this better. The application is running, and you want the MCU to reset. Why? To switch to SCI Boot and do a Firmware update? This can be done, for example, by enabling a watchdog and not servicing it. There has to be some external/internal trigger.

    4. This is related to 3 above. Ok, I think there is a subtlety here. The host communicates with the Flash KERNEL over UART, and the Flash KERNEL supports Commands, including Reset. Now, when the APPLICATION itself is running, normally it wouldn't support any host communication. Unless you built in this support into the application. I can give you an example - LFU, or Live Firmware Update. Here, we do everything in Flash boot mode i.e. we never switch to SCI Boot (even though the firmware itself is downloaded via SCI i.e. UART). The key is the Flash Kernel is always resident in Flash. Some space is reserved in Flash for it. And the application has an SCIRX ISR that allows it to know when it has received a host command, parse that command, and jump to the Flash Kernel for further action.

    Something similar can be done here. If your application is running, and you want the host to send it a command to Reset the MCU. You would need an SCIRX ISR that captures this command, then some logic that parses this command and takes the necessary actions (in this case, say enable a watchdog and let it expire so the device resets). Just a thought.

    Thanks,

    Sira

  • 0 in reply to Sira Rao80
    TI__Prodigy 360 points

    Hi Sira,

    Please see additional inputs/questions below....

    1. Yes, we would like to update the MCU firmware/application from a Linux host. Hence we are looking for reference on how to build our own Linux programmer.  Is there any guidance you can provide (or point us to) to help?

    2. Thank you!

    3. Yes, we would like to reset the MCU so that it can be switched into SCI boot mode to do firmware update.  

    4. It is our project requirement to set up a communication channel between host and the MCU, because we want the MCU application to listen command from the host and perform specific task on demand (such as turn on relay or return sensor reading). This communication channel will be implemented using UART (RS-485), and we will build this communication support into the MCU application.

    Since we already have this RS-485 communication channel in place, so we think we might as well leverage it to “tell” the MCU to reset itself when we want to perform firmware update.

    Regarding LFU - From my understanding, the MCU that we selected (TMS320F280025C) contain only single bank flash memory, hence it can only support “offline firmware update” instead of Live Firmware Update (which requires dual bank flash memory). Can you help to check if my understanding is correct?

    Thank you!

    Meredith

  • 0 in reply to Meredith Turner
    TI__Mastermind 27145 points

    Hi Meredith,

    Unfortunately we don't have more resources to point to on the Linux side. The serial flash programmer source code should be easily portable to a Linux side application (whichever one the customer decides to use).

    LFU is possible on F28002x as well. Certain constraints exist - the critical ISRs will need to run out of RAM, likewise Flash APIs and the code that waits in loop while the Flash APIs run also need to run from RAM. At the end of the LFU, the device is reset through a Watchdog.

    In fact, the MySecure I am creating is a joint F28002x LFU + SCI Flash Kernel example i.e. it will have both.

    Let me know if I can help further.

    Thanks,

    Sira

  • 0 in reply to Sira Rao80
    TI__Prodigy 360 points

    Sira - More follow-up below....

    • Unfortunately we don't have more resources to point to on the Linux side. The serial flash programmer source code should be easily portable to a Linux side application (whichever one the customer decides to use).
      • Can you point us to the programmer’s Windows source code?
    • LFU is possible on F28002x as well. Certain constraints exist - the critical ISRs will need to run out of RAM, likewise Flash APIs and the code that waits in loop while the Flash APIs run also need to run from RAM. At the end of the LFU, the device is reset through a Watchdog.
      • Thanks for sharing. Can you shed some lights on what are the impacts that brought by the said constraints (i.e. ISR and codes has to run out of/from RAM)? Does it means this method consumes a lot of RAM?
    • In fact, the MySecure Software release I am creating is a joint F28002x LFU + SCI Flash Kernel example i.e. it will have both.
      • Few more questions about F28002x LFU:
        • Q1: Sounds like F28002x LFU is pretty cool. In your opinion, what is the downside of F28002x LFU compared to offline firmware update via SCI? Will LCU require significant amount of additional development effort?
        • Q2: If using F28002x LFU and the firmware update process failed due to some unexpected reason (e.g. power loss), can the host still be able to communicate with the MCU and retry the LFU?
        • Q3: When we purchase F28002x MCU from TI, will the LFU capability already enabled (i.e. the SCI flash kernel already resides in flash)? Answer of this question help us to better understand requirement to our production process

    Thank you,

    Meredith

  • 0 in reply to Meredith Turner
    TI__Mastermind 27145 points

    Meredith,

    1. Within C2000Ware at the following path:

    \utilities\flash_programmers\serial_flash_programmer\serial_flash_programmer

    2. Yes, RAM usage would be higher due to ISR + Flash APIs (unless available in ROM, which is true for F28002x) + wrapper functions

    3. 

    Q1.I don't believe so, since we provide reference examples and we already have compiler support for it. I do acknowledge that at present, a lot of the collateral on LFU is centered around dual flash bank (F28004x). We have a TID on ti.com (TIDM-02011) built around this, which shows a full system example. But we have been getting requests from customers for a single flash bank LFU example, which is why we just created the simple LED single bank example.

    Q2. If you were doing LFU with a single bank flash and had a single image in Flash that was being updated, and the update failed, then you're basically left with no working image. So you cannot retry LFU, because there's no underlying application in Flash that can support it. So you would have to go with an offline firmware upgrade at that point.

    Q3. No, LFU is a software feature. So the customer will need to incorporate the Flash kernel etc. into Flash by themselves on the production line.

    Thanks,

    Sira