• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 434 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.

TMS320F28379D: Boot Mode Confusion

Mike McDonald1
Prodigy 135 points
Part Number: TMS320F28379D


By default, the TMS320f28379d uses GPIO72 and GPIO84 for determining the boot mode. To boot from SCI, you'd pull GPIO72 low and GPIO84 high. But by default,the SCI boot uses GPIO84 as SCITXDA. So GPIO84 is being used as both the boot mode pin and as the TX pin for SCIA? How can it be used for both purposes at the same time? Is there some indicator to tell me when to stop driving GPIO84 high and start using it as SCI TX?

Under normal circumstances, I'd like our board to boot from flash, ie "Get Mode". When we need to update the flash contents, I'd like the board to boot from SCI so I can load a flash update app to reprogram the flash contents. I don't have enough free pins on my "host" processor to use the Parallel boot loader. That only leaves the SCI boot loader and the apparent conflict over GPIO84.

What am I missing? Or is there a "better" way to boot normally from flash but be able to load a rescue/updater app if needed?

Mike

  • 0
    TI__Mastermind 19795 points

    Hi Mike,

    Thanks for the questions! To answer the first, you are correct that the TX pin is used for both the boot mode pin and the TX pin. This is to reduce the need for another pin to define the boot mode. The two purposes do not conflict however, as the TX pin is controlled by the C2000, and should not be affected by the external host device during the boot time (the signal should be stable during boot as the external host does not modify TX).

    Second, the need for TX being used as TX will not occur until the actual loading has begun. To depict this in an example scenario, the TX pin will never be toggled or changed by the external host system even once fully programmed, only the C2000 will toggle this line. When will the C2000 begin toggling this line though? This only occurs once the C2000 is actually executing instructions that modify the SCIA-TX line, which will only happen after the boot has occurred.

    Third, what you are trying to do is perfectly acceptable, and we actually have a pretty great app note on this if you'd like to check it out (linked here below if you'd like to see it)!

    https://www.ti.com/lit/an/sprabv4c/sprabv4c.pdf

    This goes over how to do serial flash programming, and although it refers to a different C2000 device (with the pins related to that particular device), the general concept holds for this device as well. But to more succinctly answer the third question, the SCI boot loader being used on GPIO84 will have no conflict and can be used as mentioned above!

    Let me know if this answers your questions!

    Regards,

    Vince

    ----------------------------------------------------------------------------------------------------------------------------

    If I was able to answer your question, please press the green "Verified" button below, thanks!

  • 0 in reply to Vince
    Prodigy 135 points

    OK, let me paraphrase this back to make sure I'm understanding correctly:

    1) Since the ROM boot loader will be waiting for a 'A' on SCI RX, my host can drive GPIO84 until the host is ready to transmit the 'A'.

    2) My host releases GPIO84 and configures its I/O pin to be a UART input pin.

    3) My host then transmits a 'A' on GPIO85

    4) The ROM boot loader does baud detection, inits GPIO84 as SCI TX, and starts processing a stand boot data structure, echoing each byte back over SCI TX.

    OK, no pin conflict for SCI boot mode then

    A couple related questions about the CAN boot mode:

    a) SCI boot mode has the extra baud detection character 'A' which the ROM boot loader blocks waiting for. I assume the CAN boot mode doesn't need the rate detection so it just waits for the first CAN message in mailbox 1, which should be an 0x08AA. Correct?

    b) Is there any kind of acknowledgement from the ROM boot loader or do we assume the CAN bus is reliable?

    c) In any of the device based boot modes (SCI, CAN, ..), for "boot to flash", the address of the flash entry point would be used as the "entry address" in the boot data stream structure and the size of the first data block would be 0.

    d) for updating the flash, I'd use the RAM entry point as the "entry address" and the data blocks would contain the RAM based flash kernel

    e) we'll have multiple Delfinos on the CAN bus. If we use the CAN boot mode, it seem like the all have to boot in lock step since they all use the same CAN mailbox number. Either they all are booting to flash or they all are loading the RAM based flash kernel. How much variation in time is there between different chips before they're ready to accept the first CAN message (0x08AA)? Seems like any variation would be a window of time for things to get out of sync.

    Mike

  • 0 in reply to Mike McDonald1
    TI__Mastermind 19795 points

    Hi Mike,

    Thanks for the responses.

    Actually, the process can be simpler than what you described, as the host system should actually never "drive" its own RX line (TX of the C2000).

    As part of configuring boot-mode pins, SCIRX of host should be configured as pullup. Or you can "drive" the pin as you mentioned in the last post, but then you will have to ensure you stop driving the pin once the reset is exited and the C2000 is waiting for 'A'. So I would suggest just configuring your host RX as a pullup. Then the process is just:

    1) Host resets C2000

    2) Host transmits 'A'

    3) Boot-loader process here


    For the related CAN boot questions:

    a) Correct

    b) Assume CAN bus is reliable

    c)  If you are talking about “boot to flash” as a boot option, it is an entirely separate boot mode from the other ones (assuming I am understanding your question correctly). Also, see the following information from table 4-28 (LSB/MSB Loading Sequence in 8-Bit Data Stream) in the TRM discussing what a block size of 0 indicates:

    “Block size in words of the first block to load. If the block size is 0, this indicates the end of the source program. Otherwise another block follows. For example, a block size of 0x000A would indicate 10 words or 20 bytes in the block”

    d) Correct, you could then load the code to flash via this newly loaded kernel.

    e) I will get back to you with an update on this by the end of this week.

    Regards,

    Vince

  • 0 in reply to Vince
    TI__Mastermind 19795 points

    Hi Mike,

    Here's the follow-up on loading the RAM-based flash kernel on multiple C2000 devices on a CAN bus (question "e"):

    The timing difference between the devices won't be the real problem with such a setup, as they will all 1) finish the boot process and 2) begin waiting for the first CAN message. You can then begin loading the kernel to the RAM of the devices on the bus. The relative timings of the CAN communications won't be an issue when transferring the kernel to the C2000 devices.


    The issue is that the ACK responses from these nodes during the kernel loading process will all happen at the same time (since they will have the same message ID). Since all of them happen at the same time, any NACK will essentially be "drowned out" if even one ACK happens at the same time, and you won't be able to directly know if any devices failed the kernel load.

    Because of this situation, I would suggest in the custom kernel you load to the RAM of these devices, you make all nodes immediately reply with whether or not they successfully loaded the kernel. To do this, make each device respond with a unique ID.

    You can implement the unique ID with GPIOs and dip-switches on the boards and read those in and pass that on, but since you mentioned you are limited on pins, I would instead use the "UID_UNIQUE" register in "UID_REGS". Basically, transmit this value as soon as the kernel is loaded on a device, and listen for this on the host. If you know which UIDs were there to start with, you can tell which ones failed to load the kernel.


    Let me know if this clears up the question.

    Regards,

    Vince

  • 0 in reply to Vince
    Prodigy 135 points

    The timing problem is that if Delfino #1 starts accepting CAN messages at time A and Delfino #2 starts accepting CAN messages at time B, if my host sends the 0x8aa CAN message at time C, where A< C < B, then Delfino #2 won't recognize the update. So at the end of the update, Delfino #1 will be running the new version while Delfino #2 will be running the old and my host won't know that. The difference between time A and time B may be small, but if it's not zero, there's a potential problem. If TI specified an upper bound on the time, then my host could just wait long enough to be sure everyone was ready. But I haven't found that upper bound.

    The HW guys did put a 4 bit dip switch on the board for an ID. Unfortunately, they used CANA's pins for it and used CANB for the CAN port. Argh! I'm guessing they copied the LaunchPad's schematic. So I'm not going to be able to use the ROM boot loader's CAN mode anyway. So yes, I'm reimplementing the boot loader instead of using the existing one.