PK5 ISP, dW, TPI, JTAG and theoretical PDI support #1935
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dW has some hiccups on flash writes JTAG must erase chip before overwriting EEPROM
|
It's incredibly cool to see full support for the PICkit5! I just ran |
|
PICkit5 in PDI mode: PICkit5 in XMEGA JTAG mode |
|
Output from The ATtiny15 is a difficult one. I'm not even sure it's supported by the PICkit5, but I gave it a try anyways. Results below: |
|
I'm not sure, but I think I have a bug in JTAG Fuse write that doesn't correctly poll for a completed read. This might lead to a fuse write corruption. It seems like it wrote a wrong value into hfuse killing SPI and JTAG access on my 32u4. tl;dr, don't use JTAG for now. At least not when writing Fuses in quick succession. Any recommendation on how to HVPP the Arduino Leonardo without a HVPP Programmer? (With 5 bucks per chip, it would suck to loose it) Was thinking about to just write a quick sketch to do fuse reads/writes with another AVR, probably a DA with 12V coming from an external Power Supply. Oh, and I was able to get prodsig to work on isp (didn't manage to check jtag), I didn't knew they even had it as I've only consulted the docs. |
How so exactly? I mean besides the flash programming failing? According to the scripts.xml, it is supported. |
I'm not even sure the Leonardo breaks out all the necessary pins to do HVPP. Are you using the atmega32u4 to test JTAG?
IIRC prodsig and serial number was added to lots of "classic" AVRs right before the v8.0 release.
I'm not able to read any memory apart from the signature. But I'll give it a try again if you think you have a solution. BTW thank you for doing this. This PR is a BIG DEAL for the community and the Avrdude project in general. Fully supporting the latest and greatest official Microchip programmers is key to keep Avrdude relevant. I only have a PICkit4 and a SNAP to test with, but it would be really interesting to see if hte ICE4 and/or an ICD5 would work as well. They should be compatible as they use the same scripting approach, but I wouldn't conclude with anything before performing actual tests. Maybe @xedbg have access to these? |
|
Those tools are so expensive not even I can afford to order one 😬 |
|
Good news: I was able to recover the 32u4, just had to solder on 3 jumper wires and desolder a diode on the reset line. This allowed me to verify that fuses and prodsig work correctly with jtag now, no lockouts on my end anymore.
I looked at the test log again and noticed something strange - the transfer had a timeout on sernum for some reason (the 10 seconds flat is an indicator) and broke all following transactions. The only reason signature works is because I only check it once on init and just feed the buffered signature. I would be useful if you could try to read it with -vvv in terminal mode to get a better idea of what's going on.
Is there a reason why the -B32 option was used? Has it failed on a faster clock before?
This is a similar error I had with debugWire. I increased the page size here too, maybe it could help. Also, I'd like to suggest to change the usbdev_send trace output created with the -vvvv option to the same format that is used on memory reads, is this feasable? it would make debugging the data way easier then the wall of unformatted text log that is currently implemented. |
I couldn't even read the signature if I didn't reduce the ISP clock speed. I tried -B8 and -B16, but I was only able to read the signature using -B32. BTW can you add Here are a few new test8 runs using your latest commit. |
|
I've reworked the prodsig retrieval - now it retrieves all bytes at once when the first address is requested, otherwise it serves a buffer. This should fix sernum and tempsense. And with the Attiny15 - I have no idea why it doesn't work It seems however that test8 is timeouting on reading the eeprom, but the rest seems to work?. The script is pretty much the same compared to 328p, only the commands for programming are different. I wonder however, if the problem persists with other tinies aswell, like the attiny85/84. I would appreciate if somone could test them aswell |
Sure! The ATtiny15 is a strage one. R/W EEPROM does not work, and if I wait a bit before sending a new command in terminal mode, it fails: |
|
I think i have to give up on the Attiny15 - without having the chip here I won't be able to debug the problem effectively. I need to trace the lines with my oscilloscope and try out different things. I suspect it would have ended with me writing a full set of custom scripts to get it to work - which will be more work than is worth for this chip. On another note, @stefanrueger , currently I'm using the part name to identify the correct script for pickit, however I thought it would be better to use the signature as the identifier for the switch cases. This would, however, require to run the scripts_decoder.py file any time the avrdude.conf is expanded (the signature would be pulled from the conf), It would also require an installed MPLAB or rather the toolpack on the uploaders's PC. Is this feasable or would it be too much of a hassle? |
The ATtiny15 is tricky for sure. That's why I have one in my parts bin for testing. It has given us problems before, and I think really old AVRs may behave in a similar way. That's why it's nice to get it figured out. If you search for |
|
This gave me an idea actually - someone mentioned a byte access. I've checked the scripts and it seems they implemented a word access, for eeprom and flash. Reading the EEPROM just by byte seems to break the system as avrdude tells pickit to send 1 byte but it has read 2 - at least that is my best guess. |
|
Here is the -vvv output: |
|
alright, seems like I have to modify the code. Is there an easy way to check for the old AVRs like the Attiny15? |
The output was from when I tried to write to the ATtiny15 EEPROM. Do you need more logs from different memories? |
Nah, there is a problem somewhere else - I need to get the read/write length to a factor of 2. Maybe by setting the pagesize value to 2 in the .conf file? Avrdude still tried to write 1 byte only. Either I write a workaround or tell avrdude to write words. I find it weird though that the EEPROM readsize is set for the Attiny15 - but to 256 bytes while it has only 64 bytes. |
|
You'll have to instruct me, or provide a modified ATtiny15 config I can use to perform the tests you need. And ideally a command or two 😉 |
|
I've found a "mode" paramater for the memories, I hope it works as intended. |
|
Amazing! That certainly did the trick! |
|
Excellent. Now I'd like to ask you to recheck xJTAG and PDI, just to make sure I haven't introduced a regression. ./test-avrdude -e ../build_linux/src/avrdude -d1 -p "-cpickit5_jtag -p m32u4 -B400kHz -xvtarg=4.5"./test-avrdude -e ../build_linux/src/avrdude -d1 -p "-c pickit5_isp -p m32u4 -B400kHz -xvtarg=4.5"./test-avrdude -e ../build_linux/src/avrdude -d1 -p "-c pickit5_tpi -p t9 -B400kHz -xvtarg=4.5"./test-avrdude -e ../build_linux/src/avrdude -d1 -p "-c pickit5_updi -p avr128da48 -B400kHz -xvtarg=4.5" |
|
Thank you! I just left for Christmas holiday, and won't be home for about a week. I'll test for regressions as soon as I'm back |
|
A general thought came to mind: UPDI, PDI and xJTAG have a OCD messaging register. In UPDI it uses the CS Register 0x06 and 0xF18 in the data space for unidirectional communication towards the debugger. I haven't researched the other ones yet, but as PDI worked out of the box just with what I have written for UPDI, It shouldn't be too different. Some sources: |
Maybe I'm missing something. What kind of functionality for the end user will this provide? |
It would provide an extra communication channel for ebugging. Of course, due to the limited bandwith the use would be limited. Edit: I should add that I can understand if this feature would be out of the scope of avrdude - the purpose being reading and writing memories |
|
@stefanrueger would have to decide if this (debugging communication) is something that would fit into the Avrdude project. Anyways, here are some more xmega PDI and JTAG tests: $ ./test-avrdude -d1 -p "-c pickit5_pdi -p atxmega128a3u"$ ./test8 -a"-v" pickit5_pdi atxmega128a3u$ ./test8 -a"-vv" pickit5_pdi atxmega128a3u$ ./test-avrdude -d1 -p "-c pickit5_pdi -p atxmega256a3bu"$ ./test8 -a"-v" pickit5_pdi atxmega256a3bu (Several times. Not sure why it randomly fails)$ ./test8 -a"-vv" pickit5_pdi atxmega256a3bu$ ./test-avrdude -d1 -p "-c pickit5_jtag -p atxmega256a3bu"$ ./test8 -a"-vv" pickit5_jtag atxmega256a3bu |
The OCD Messaging register can be quite cool - I have some code lying around somewhere for getting it to work; but I/we never really put a full system in place, and went all-in on just using a UART on separate pins for printf. Let me know if someone wants to look into this further. (Can't remember, but I think it needs OCD enabled since its an "OCD message"). |
Sounds useful, but would need good documentation (at least in the .tex documentation) and documented application examples. Maybe have this as a separate PR after this one has been merged: the main priority for this PR should be to iron out the corner cases for r/w of memories. Thanks for the wonderful collaboration @MX682X and @MCUdude; I sense we are getting closer to finishing this with every iteration. |
|
@stefanrueger For some reason I'm getting a weird error when running test8: there is always a flash verification mismatch when running -r1 on jtag targets, but never on other tests or other programming interfaces. I've tested it on a 32u4 and on a mega2560. Is this something to be concerned of? |
I just looked AVR OCD messaging up, and this looks really interesting! It would be really cool if one could "printf" to the UPDI port instead of using UART for crude debugging. Maybe Avrdude could implement this in terminal mode? And could this be implemented for the SerialUPDI programmer as well? This could be really useful when you don't have a spare UART port. Feel free to open a dedicated issue to discus this, if this is something that could be possible to implement. |
I'd say so! Maybe first create a random contents file Then try out some versions of below Maybe try out only writing flash from that And see what happens... Perhaps |
|
figured out why jtag was failing - they are using word addresses instead of byte addressing. Luckily, I noticed the inconsistency on the end-address in MPLAB logging. About xJTAG - when I started working on the script decoder I decided to use strncmp with a length of 10 - enough for UPDI devices, but not for xJTAG, so I suspect the code might have loaded the wrong scripts, which might lead to the fails? replaced with strcmp as I can be sure that one string is definitely NULL terminated. I've also added the upcoming EC Series from the scripts. |
|
Looks like great progress @MX682X. Let the team know when you think this PR can be tested. |
|
it is ready to test, I'm just not sure if the changes that I made will have an effect. As exams are coming up, I'm not able to work much on the code right now though. |
|
Here's a new test with the PICKit4/5 in xJTAG mode connected to the ATxmega256A3BU. Looks promising! |
|
The PDI test with the ATxmega128A3U failed at the first attempt, but suceeded at the second attempt, without power EDIT: It is caused by a sloppy micro USB cable. It fails immediately if I tap the PICkit4 while it's programming. |
|
I think @MCUdude has done very comprehensive tests on this PR. I will see if I can carry out some sanity tests under Windows and Linux. |
|
the "err = No such file or directory" sounds like an error with the usb connection indeed. I also have an idea how to improve handling of transfer errors, I'll try to implement it on the weekend |
… minor adjustments and fixes
|
fixed the typo and improved error handling. I'd say it's done. |
|
I'm very pleased with this PR, and also I approve it. But there are a few tiny quality-of-life improvements that would be neat, but may be dealt with later. Let's say I have a PICkit4 that I recently used with MPLAB. If I try to use it with Avrdude ( |
|
The functionality looks great! Thanks for your contribution, @MX682X I couldn't help noticing that the
I realise that currently AVRDUDE automatically capitalises messages, but that fashion might change and it's trivial to capitalise messages but very hard to automatically lowercase messages. I also realise that a missing final AVRDUDE tends to spell debugWIRE like so, not Debug Wire or similar. Some error messages say PICkit5 (good), some PICkit (there may be a reason for this), and some Pickit 5. Please review. Sometimes messages refer to CS Reg, sometimes to CS reg (my preference). Here a sample(!) of messages that I feel should be reviewed: Note Attemting -> Attempting and reenable -> re-enable And, I absolutely agree with @MCUdude and @mcuee that this PR is a great enhancement for AVRDUDE! |
@MCUdude Good idea, but itsn't the example you give pickit4 (so outside scope of current pickit5 PR)? |
Not necessarily, because both the SNAP and PICkit4 is automatically switched to PIC mode when used with a recent version of MPLAB X. So ideally, Avrdude shouldn't care if you're trying to use a PICkit4/SNAP in PIC or AVR mode. It should only warn/tell you which mode it is in and continue the session. This PR adds support for both the PICkit4 and SNAP in PIC mode. |
|
I fixed the messaging, I hope I haven't missed anything. Also, about the PICkit4 and SNAP topic: From the user's perspective it is extremely unintuitive and non-standard to use -c pickit5 for their SNAP or PICkit4. At least the messaging should be extended on a detected programmer in PIC mode. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Chips I tested with test-avrdude successfully:
328p with dw/isp
atmega32u4 with jtag/isp
Attiny9 with tpi
A couple of caveats I noticed:
debugWire had sometimes trouble writing higher flash addresses, but it was inconsistent. Couldn't tell why (tested with 328p). An increase of the page size seemed to mitigate the problem.
JTAG can't rewrite EEPROM, at least on 32u4, so a test was failing there. To write a new value, a chip erase is needed, but this is also pointed out in the datasheet.
As I don't have an xmega, I couldn't test the xmega jtag nor PDI, but it looked so similar to UPDI that I guess it should work.