TM4C123GH6PM: Software for debug with TM4c1294NCPDT

Are you sure that, "Adding such (program & debug) MCU to your board" - makes the most sense?

Normally/customarily the "JTAG/SWD" Probe is NOT "board resident."     This is so as the, "Size, Cost & Complexity" of your planned board(s) will increase due to the "extra MCU's (and support circuitry's)" inclusion.     In addition - should you experience, "JTAG Lock-Out" (Not a rarity here) you cannot easily, "Move your JTAG Probe to "Next Victim/board" - and thus quickly easily localize & identify the likely problem.

In addition - is it "locked in concrete" that you will (never) seek (another's) ARM MCU?      (i.e. an: M0, M3, M7 - unavailable here)      What then?      Those w/"much experience" will usually choose a JTAG/SWD Probe which proves, "Vendor Agnostic" - even better if it has (long) pre-existed "single vendor offerings" - and has proven more capable & robust...

Convention exists (often) for good reason.   "Culling yourself from the herd" - on (plains) Silicon or Serengeti - may yield an unfortunate outcome...

Hi Bob,

thank you for your aid so far. If I program the TM4C123G to ICDI, can I program the TM4C1294NCPDT using USB via the TM4C123G or do I have to Bootload the TM4C1294NCPDT as well?

Jonas.

Bruno Saraiva said:

Are you trying to create your own development kit? That would be the ONLY reasonable situation in which to add an USB ICDI ARM interface to your project.

A very particular kind of development kit (and one with multiplied support costs)*. You can make a development kit w/o an on board JTAG interpreter

Bruno Saraiva said:

cb1's reply is actually what you need to hear... Even if using his Shakespearian language... ;)

I'll vote for that as well. Third party tools have some or all of the following

• Avoiding vendor lock-in
• Proven over multiple vendor's chips and customers
• Support for more than the micro
• Additional Utilities (If you can use these they can pay for adapter themselves)
• A lot more robust than running flywires from a Lanchpad.

Figure out how much time you have to save to pay for the tool. For a professional it's not very much.

Robert

* I don't have any inside figures but I rather suspect TI spends as much or more in ICDI support as they do for the chips.

Be (very) still - my aged - yet at least for today - not completely, "Avoided/Glossed Over" Heart!    (364 "other" days arrive for that...)

Receiving the "banned" ** LIKE ** - from 2 (fellow) outsiders - AND the vendor agent - (almost) reduces the pain from my swollen foot...

Hi everyone,

Thank you all for your information. It is true that I should have thanked CB1 and what he says is indeed very helpful. However, I want to use the TM4C1294NCPDT in a sensor board that has to be able to be reprogrammed from a distance over a network. Therefore, we will attach the board to a on-site computer by ethernet for data transfer and by USB for power and reprogramming. So, for easy reprogramming, I chose for the extra TM4C in order to avoid having to place extra interfacing on site. It would have been easier if I could sent my data by USB also, but unfortunately the maximal data rate for USB is barely enough.

Jonas.

Jonas,

Interesting "Problem XY" situation.

You don't seem to need to discover "what software for debug with TM4C...". You need to know how to update a TM4C firmware in the field!

For some reason, you were led to believe USB speed "is barely enough"... (Yet, if you think about it, it is still a USB connection who is carrying your JTAG debug into the lauchpad). Tell you what: we update firmware on the field via Bluetooth LE, it does not get too much slower than that!

Do some research in the forum, related to firmware update and mostly bootloader. If a physical connection is the best option for you, just add a UART port to your board with a RS232 transceiver. Those low cost USB/RS232 adapters are available everywhere, and your field guys would be able to update the firmware using an easy to find hardware. Alternatively, you can work a bit further on your hardware and software, and implement a direct USB connection to your target board.

Do think twice as to fall into a situation that would require actual DEBUGGING in the remote location, if your project comes to it. There is probably a better way around, and probably you can test your project away from the "hazardous unreachable" area, even if you just need to allow for some adjustable control parameters to be fine tuned later on.

Cheers

Bruno

Bruno Saraiva said:

Interesting "Problem XY" situation.

You don't seem to need to discover "what software for debug with TM4C...". You need to know how to update a TM4C firmware in the field!

Yep, debug has morphed into remote update.

A bootloader and an external SPI flash is likely a better approach in a number of ways.

Bruno Saraiva said:

For some reason, you were led to believe USB speed "is barely enough"... (Yet, if you think about it, it is still a USB connection who is carrying your JTAG debug into the lauchpad). Tell you what: we update firmware on the field via Bluetooth LE, it does not get too much slower than that!

And at some point the limit is flash programming and erasing time not communications. As you say USB is quite fast, you really have to go to Ethernet to match or exceed it.

Bruno Saraiva said:

Do think twice as to fall into a situation that would require actual DEBUGGING in the remote location, if your project comes to it. There is probably a better way around, and probably you can test your project away from the "hazardous unreachable" area, even if you just need to allow for some adjustable control parameters to be fine tuned later on.

Amen to that, the more testing you can do away from the field/restrained access the better. Sometime it's unavoidable though.

There are ways of doing it that do not require JTAG as you point out. Indeed until quite recently JTAG was not available for this purpose. Also keep in mind that even if JTAG is available, many of its features wouldn't be appropriate to use for some environments*.

Robert

* None of the PLCs I've used have single stepping or breakpoints. They're not generally considered appropriate.