search

avrdudes / avrdude

AVRDUDE is a utility to program AVR microcontrollers
GNU General Public License v2.0
724 stars 137 forks source link

JTAG signature write #1527

Closed stefanrueger closed 11 months ago

stefanrueger commented 11 months ago

There are a couple of ..._write_byte() routines that contain code for writing the signature page, eg, https://github.com/avrdudes/avrdude/blob/cbac6349b02ae72ec3ed2b345efe8f121d846547/src/jtagmkII.c#L2374-L2378

Is that a thing? For which parts could jtagmkII programmers actually write the signature (or calibration)?

mcuee commented 11 months ago

@stefanrueger

The following issue is related to Calibration. Supposedly AVR JTAGICE mkII is able to carry out calibration but it is not supported by avrdude.

I have closed that issue. We can re-open if needed.

mcuee commented 11 months ago

The above issue #71 mentioned that AVR JTAGICE mkII is able to carry out calibration.

Indeed page 30 of AVR067 mentions the command. CMD_OSCCAL: Performs OSCCAL calibration sequence

AVR067: JTAGICE mkII Communication Protocol https://ww1.microchip.com/downloads/en/Appnotes/doc2587.pdf

Page 62 mntions the memory type OSCCAL_BYTE.

Memory type EEPROM_PAGE uses page write and byte read. Memtypes FUSE_BITS, LOCK_BITS and OSCCAL_BYTE use byte read and (write). The address sent to JTAGICE mkII is byte address for all memory types. Only the start address needs to be supplied.

mcuee commented 11 months ago

Other than OSCCAL_BYTE, I think XMEGA_USER_SIGNATURE can be read/write as well.

mcuee commented 11 months ago

For JTAGICE 1: AVR060: JTAG ICE Communication Protocol https://ww1.microchip.com/downloads/en/Appnotes/doc2524.pdf

Page 12:

Memory type EEPROM_JTAG uses page write or byte write and byte read. Memtypes FUSE_JTAG, LOCK_JTAG, SIGN_JTAG and OSCAL_JTAG use byte read and (write). The address sent to JTAG ICE is a word address for Program Memory and byte address for all other memory types. Only the start address and the number of bytes to be read/written must be supplied.

mcuee commented 11 months ago

The above documents are not so clear whether the calibration OSCCAL_BYTE or OSCAL_JTAG byte can be written or not.

However, from AVR055, it seems the calibration does not really write to the byte, rather write to another place (EEPROM or Flash) and later can be loaded to the OSCCAL register.

AVR055: Using a 32kHz XTAL for run-time calibration of the internal RC https://ww1.microchip.com/downloads/en/Appnotes/doc8002.pdf

Another document is AVR053: Internal RC Oscillator Calibration for tinyAVR and megaAVR Devices https://ww1.microchip.com/downloads/en/Appnotes/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf

One more for xmega: AN2644: XMEGA Internal RC Oscillator Calibration https://ww1.microchip.com/downloads/en/Appnotes/XMEGA-Internal-RC-Oscillator-Calibration-00002644A.pdf

mcuee commented 11 months ago

The above documents are not so clear whether the calibration OSCCAL_BYTE or OSCAL_JTAG byte can be written or not.

Maybe @xedbg can help here. Thanks.

xedbg commented 11 months ago

No - calibration sections can only be written in the Microchip fab, sorry. (And not even I know how to do that ;)

dl8dtl commented 11 months ago

And not even I know how to do that

They are written on the chip tester, using tester bit streams. The device is "sealed" afterwards, which is (IIRC) an OTP fuse that cannot be erased later on, thus protecting the production signature row.

Early AVRs (notably the AT90S1200) could indeed accidentally erase or overwrite the signature bytes; devices with signature 0xFF, 0xFF, 0xFF (this is documented in AVR910) and even 0x00, 0x00, 0x00 have been observed. That's been the original reason for adding the -F option to AVRDUDE.

mcuee commented 11 months ago

@dl8dtl

Thanks for the bakground info. That is quite interesting.

Do you think the codes mentioned by @stefanrueger need to be changed?

stefanrueger commented 11 months ago

OTP fuse that cannot be erased later on, thus protecting the production signature row

Thanks all round. I suggest treating signature , calibration, prodsig and all sub memories such a tempsense as read-only in AVRDUDE, ie, the code should not attempt to write to device, and any intention to write something different to what is there should yield an error. (This allows writing the backup of a read-only memory without triggering an error.)

mcuee commented 11 months ago

OTP fuse that cannot be erased later on, thus protecting the production signature row

Thanks all round. I suggest treating signature , calibration, prodsig and all sub memories such a tempsense as read-only in AVRDUDE, ie, the code should not attempt to write to device, and any intention to write something different to what is there should yield an error. (This allows writing the backup of a read-only memory without triggering an error.)

I agree.

mcuee commented 11 months ago

Just noticed that the datasheet is clear about sigrow for the AVR DD and EA family as well as Mega-0 family and Tiny-2 (probably also other families). https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/AVR64DD32-28-Prelim-DataSheet-DS40002315B.pdf

https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/AVR64EA-28-32-48-DataSheet-DS40002443.pdf

https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/ATmega4808-09-DataSheet-DS40002173C.pdf

https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/ATtiny1624-26-27-DataSheet-DS40002234B.pdf

The content of the Signature Row (SIGROW) fuses is preprogrammed and read-only. SIGROW contains information such as device ID, serial number, and calibration values.