PK5 ISP, dW, TPI, JTAG and theoretical PDI support #1935
+13,058
−1,339
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! |
|
I hope that the test8 will work now with the attiny15 |
|
We're really close! I'm not sure what's casing this to happen: |
|
@MX682X @MCUdude Amazing progress what with thorough testing and rapid improvements for difficult chips.
That's a can of worms, which I do not recommend. Also, should you need the signature, using the part name gives you the signature, eg, through the function |
|
Daniel68Sch over at the Avrfreaks forum just tested this PR with an MPLAB ICD5. It seems like he did everything correct, but didn't get it to work. Is there anything he could provide to help out figuring out what's wrong? https://www.avrfreaks.net/s/topic/a5CV40000002aXFMAY/t398970 |
|
Send an reply there, might fix the bug with the ICD5 (if there is any that is), but I won't be that active on this PR for the next week or two, just so you know. |
|
I tend to agree that MPLAB ICD 5 may have different USB PIDs, just like the other Microchip tools. https://www.avrfreaks.net/s/topic/a5CV40000002aXFMAY/t398970
|
Without a -vvv log it is hard to figure out where exactly the hiccup happens, so if a test fails, I'd appreciate if you could redo a test with -vvv. (please don't do 4v; 3v is enough, I usually need the function calls only as 4*v gives the usb transmission an that is mostly the script content). I suspect the problem might lie in the flash size though, similar to the previous eeprom story. To make things easier, I've added an expermiental command line flag: "-xf=[flash size]". It has no checks what so ever and will be removed in the finished version. You have to run the test with different values of a power of 2. starting with 64 and going up to 1024. |
|
Here are the results. I power cycled the target and the programmer between each attempt. $ ./test8 -a"-B32" -a"-vvv" -a"-xf=1024" pickit5_isp attiny15$ ./test8 -a"-B32" -a"-vvv" -a"-xf=512" pickit5_isp attiny15$ ./test8 -a"-B32" -a"-vvv" -a"-xf=256" pickit5_isp attiny15$ ./test8 -a"-B32" -a"-vvv" -a"-xf=128" pickit5_isp attiny15$ ./test8 -a"-B32" -a"-vvv" -a"-xf=64" pickit5_isp attiny15 |
|
Well, the flash size theory was wrong, it has nothing to do with flash sizes. A: Timings. Which is unlikely, as the fuse error happens after a flash read. Still, just out of curiosity - is avrdude already handling the delays when it comes to write times or do I have to add it to the .c file? The pickit seems to handle the timing restriction fine as is though. B: A missing script instruction. This is more likely. |
|
Here's a new test with your latest commit: $ ./test8 -a"-B32" -a"-vvv" pickit5_isp attiny15 |
|
@MCUdude Seems like I have a bug on the flash size overwrite, just set -xf=256 for now while I fix the bug |
|
Here's a new test: $ ./test8 -a"-B32" -a"-vvv" pickit5_isp attiny15 |
|
This is extremely weird - Even though i removed everything that would have changed the flash size avrdude still wants to read the flash byte by byte |
|
I just tested with your latest commit. That seemed to solve the issue! $ ./test8 -a"-B32" -a"-vvv" pickit5_isp attiny15``` $ ./test8 -a"-B32" -a"-vvv" pickit5_isp attiny15 $ avrdude -B32 -vvv -c pickit5_isp -p attiny15 -D -UALL:r:bak-pickit5_isp-attiny15.hex:I -T 'fact reset' -UALL:w:bak-pickit5_isp-attiny15.hex:I -UALL:v:bak-pickit5_isp-attiny15.hex:I Avrdude version 8.0-20241221 (7725f19) Copyright see https://github.com/avrdudes/avrdude/blob/main/AUTHORSSystem wide configuration file is /usr/local/etc/avrdude.conf Using port : usb Memory Size Pg sizeeeprom 64 1 Variants Package F max T range V rangeATtiny15 N/A N/A [N/A, N/A] [2.7 V, 5.5 V] Programmer type : pickit5 AVR device initialized and ready to accept instructions Processing -U ALL:r:bak-pickit5_isp-attiny15.hex:I
Processing -T fact reset Processing -U ALL:w:bak-pickit5_isp-attiny15.hex:I Processing -U ALL:v:bak-pickit5_isp-attiny15.hex:I Avrdude done. Thank you. |
|
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 |
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.