There are many fake Atmel chips in the world and for most hobbyists it doesn't matter whether your Aurduino Nano has a real on or a fake one installed.  Blinky programs will work just fine on a fake.  For some applications though it's a critial componenet that can cause your project to fail and will cost you many, many hours chasing a fault, that's not of your own making.

Specifically in response to https://www.youtube.com/watch?v=eeDC1m7ANJI

I realised that instead of using the "Auduino system" (which I never use) to upload and run a sketch, the same data should be readable using avrdude.

Avrdude uses the serial programming mode to install code and query the chip including getting the calibration byte and the signature bytes.  These bytes are in the memory block we are interested in to determine whether the chip is genuine or not. As explained in the video if we read this block and it's mostly 0xFF then we can reasonanbly assume the chip is a fake.  The data sheets say that there should be data in here, which includes the chip serial number.

Using avrdude and editing avrdude.conf we can read out the relavent block of data to get the same information as described in the video.  LIke I said I don't use the Arduino system so getting the data without reprogramming the chip was my goal.  Beside which you may not want to overwrite the existing program. This may be  because you may not have access to the source code to reprogram the chip  aftet doing the test. In htis case download the code from the chip into a file as a backup.

At first, looking at avrdude.conf and the manual I was compltely mystified.  This is completely normal when programming however, so I persisted.  Perusing the manual, with a clue from the thread in the above video, I discovered the Serial Programming Instruction Set.  This is table 32-17 in the 328PB data asheet, and table 20-12 in the Attiny85  datasheet.  Since I normally use either tiny85's or tiny84's for my projects and the instruction set is the same I delved into that and the avrdude.conf file to see what's going on.

While the avrdude manual is about as clear as mud, the Atmel data sheets are well written.  Still not an easy read but at least all the data are there.

The avrdude.conf instructions are a string representation of a binary number that's the equivalent of the hexadecimal values in the Serial Programming Instruction Set table.   But why?  Why not use the hex values?  No idea.  If I find out I'll update this post.  Anyway after reading the instruction set table and other parts of the avrdude.conf file I came up with the following to insert into avrdude.conf to get us the required data.  Without having to reprogram the chip or fire up the (horrible) arduino IDE.

memory "ext-sig" 
size    = 32;
read_hi    = "0 0 1 1 1 0 0 0",
   "0 0 0 0 0 0 0 0",
"x x x x a3 a2 a1 a0",
  "o o o o o o o o";

read_lo    = "0 0 1 1 0 0 0 0",
   "0 0 0 0 0 0 0 0",
"x x x x a3 a2 a1 a0",
  "o o o o o o o o";
;

Save the file and run avrdude in terminal mode. You can call it whatever you like, "ext-sig" seemed good to be since we are reading the entire 32 bytes of the signature section. This will show up in the list of available memory areas you can query.

avrdude -C/etc/avrdude/avrdude.conf -v -patmega328p -cstk200 -t

avrdude> read ext 
>>> read ext
0000  1e 92 95 ff 0f bc 00 26  ff 09 ff 17 ff ff 57 39  |.......&. ....W9|
0010  33 33 35 34 ff 14 12 09  17 05 12 09 13 09 ff ff  |3354... ... . ..|

This looks like a genuine chip, hooray!

Doing this on another Arduino now reveals:

avrdude> read ext 
>>> read ext
0000  1e d9 95 ff 0f ff ff 26  ff ff ff ff ff ff 58 ff  |.......&......X.|
0010  ef ff ef ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

Which leads me to believe this is a fake.  Both nanos were purchased at the same sime as a lot of five.  Eyeballing the chips, with a lens, reveals that the fake ships have very sketchy labelling and this alone can be used to reveal real or fake chips that confirms the above output.

Now I can check my chips easily without having reprogram them.

These instruction blocks can be inserted into the sections of other chips, in my case ATiny85 anf ATiny84 so I can query those chips too.  Beware though that these manual edits may be lost when avrdude is updated by your OS's update process. 

An attempt to explain how I think this works follows and may not be correct.

From the Atmel datasheet:

Read Signature Byte 0x30 0x00 0000 000aa(2) data byte out

This seems to read out only the lower byte of the pair but we need all the bytes.

In other avrdude instructions I see there's a read_lo and a read_hi part with just a single bit change in the lower nibble, which is set to 0x8 or 1000 binary.  Using this clue and specifying a size of 32 should get the entire block.  Except it took a while to figure out the address part. I ended up with "x x x x a3 a2 a1 a0" and this is where I'm confused.

I rationalised this as:

We want 32 bytes, the instruction read_hi and read_lo gets alternate bytes (of a 16 bit word?), each alternate byte "group" is 16 bytes, "x x x x a3 a2 a1 a0" is a 16 byte adress size block, do this twice to get 32 bytes as interleaved data bytes which (Somehow. This is where my undertanding comes to an end.) avrdude correctly interprets as a 32 byte block of data and spits it out.

For fun, while I'm in avrdude terminal mode, I used the send <b1> <b2> <b3> <b4> command to manually query the chip using the Serial Programming Instruction Set table.  Example, to get the calibration byte.

>>> send 0x38 0x00 0x00 0x00
results: 00 38 00 d9

Avrdude echoes the command set with the last byte populated with the calibration byte value.  This can be done for all the instructions in the table.

>>> send 0x30 0x00 0x00 0x00
results: 00 30 00 1e
>>> send 0x30 0x00 0x01 0x00
results: 00 30 00 95

This returns the bytes at the address specified in the 3rd instruction byte.  Interesting we can supply the hex codes here yet avrdude.conf requires a binary as a string, which is both odd and unexplained.  I tried to use hex in avrdude.conf and just got errors. Reply to this post please if you have any more information on this. 

Next will be a script to automate the testing and outputting a report.

Thank you to Kevin Darrah for your excellent video inspiring me to do this.

 

 

 

.

 

 

Last changed: 25. September, 2020 at 08:01

Back to Overview

Comments

Add Comment