PK5 ISP, dW, TPI, JTAG and theoretical PDI support #1935
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 |
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.