Role and development of firmware to program other microcontrollers using TM4C processor with TM4C itself performing a specific task.

Shantam,

So the origin of your question is a question, but you pose the theory of the question as fact which it is not. But, if the other devices are uC based which CC2650 and CC1310 are, then you should be able to send data to them over UART or any other communication interface they and the host controller support. Theoretically, this data would actually be code that would run in RAM of the target device (CCxxxx in this case) and would provide the interface to receive the new binary and program it into the devices program memory. Once the algorithm was transferred into the target's RAM you would need some mechanism/command to execute the algorithm from the RAM of the target so it could host the reception of data from the host processor. I am am not certain how much RAM is on the CCxxxx devices but this could be an obstacle if the interface needs are excessive.

A secondary method would be to implement an emulator functionality  similar to our XDS110 which uses the TM4C129 as the on board uC to carry out the interface activities. In this case, the the firmware of the TM4C129 could set up the HW interface to the target as JTAG which would give access to allow program flow modifications and jump to RAM execution or even direct access to the target flash/program memory dependent on the architecture of the target.

So, to give a very short synopsis, anything is possible within this context if given the proper on chip resources/IP and sufficient performance is available on both the target and host uCs.

To answer your final question:

Shantam Raj23 said:

However what intrigues me is that apart from programming those ICs does the debugger do anything else, like is it running any firmware when the Launchpad is powered ON ? Do i as a developer have access to that firmware, can i change that firmware to do more that it is supposed to ? 

The TM4C129 on the XDS110 is running firmware that is proprietary to TI as far as I know. It is possible that it may be available as a binary but I doubt that it would be available as source. This firmware does something similar to what I describe above; although, I do not have all the details available to me regarding the specific implementation. Given this device/emulator already exists, why would you need to recreate it? And note that this is only the firmware side as there is also a requirement to provide drivers for the PC/MAC side and interface with the IDEs that are being used.

Hello Chuck,
Sorry for posing the question in an ambiguous way.
Some things got cleared from your reply, however i am still not able to properly understand a few things-
Lets take a specific scenario : I have a 3rd party uC and i have interfaced CC1310 with it. Now by default the there is nothing in the flash or ram of CC1310. I would like to program CC1310 using my uC. Its important to note that my uC not only programs CC1310 but also runs firmware that processes sensor data and indulges in communication with CC1310 and maybe other ics, sensors etc.
Now you will realize that the firmware that is given to the uC by the user has roughly 2 parts. One that completely runs on the flash/ram of CC1310 and the rest that runs on uC itself. However since the CC1310 part is useless after programming it, the uC gets rid of the firmware for CC1310 once its done programming it.
Is this how one would professionally design a system or would use a different approach ? If one would use a different approach then can you explain more about how to go about doing it?

Thanks Chuck, now i got a clear picture.
Just one more question :
Implementing the CS functionality manually or howsoever is okay with me. What i want to know is that are the JTAG firmwares different and proprietary to different manufacturers ? Do we have open source JTAG firmwares ? If yes then will they necessarily work with CCxxxx devices? If not, Will TI provide its JTAG firmware to developers ?

The TM4C launchpads use the ICDI interface which is proprietary to TI, however, several other JTAG emulators also support TM4C such as the XDS100v2 and XDS200. I would guess that these other emulators also support the CCxxxx devices but can't confirm this since this is another group in TI and I don't have that expertise.

In regard to JTAG firmware, emulators such as the XDS100v2/v3, XDS200, XDS110, etc would all have their own firmware implemented in support of their own feature sets and relative to their performance capabilities. The firmware and the JTAG modules on the target devices should all conform with the JTAG standard (with some variability due to feature sets and capability). Each of these emulators have associated drivers on the PC that bridge the gap between the IDE or programmer and the JTAG hardware all the way to the device interface.

I guess what I am trying to get at here is that this is a somewhat complex set of software not limited to firmware on just the emulator, target, or PC and would be a very detailed undertaking for someone to take on. The easier approach if you want to do some custom device programming is to avoid the JTAG interface altogether and use a boot loader (examples for TM4C area broadly available) . In this case, a host device could be the intermediate device in a programming chain as discussed. The interface can be a simple SPI, UART, CAN, Ethernet, USB dependent on whats available. The question I can't answer is what is the capability of the CCxxxx devices. They are M3 based MCUs with a different architecture and, I believe, flash technology so the flash wrapper code that would be used to program them would be different than the TM4C.

I apologize for the circular discussion, but, again, I am puzzled by your desire to make your own JTAG interface device with so many options available off the shelf.

Okay, i believe i will drop my initial thought of making a design with inbuilt JTAG, rather i will use off the shelf JTAG Programmers that are available for programming various chipsets manually.
Thanks for your advice Chuck.