Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update signature row with tuned OSCCAL value #1

Open
nerdralph opened this issue Jan 31, 2021 · 18 comments
Open

update signature row with tuned OSCCAL value #1

nerdralph opened this issue Jan 31, 2021 · 18 comments

Comments

@nerdralph
Copy link

A few years ago I started working on a HV OSCCAL tuner that uses undocumented commands to modify the signature row calibration values. I got a prototype version working, and then started work to discover how to do it without HV. I was able to erase the signature page, but a couple attempts to brute force search for the write signature page command did not succeed.

I never got around to cleaning up the code, but after seeing your project I thought it would be a useful feature in HV mode to skip the use of EEPROM and just modify the OSCCAL value that gets loaded on reset. Here's the code:
https://github.com/nerdralph/piggy-prog/tree/master/PiggyTune

@wagiminator
Copy link
Owner

That would of course be fantastic. I was annoyed that the calibration bytes cannot be written to. When I find a little more time again, I try to understand your code and implement it for the calibrator.

@wagiminator
Copy link
Owner

I can't get it to work. If you have some time, please have a look:

`
// HVSP load flash page
void HVSP_loadPage(uint8_t addr_low, uint8_t data_low, uint8_t data_high) {
HVSP_sendInstr(addr_low, 0x0C); // Instr1: address low byte
HVSP_sendInstr(data_low, 0x2C); // Instr2: data low byte
HVSP_sendInstr(data_high, 0x3C); // Instr3: data high byte
HVSP_sendInstr(0x00, 0x7D); // Instr4
HVSP_sendInstr(0x00, 0x7C); // Instr5
}

// HVSP write signature page
void HVSP_writeSigPage(void) {
// erase signature page
HVSP_sendInstr(0x80, 0xCC); // Instr1: modified chip erase command
HVSP_sendInstr(0x00, 0x64); // Instr2
HVSP_sendInstr(0x00, 0x6C); // Instr3
HVSP_BUSY_WAIT(); // wait for erase cycle to finish
HVSP_sendInstr(0x00, 0x4C); // no operation command to finish erase

// load flash page
HVSP_sendInstr(0x10, 0x4C); // command to enter flash programming mode
HVSP_loadPage(0x00, signature >> 16, outCALIB0); // write signature 0 and calibration 0
HVSP_loadPage(0x01, signature >> 8, outCALIB1); // write signature 1 and calibration 1
HVSP_loadPage(0x02, signature, 0xFF); // write signature 2

// flush signature page
HVSP_sendInstr(0x93, 0x55); // Instr1
HVSP_sendInstr(0x00, 0x45); // Instr2
HVSP_sendInstr(0x00, 0x35); // Instr3
HVSP_BUSY_WAIT(); // wait for write cycle to finish
HVSP_sendInstr(0x00, 0x4C); // no operation command to finish erase
}
`

@nerdralph
Copy link
Author

nerdralph commented Feb 4, 2021 via email

@nerdralph
Copy link
Author

Here's one of the avrfreaks discussions about the signature commands.
https://www.avrfreaks.net/comment/165751#comment-165751

@wagiminator
Copy link
Owner

These are exactly the same instructions. I would agree with you that the first problem is with erasing the signature page. Since that does not work, writing to the page cannot work either.

@nerdralph
Copy link
Author

I recall testing the AC C0 00 00 command to erase the signature page which is mentioned here:
https://www.avrfreaks.net/forum/undocumented-signature-row-contents?name=PNphpBB2&file=viewtopic&t=140556

It's been a while since I was working on this. The couple of files I found have dates from the summer of 2018. I'm certain I was able to erase and then re-program the signature page, but it's possible I was using the ICSP (low-voltage) command to erase the page, and then using the HV command to re-write the page.

I still plan to re-assemble my HV programming circuit, though I'm not sure how much more work I'll do on the OSCCAL tuning. As you probably have noticed, it's primarily the t13 that needs OSCCAL tuning. All my t85's have been within 1-2% of spec. And for people that want a simple way to tune the speed, I wrote picoboot-lib, which is an Arduino compatible serial bootloader with automatic OSCCAL tuning.

@wagiminator
Copy link
Owner

This is obviously an ICSP command. I will test it, but it will take a while, because I have to deal with the ICSP protocol first.
In fact, the ATtiny13 in particular needs OSCCAL tuning, but as you may have noticed, I like to use it a lot ;-)

@wagiminator
Copy link
Owner

So, I quickly implemented the ICSP protocol (it's even easier than HVSP), but unfortunately I still can't erase the signature page ;-(

@nerdralph
Copy link
Author

So, I quickly implemented the ICSP protocol (it's even easier than HVSP), but unfortunately I still can't erase the signature page ;-(

That's interesting. I didn't have these problems, and I had found at least 2 other people on avrfreaks that had tested the undocumented commands. That leads me to two explanations:

  1. Atmel/Microchip changed the method of factory programming the signature row.
  2. You have a clone MCU which implements the documented functionality, but not the undocumented functionality.

Have you ever used debugWire on these t13s? Although it is documented in the datasheet that debugWire is supported, the actual protocol was never documented by Atmel. This would make it difficult for a clone to properly implement debugWire.
dwprog is my preferred debugWire tool:
https://github.com/nerdralph/dwprog

@wagiminator
Copy link
Owner

Aha, the second point might apply. I bought 50 ATtiny13A for € 10 on aliexpress. I'll try that with a few other chips (hopefully my ATtiny85 are original). However, if that is the problem, then either it makes no sense to implement this feature in the calibrator, or I would have to run a test before calibrating.

@nerdralph
Copy link
Author

I agree. The mere presence of clones that don't work diminishes the value of the technique. And at the same time, it probably increases the need for tuning as a clone manufacturer is less likely to tune and program each die.

@wagiminator
Copy link
Owner

I have now tried it with several ATtiny13/25/85 in DIP and SMD packages, unfortunately still without success. But as far as I can remember, I bought all of them on Aliexpress, so that doesn't mean a lot. Of course, there is also the possibility that I have a mistake somewhere.

@nerdralph
Copy link
Author

I started playing with HV programming again yesterday. Partially killed one of my t13s. I have an updated circuit with a PNP+NPN (similar to your pFET + NPN setup). Over the next few days I hope to at least have a schematic + code that works, so you can try to duplicate it.

The fact that you've tried multiple different parts leads me to believe there's something different in your setup than mine. I wouldn't rule out one batch of your AVRs being clones, but it seems unlikely all of them are. I think about half of my 8-pin AVRs were purchased from Asia.

It may be a red herring, but I had found the HVSP wasn't as simple as following the datasheet instructions, and the t13s I tested had significantly different timing than the t85s.
http://nerdralph.blogspot.com/2018/05/piggyfuse-hvsp-avr-fuse-programmer.html

@nerdralph
Copy link
Author

I'm not able to get the "0xAC 0xC0 0 0" to erase the signature page either. I tried 2 t13s (SOIC & DIP), a t85, and a DIP t88 that I bought from Newark/Element14. However I know there is a way to erase the signature page because I built the HV programmer and re-wrote the signature page after I accidentally erased the signature page during regular programming when I forgot to connect VCC and ended up powering the target AVR through the protection diodes on the SCK and MOSI lines. The signature and calibration all read as 0xFF, and with the HV command I was able to restore the signature and OSCCAL.

Back in the summer of 2018, I wrote a program to try to find the LV serial programming command to write the calibration page by partial brute force. I was guessing what the first command byte would likely be, and the program runs through all 16.8 million possibilities for the next 3 bytes.

I think I'll move on to testing the HV commands. Once I get that working again I'll document my exact hardware & firmware setup so you can try to duplicate it.

@wagiminator
Copy link
Owner

Then I wish you maximum success! It remains exciting.

@nerdralph
Copy link
Author

I did a bunch of testing this eve, and got it to work on the 2nd t13 DIP I tried:

HSVP fuse resetter
1E 5C 90 5C 7 FF FF FF FF FF FF FF FF FF 57 34 33 30 37 30 FF 9 4C 38 17 4 12 22 13 22 EE 9
Signature: 9007
OSCCAL: 5C
Found 0x5C OSCCAL, trying erase
LFuse: 76, HFuse: FF, EFuse: FF, Lock: FF
68 us lock bit read time.
Detected t13.
Debug fuses programmed.
8856 us.
Signature: FFFF
LFuse: 76, HFuse: FF, EFuse: FF, Lock: FF
Done. Reset programmer to run again.
▒▒▒▒
HSVP fuse resetter
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Signature: FFFF
OSCCAL: FF
LFuse: 76, HFuse: FF, EFuse: FF, Lock: FF
68 us lock bit read time.
Blank signature. resetting to t13 0x5E OSCCAL
missing signature.
No fuses programmed.
24444 us.
Signature: 9007
LFuse: 76, HFuse: FF, EFuse: FF, Lock: FF
Done. Reset programmer to run again.

I don't recall where I bought them, or even if I bought both of them from the same supplier. The extended signature bytes were quite similar on both.

@wagiminator
Copy link
Owner

Congratulations! So it works, but not with every chip? Did you use a t13 or a t13a?

@nerdralph
Copy link
Author

Congratulations! So it works, but not with every chip? Did you use a t13 or a t13a?

Both t13a, and both with the same date code of 1430, so I likely bought them together from the same supplier. The underside of the DIP package has TAIWAN in the circle, so that's probably where they are made.

If I'm feeling more adventurous, I may hook up the scope and compare the the two parts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants