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.

Logical question(s) for Binary-Flashing on TM4C micro-controller

Other Parts Discussed in Thread: SEGGER

Hi All.


Right now, what we do is follows ::

* Connect the PC to Tiva-Launchpad via USB.

* Connect the Tiva-Launchpad to our SOC-board (containing the micro-controller) via JTAG.

* Flash the binary from PC ==> Tiva-Launchpad (which then automatically "transfers" the binary to SOC-board).

Above works great, but there is the added complexity of the Tiva-Launchpad in between for flashing the binary.

We would like to remove this complexity.

Now, also to note is ::

* When I use Tiva-Launchpad, the USB-connection works as a logging-debugging port FOR TIVA (since it is connected to the UART0 of the chipset on Launchpad).

* Also, for the SOC, the UART0 has been exposed via RS232-ports, which we use for logging-debugging FOR SOC.

Now, my question is, is it possible (at least in theory) to connect the PC directly to the SOC (with some kind of hardware-interfacing between the RS232-ports-on-SOC and USB-port-on-PC), so that the binary can be flashed from PC to SOC directly without requiring the TIVA-board (and without writing any additional boot-loader code for SOC) ?

  • " added complexity of the Tiva-Launchpad in between for flashing the binary."

    So - vendor's board is "tossed" yet you request full detail to connect & transfer to (some) unspecified SOC? (somehow this makes sense?)

    Would not that SOC vendor be a "more likely" source for such detail?

    We note that you claim to seek, "reduction in complexity" by replacing a working system w/one (presently) unknown. And this is said to "reduce complexity!"
  • I would tend to agree with cb1' comments related to this thread. However, if you still want to pursue other programming options, I would recommend you contact a third party programming specialty supplier such as DataIO, BPMicro, SMH, etc. Note that these are not necessarily endorsements of these supplier, simply they are some that I am aware of.
  • Umm, yeah I agree with Chuck and cb1, check with your SOC manufacturer.

    Ajay Garg said:
    * Connect the Tiva-Launchpad to our SOC-board (containing the micro-controller) via JTAG.

    However, since you state that you current connect to the SOC via JTAG why not look at a JTAG based programmer? If your SOC is ARM based (or another fairly generic micro) then there is likely support available for it. More obscure cores may have support from the specialty support manufacturers mentioned.

    In any case the first question should be are there existing PC tools to program the SOC?

    Robert

  • But friends - the (whole) point of this exercise is, "REDUCE COMPLEXITY!"

    Poster reported a "known good - working system" and now, "Kicks that to the curb" to "reduce complexity!"

    It would appear that "complexity has been added" - NOT "Reduced!"

    There is (little) likelihood that posters quest (now) involves TM4C - at all!   We should not be so burdened...

  • I won't waste my time replying to grouch(es).

    Robert gave a good pointer.

    Yes, in the current scenario, the connection between the PC and the Tiva-Launchpad is over USB, and between the Tiva-Launchpad and the SOC is over JTAG.

    So, if I connect the PC directly to the SOC via a USB-to-JTAG converter, will that do the trick (i.e. without needing to write any boot-loader additonal code etc.)?

    Thanks again to all the (non-grouchy) replies.

    Thanks and Regards,

    Ajay

  • Is it grouchy to care & seek to protect this forum?

    Does your post involve use of this vendor's TM4C - at all - to "reduce complexity?"   (Ans: appears not - you've kicked TM4C to the curb)

    Your post claims "logical" yet you've replaced a known good, working system - w/one (unknown to you) - allegedly to "reduce complexity."

    As your very first reply (from this reporter) suggested - such issue should target the SOC vendor - TM4C is - at best - subterfuge here...

  • Ajay,

    Sorry if you thought my point was "grouchy" as you state. Simple fact is you are looking for a potential solution for your problem. cb1 pointed out that you are fixing something doesn't appear to be broken; but, this is your choice. My solution was to employ the production programming experts that do it for a living. I'm not quite certain how that qualifies as a "grouchy" response. None the less, good luck!!

    Also note that a simple JTAG connection will not interact with the bootloader code without a customer PC side SW development and, most likely, modifications to your bootloader. However, if you go directly to the JTAG option, a bootloader will no longer be needed for factory programming. What you might loose is the ability to log some of the information you currently log dependent on that that information is. Although, it does have some fixed logging capability. The key here is to understand what drove the current implementation and to insure any future less complex solution continues to satisfy your production needs/requirements.

    Another key thing to keep in mind if you go straight to JTAG is that the length of the connecting wires is important since reflections can impact the programming. Use of appropriate terminators will solve this issue, though.
  • I would expect so, particularly if it's a core supported by an adapter/programmer company such as those earlier listed. If an ARM core check Segger they do a variety of specific implementation including IIRC some SOC versions.

    Your SOC supplier may well have approved adapters as well.

    Robert
  • I'd call replacing a custom JTAG lash-up with a commercial adapter a reduction in complexity myself, not apparently TI related I agree.

    Robert