add JTAG support to avrftdi #1324
Conversation
|
@jkent Thanks for your cotribution! Two quick comments
Other than that, once both above are addressed someone on the team can do a review (may take some time...) |
|
Thanks for your contribution! Sadly, I don't have any hardware I can test with, but this will in fact be the first non-official hardware that supports AVR JTAG programming!
@stefanrueger I do agree that leaving old code (formatting) like it already is is a good idea, but I'd argue that "new" code should follow a loose standard to match the look and feel of existing code. Most of the code base already uses two white spaces as indents. We should continue to do this. |
jkent
force-pushed
the
avrftdi
branch
3 times, most recently
from
f58cad4
to
d9f4586
Compare
|
Sorry for the noise. Should be good now. I'm not a Windows programmer. :) Thanks for the feedback. I left the formatting in the style of the original. |
|
Wooops, regression fixed from checking out my main branch during reformat. I have another JTAG programmer that works, but it uses code on an ATmega16u2. I still need to publish that code. If interested, I've added support to AVRDUDE for it too. It is dual role where it by default acts as a USB serial adapter, serial break signal switches to programming mode where it does JTAG operations. Its not nearly as fast as the FTDI MPSSE, but it could be useful to somebody. |
|
Thanks @jkent Out of curiosity:What's the significance of tdi, tdo, tck and could they be overlaid to sdi, sdo and sck? Not suggesting they shoud, but if they are essentially the same functionality a simpler overlay in lexer.l could be sth like Externally you could use tdo, tdo, tck but within the program it would be SDI, ... |
|
They are the JTAG signals. In terms of the MPSSE, they use the same pins, but on other bitbanging hardware they could have different functionality. I added them for completeness. They also keep you from being confused about the data direction, as the ISP signals are in terms of the host, where the JTAG signals are in terms of the device. |
|
Thanks for explanation (so sdo corresponds to tdi?). All good. |
|
That is correct! In terms of the programmer SDO is an output, and TDO is an input. |
That would be nice to have as well -- probably in a separate PR. I assume the FW can be ported to ATmega32U4 (and therefore Arduino Pro Micro or Leonardo). |
|
It is nice to have FTDI MPSSE to work with AVR JTAG. It will open up quite some JTAG adapters to use with AVR JTAG as there are many adapters which are based on FT2232H (mainly for ARM chips using OpenOCD). |
src/avrdude.conf.in
Outdated
| #------------------------------------------------------------ | ||
| # tumpa-jtag | ||
| #------------------------------------------------------------ | ||
|
|
||
| programmer parent "tumpa" | ||
| id = "tumpa-jtag"; | ||
| desc = "TIAO USB Multi-Protocol Adapter (JTAG)"; | ||
| type = "avrftdi_jtag"; | ||
| sck = ; | ||
| sdo = ; | ||
| sdi = ; | ||
| tck = 0; # TCK 9 | ||
| tdi = 1; # TDI 5 | ||
| tdo = 2; # TDO 13 | ||
| tms = 3; # TMS 7 | ||
| reset = ; #4; # RST 15 | ||
| buff = ~11; | ||
| prog_modes = PM_JTAG; | ||
| ; | ||
|
|
There was a problem hiding this comment.
Please use the output of avrdude -ctumpa-jtag/s (the canonical form as understood by avrdude) for the avrdude.conf.in entry. Also, it would help us and improve avrdude.conf if if you could replace the pre-existing (meaningless) comment submitted as bug #46020 with a suitable URL for TUMPA.
There was a problem hiding this comment.
Maybe using this URL.
https://www.tiaowiki.com/w/TIAO_USB_Multi_Protocol_Adapter_User%27s_Manual
There was a problem hiding this comment.
This is the output of avrdude -ctumpa-jtag/s. Is it sutable? or would you prefer a complete new device entry (with usb vid/pid) without the disabled reset/sck/sdo/sdi signals?
#------------------------------------------------------------
# tumpa-jtag
#------------------------------------------------------------
programmer parent "tumpa"
id = "tumpa-jtag";
desc = "TIAO USB Multi-Protocol Adapter (JTAG)";
type = "avrftdi_jtag";
prog_modes = PM_JTAG;
buff = ~11;
reset = ; #4; # RST 15
sck = ;
sdo = ;
sdi = ;
tck = 0; # TCK 9
tdi = 1; # TDI 5
tdo = 2; # TDO 13
tms = 3; # TMS 7
;
There was a problem hiding this comment.
Ignore this, as per @mariusgreuel , I will parent this off of ft2232h_jtag.
There was a problem hiding this comment.
I had a quick look through the code; it's well written and I did not spot any obvious problems. Once we have an independent functional test (@mcuee?) I think we can merge your contribution. Thanks again
|
I need to figure out the connection first. The following connection does not seem to work. JTAGKey2 to FT2232H map:
JTAGKey 2 Diagram (JTAGkey 2 using FT2232H, JTAGKey using FT2232L). |
|
Debug log. Click for the detailed debug log with -vvvv |
|
@mariusgreuel |
|
Hi @jkent, thanks for the PR! Have not tried using the programmer yet, but your code looks good! One note: A lot of people (like myself) have generic FTDI breakout boards, such as the Adafruit FT232H, FT mini modules, etc. I think we can make your FTDI JTAG programmer available to a bigger audience (plus ease testing for myself) if we include configs for generic FT232H and FT2232H boards. My suggestion would be to add two new configs such as |
|
@mcuee I'll take a look at the ATmega32A manual in a bit to see if there are any differences with the programming protocol. I did not implement byte by byte read/write because of its speed, but maybe some chips need it? |
I tend to think my issue is more related to connection as it failed to read the device signature. I will try again later with ATmega128A to see if that makes any difference. Let's see if @mariusgreuel can have a positive result. |
|
I think your current code will not work with my JTAGKey 2 as there are two pins to control the reset signals. Openocd uses the following convention. Relevant codes to deal with different configuration of FT232H/FT2232H/FT4232H or similar. For tumpa. For JTAGkey2 Other files of reference to avrdude from OpenOCD |
|
@jkent @mariusgreuel @stefanrueger Still I am okay if we just get the current code merged without modifications. At least many adapters will be supported with the current pull request. Only things like JTAGkey and KT-Link will not be supported. KT-Link
|
Can AVRDUDE's model of pins and external devices cope with the need to control two pins to set the reset signal? What I am trying to get at is there a way the current code base can do this at all with only small changes? Would a hardware mod (cutting wires, some pullup/pulldown for one of the signals) be an alternative?
OK, will merge on the next mergefest, may actually be today's (European ) evening, unless I hear from you to the contrary @jkent @mariusgreuel @MCUdude @mcuee. |
|
I just tried a few things, today not much seems to work, not my day. Quitting now and saving a serious look at this for another day. I do not have a m128rf, so I took a m32u4 (the JTAG commands look identical at first glance). Some sanity checks: SUCCESS: MSVC with custom libftdi/FTDI driver, FT232H via ISP: D:\Work\avrdudes\avrdude>out\build\x64-Debug\src\avrdude.exe -c ft232h -p m32u4
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9587 (probably m32u4)
avrdude done. Thank you.FAILED: MinGW64 with stock libftdi/libusb0 driver, FT232H via ISP: $ ./build_mingw64/src/avrdude.exe -c ft232h -p m32u4
E avrftdi_open(782): Error -4 occurred: usb_open() failed
avrdude error: unable to open programmer ft232h on port usb
avrdude done. Thank you.FAILED: Linux/Ubuntu 22.04 with usbipd-win, FT232H via ISP: marius@Zeus:/mnt/d/Work/avrdudes/avrdude$ ./build_linux/src/avrdude -c ft232h -p m32u4
E avrftdi_open(782): Error -4 occurred: usb_open() failed
avrdude error: unable to open programmer ft232h on port usb
avrdude done. Thank you.SUCCESS: MSVC, Atmel ICE via JTAG: D:\Work\avrdudes\avrdude>out\build\x64-Debug\src\avrdude.exe -c atmelice -p m32u4
Vtarget : 5.01 V
JTAG clk prog. : 1000 kHz
JTAG clk debug : 1000 kHz
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9587 (probably m32u4)
avrdude done. Thank you.As only the MSVC build works with the FT232H, I just tried the ft232h_jtag programmer with this configuration. It seems like the D:\Work\avrdudes\avrdude>out\build\x64-Debug\src\avrdude.exe -c ft232h_jtag -p m32u4
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x800021
avrdude error: expected signature for ATmega32U4 is 1E 95 87
double check chip or use -F to override this check
avrdude done. Thank you.
D:\Work\avrdudes\avrdude>out\build\x64-Debug\src\avrdude.exe -c ft232h_jtag -p m32u4
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x21e100
avrdude error: expected signature for ATmega32U4 is 1E 95 87
double check chip or use -F to override this check
avrdude done. Thank you.
D:\Work\avrdudes\avrdude>out\build\x64-Debug\src\avrdude.exe -c ft232h_jtag -p m32u4
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0xe19080
avrdude error: expected signature for ATmega32U4 is 1E 95 87
double check chip or use -F to override this check
avrdude done. Thank you.Note sure what is going on. I used a direct connection, no pull-ups/downs. I have no experience with the JTAG/AVR protocol, but I am wondering:
@mcuee I can't remember whether I tried the FT232H programmers with MinGW/libftdi/libusb0, do they still work for you? |
|
Decided to leave this PR hanging around until the next time as there might be a few insights that come from more testing... |
I was using MinGW/libftdi-1.0/libusb-1.0 with my FT2232H based JTAGkey 2 and it worked fine last time. I will check again the ISP mode with latest git and this PR to see if there are any regressions. As for MinGW/libftdi-0.1/libusb-win32 or MinGW/libftdi-0.1/libusb-compat-0.1 combination, I have not tried it since libftdi-0.1 has not been updated for a long time (last commit was on 2014-12-23, last release was on 2012-03-19). |
|
I reviewed all |
I tried adding
This didn't work very well: |
|
@MCUdude Thanks for testing. Admittedly, my ideas were a tad bit naïve (as was the allowfullbitstream shout b/c this parameter isn't used at all here). |
|
Something worth trying is adding some JTAG clocks in the Run-Test/Idle state. I need to port over my overhauled Python code that does FTDI JTAG, it would make this much better/easier. (I've written some nifty debug code that uses the undocumented OCDR register) |
Just wondering if you can add some debug message to this PR (for the JTAG functions) to help debugging this issue. Thanks. |
|
Another option would be to document that this programmer does not work for older JTAG parts and make sure the code does not try to, for example by |
I think this is the way to go for now. This PR is a significant improvement for avrdude so it is worth to merge even with the known issue. |
|
Agreed! What is here is here, more can be added when ready, just a clear message / warning what is working already and what needs work would be nice :-) I am following the thread but am too overworked right now to test / help at the moment please forgive me! |
We actually don't know. We only hypothesise that this PR works for classic JTAG parts other than ATmega(16|32|64|128)(A|). We also know that this PR won't be able to read/write the |
|
@jkent Here another idea what the problem might be: the JTAG sequences for the ATmega32U
and the ATmega16
are actually different! Similarly, flash write seems to want the extended address byte, too, for the ATmega32U. Your PR implements the protocol variant with the extended address bytes. If that hypothesis is correct then it's this line in Should this get us further then it's a bit of work to go through the data sheets of the 80 parts that support JTAG to see which is which. This command gives the list of JTAG parts: The good news is that many of these parts are covered by a single data sheet, so there are a lot fewer than 80 data sheets to consult. Once that is figured out there might be a simple proxy, eg, or we might have to invent a new bit for the to distinguish these two different protocols and a corresponding |
stefanrueger
dismissed
their stale review
Approval withdrawn b/c it turns out there are (at least) 2 different JTAG protocols that need to be catered for.
|
Another idea is to check whether the JTAG LEA sequence is needed for parts that don't actually have a 22-bit PC. If so, might work as well. Depends on implementation of the JTAG protocol in the chip. I would feel slightly more happy if the data sheets supported that approach somehow, eg, if it mentioned that the LEA sequence is optional for small parts. |
I tried both of these in avrftdi_jtag_paged_write() and in avrftdi_jtag_paged_load(). However, the result is the same when reading the ATmega16 flash memory. The flash is empty, but Avrdude still reports that there is content: |
|
Oh well, so there is only one protocol after all, and I guess it's optional to send the JTAG LEA sequence with the address (if the size of flash doesn't require it). So we are back to square one. |
|
I've just tested this PR with the following hardware, and I'm able to read and write to flash without any issues on all of them:
I wasn't able to get the ATmega162 working, but I suspect it is a hardware issue of some sort: |
|
Thanks, that's great. What about the ATmega2560 and AT90CAN64? @jkent @MCUdude @mcuee BTW, how is the TCK frequency controlled for the communication? The data sheets say "During programming the clock frequency of the TCK Input must be less than the maximum frequency of the chip." How does the code ensure the TCK frequency is not too fast? |
@mcuee had already tested the ATmega2560 with success, and it turned out that I didn't actually own a CAN64, only a CAN128. However, I see no reason why these should behave differently.
By using the -B flag. It does in fact slow down the programmer but doesn't resolve the ATmega16/32/64/128 flash read issue, sadly. I'm not sure how we could get to the bottom of this. But other than these four chips, I think the PR is good to go |
|
Here a summary of what works and what does not and what is not tested. Parts that appear on the same datasheet are put on one line; it's assumed if one of these works then the others do too:
What do people make of this?
As it's the flash read routine that might go wrong, it's easy to imagine things can silently go wrong (not good). |
|
I have updated the above table after testing ATmega64A. It failed as expected. To me we can merge this PR and not to program known-bad parts ATmega8/16/32/64/128(|A). |
|
I'm comfortable with this option:
I'm pretty confident that only the "older" parts don't work. And as long as this PR doesn't affect other programmers/parts in any way, I'm fine with merging this. However, we should try our best to make it work for the old parts as well. |
The use of exit() is brought about by the fact that, unlike all other programming functions, pgm->enable() is of type void, ie, cannot easily tell the caller something went wrong.
|
This PR should now be ready for merging. @mcuee @jkent @mariusgreuel @MCUdude: final tests/comments, please. I've resolved the merge conflict and added code that rejects programming parts that are known to be incompatible with avrftdi_jtag. I opted for exit(1) in the This PR won't be able to read/write the usersig memory of ATmega*RF(A1|R2) parts, see PR #1406. That would require someone with such a part to code this. |
Added tumpa-b and tumpa-jtag to config
JTAG tested at 8MHz, example of reading 128KiB flash: