ATmega328: Chip markings, initial program memory and flags state, IDs...

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I built the Open Programmer about a year ago, and it served me well with several PIC projects, after using a serial zapper for years. Now I wanted to experiment with the ATmega328, so I built the AVR adapter and I have some strange issues. I have no experience with AVR chips, and don't know the 'default' behavior when new.

  •  

  • First I checked all connections and everything seems ok.

  • I have two different AVR chips. One marked 'ATmega328P-PU', one 'ATmega328P U' (both literally) They responded somewhat differently:

 

Chip marking ID Lock FUSE FUSE High FUSE Extra
ATmega328P-PU 1E950F 0xFF 0x62 0xD0 0xFF
ATmega328P U 1E950F 0xCF 0xFF 0xDE 0xFD

 

The 328P-PU program area is read as random data, and different each read gives different values, giving the impression that the data is floating.

The 328P U program area seems to have code (boot loader?) at the end (from 0x3e00 and up. Which could explain the 0xCF in the lock bits.

So... questions:

 

-Is this normal behavior for new chips? (i.e. can the unprogrammed area give random readouts?)
-The '328P U' marking seems suspicious. I found no reference to this version. Anyone?
-The oscilloscope shows minor overshoots on the signals from the chips (about 0.2V). I don't think this has any influence on things though. The ground connections seem Ok.
-According to the datasheet, AVCC should be connected. On the AVR adapter PCB it isn't. Problematic?
-The adapter circuit shows a jumper for use with 20-pin devices on the 28-pin sockets. The PCB doesn't have that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

New chips would normally arrive un-programmed.  (except for some USB chips, which come pre-programmed with a bootloader.)

"Random and changing" contents is definitely unusual.  Could it be locked?  (I'm not sure that the lock bits will read is "locked" on a locked chip.)

There are a large number of people selling ATmega328p chips with the Arduino bootloader (or "AN arduino bootloader") and fuses already programmed, ready to plug into your arduino-compatible project.  Usually they charge extra for the service, but it wouldn't surprise me to find some mis-binned chips floating around.

The flood of cheap Arduino-compatible from China has led to suspicions that somewhere there is a gray-market source of cheap ATmega328 chips; perhaps even "clone" chips.  It's not uncommon for such chips to be re-marked.  (they COULD of course be genuine atmel parts sold in 100k lots with custom markings to some appliance vendor, who they threw them away because it was cheaper to buy new pre-programmed chips than reprogam or ship products with out-of-date firmware.   In which case funneling them into the gray and hobby market seems like a wonderful thing!)

 

-According to the datasheet, AVCC should be connected. On the AVR adapter PCB it isn't. Problematic?

Yes.  All power pins should be connected.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks!

 

I'll put in a jumper from AVCC to VCC, and see if that changes something.

 

'Unprogrammed' means 0xFF, doesn't it? At least the PIC chips were like that, and I see on the output dump that lines with all FFs are not shown.

 

I'll try to find out how to specify the fuses in gcc and try to unlock. I haven't gotten that far yet.

 

Both chips are very different. The PU chip has 2 lines on top (just the part number and date), and 3 lines on the bottom. The U chip has 3 on

top and nothing on the bottom... But I doubt they have been manufacture in separate places. The mechanical appearance is too similar.

 

John

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
Chip marking ID Lock FUSE FUSE High FUSE Extra
ATmega328P-PU 1E950F 0xFF 0x62 0xD0 0xFF
ATmega328P U 1E950F 0xCF 0xFF 0xDE 0xFD

The first one has default fuse values, almost.  The High fuse has a default value of 0xD9.  Is 0xD0 a typo?

 

The second one has the fuse values I would expect of an Arduino UNO R3.  Low power external crystal oscillator, 512-byte bootloader, 2.7V BOD.  And, lock bits set for BLB1 mode 3.

 

The 328P-PU program area is read as random data, and different each read gives different values, giving the impression that the data is floating.

It gives me the impression that your wiring is faulty.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sun. Mar 18, 2018 - 02:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Reading up more on Open Programmer, testing, etc, shows that the programmer should send the 'Chip Erase' command to the ATmega... It seems that command didn't make it into Open Programmer. Will check tomorrow if it's difficult to add.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the programmer should send the 'Chip Erase' command to the ATmega... It seems that command didn't make it into Open Programmer.

Really?  It would have been pretty useless as an AVR programmer in that case.  You ALWAYS need a chip-erase to re-program an AVR.  Not having it implemented would give you one-time-progammable parts.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You ALWAYS need a chip-erase to re-program an AVR.

There is at least one use case for not erasing before programming:  When programming a bootloader and an app from two separate .hex (or .elf) files.

 

But I agree, rather silly not to make chip erase the default action.  For example, avrdude has the -D option.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, looking around some more, I read a comment that Open Programmer erases the chip each time it's programmed. 'Chip Erase' isn't mentioned, but I suspect the only way to do it is with that command.

 

So, even with all the weird (and continuously changing) values read from the chips, I decide to be brave and program some bytes (I'm a very cautious person). I compiled a few lines, generated the hex, and zapped the chip... Even stranger: The 10 bytes I programmed read perfect, and consistently the same. All around bytes are still changing. The pattern seems to repeat itself, not the location. The top line is the test I programmed (it's just a simple assembler file of the first 20-odd assembler instructions - adc, add, etc.)

 

I added two screenshots to show how the contents changes.

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why mess with an unknown programmer, pick up a USBASP for $3 and start learning AVR!    While your at it, pick up a few arduino nano's and/or Uno's as well.

 

Jim

 

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274