I have some hard time understanding JTAG for programming. I have an mcu that can only be programmed via JTAG. What are some easy chips to start with in order to program an mcu via JTAG? I suppose I d need a chip (mentionned in the previous sentence) in order to convert the serial data received via usb to the "JTAG-equivalent"?
I am trying to program this mcu: TM4C1294 cortex M4, which can only be programmed via JTAG.
EDIT: a lot of you guys are talking about an FTDI2232 chip. But how would you wire an FTDI chip to the mcu? I mean the ftdi chip does (as far as I know a conversion to TTL and that s it). So you would then have all your data on the TX and RX pins. But with JTAG you need a TDI,TDO, TCK and a TMS pin. So I think you need another chip to do the conversion. No?
Answer
EDIT.
That is a cortex-m based mcu, which in this case uses ARM SWD, which we use the term jtag, they call it a serial jtag which jtag was already serial but they supposedly take the four jtag signals (TMS, TCK, TDO, TDI) and serialize them, I have not dug into the details. Arm uses it because it saves signals on the core (pins on the part). Because of the popularity of the cortex-m devices and either they always used this or certainly all the current cores use this interface, it is easy to get access to tools.
Someone just asked about the connected launchpad using this part. that launchpad does a common thing that you see with eval boards today, they put a microcontroller up front that is basically a usb to jtag/swd interface, and then the target eval mcu for you to play with. the up front one is not to play with it is the debugger interface so you dont have to go buy one. often being an mcu from the same company and not a generic usb to I/O device (FT2232) it has their software with a protocol they have chosen/invented. often proprietary, sometimes secret. In this case you can use lm4flash to program it (on linux) or obviously the TI provided tools on windows. lm4 is because ti bought luminary micro which had this stellaris line of products (the first cortex-m products out), and kept the stellaris name for a little bit and the lm4 part numbers, then changed it all to tiva c at some point, but the lm4flash tool didnt change names, didnt need to. the protocol is essentially documented in the lm4flash tool.
I believe you can use the front end of the connected board for this mcu as a programmer for other mcus not on the board, there is a connector so that you can use that launchpad for programming mcus on your project and in that case you would just use the ti toolchain or something like lm4flash.
Ti also has an msp432 launchpad which again like most of these boards has an mcu up front as a usb debugger then a second one which is the eval mcu to play with. the msp432 launchpad uses a different protocol it conforms to the CMSIS-DAP which ARM I assume is trying to push to solve this problem of proprietary usb debuggers for a common arm swd interface. Will see where it goes, but like most of these boards, you can electrically or sometimes physically disconnect the debug end of the board, and use it as a programmer for their part in your project, and since it is a common arm swd interface on the mcu side you can cross brands you shouldnt have to limit yourself to ti mcus with the ti header. depends on the software used.
which leads to the stlink from st, their eval boards have an st microcontroller in front of the eval microcontroller, some of them with the debug end you can physically break off the board if you want to use it generically. and like cmsis-dap you can use tools like openocd which will allow you to specify the jtag id of the chip and basically cross brands. there are also stlink dongles you can buy without an eval mcu, but they cost 50% to several times the cost of an st discovery or nucleo board, so for my money I would just buy a discovery or nucleo board and leave it intact (that is actually what I DO) or break it off. and then just use openocd to access the device, I use this cross brand all the time stlink to talk to st, atmels, nxp, whatever. maybe someday I will try the CMSIS-DAP front end of an msp432. nice thing about the st boards they populate all the pins, others leave it so you have to like this msp432 board they populated most, but not all, I guess actually when removing the debug jumpers that gives me access...
FT2232 or other mpsse solutions from FTDI. The mpsse design has dedicated pins for uart, and jtag, you cannot simply assign any function to any pin for most or all of the supported parts. And for ARM SWD it depends on software most likely but you would look at someone who has already wired it up and posted on a page somewhere or look in the openocd source code to see what they want for those two pins. Most if not all generic jtag-ish debuggers are going to put a "target sense line" that you hook up to the power on the target mcu side, allowing support for 3.3v or 1.8 or 5v, I suspect it is the VDDIO for the target side you may be powering that end of the board (target powered rather than host powered). if you are making your own board with all of this or hand wiring a generic ftdi breakout (the FT2232 or FT4232 module is about $20 and works great as a generic ftdi breakout for all kinds of jtag, serial, anything anyone else does with an ftdi) you could of course find another 3.3v source and not have to sense. Then connect the swdio and swclk and a ground if you need to, then just use openocd.
I think j-link's support arm swd, pretty much anyone who wants to keep making jtag wigglers needs to support it due to the far and wide reach of arm based microcontrollers which are now cortex-m based instead of ARM7TDMI (which used the TDI, TDI, TMS, TCK real jtag).
Some of these microcontrollers have other ways of programming, itc, spi, serial, and some can be programmed directly with usb if they have a usb interface. None of these being jtag of course, all being proprietary protocols for that part or family or vendor, some closed some open. With the ease at which you can get ARM SWD solutions off the shelf I am seeing at least one vendor not embedding a factory programmed and protected bootloader, instead they have an open source solution to use their protocol, but that is easily erased bricking the board if you didnt provide yourself jtag. One vendor was jtag only, no other solution. st and nxp still have uart/serial bootloaders using their traditional protocols. I have not looked at everyones parts in depth, only a small sampling from the big names. this could still be a solution, or no matter what brand or core processor you can ALWAYS (okay well maybe not always for one time programmables or devices that cannot program their own flashes internally) write your own bootloader. Depending where your product is used, it is not uncommon to have mice and keyboards and things that plug into a computer have just enough firmware to enumerate then the host driver downloads the rest of the firmware, allowing for easy firmware updates to come with the driver. An early usb microcontroller the EZ-USB with an 8051 in it worked this way. this is an option for that type of a use case where there is additional software on the other side of your products usb interface. you likely still have to load some firmware to the device initially and then the rest of the firmware is downloaded on enumeration/driver init.
No comments:
Post a Comment