Gammon Board Programmer not recognizing 1284 signature

I’ve been using Nick Gammon’s “Atmega_Board_Programmer” sketch to program my chips with proper bootloaders with great success for a long time. I recently got a few new 1284P’s and the signature is different from my old ones so the programmer will not recognize them.

Here’s what I get upon connecting to the serial monitor.

Attempting to enter ICSP programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x97 0x06 
Unrecogized signature.

The old signature was : 0x1E 0x97 0x0[b]5[/b] Only being different in this one value. I figured this may be a change from the manufacturer on newer models? Either way, I want to let Nick know, and ask how I can add this signature into the recognized signatures.

You bought 1284 chips instead of 1284P, probably by accident. I did the same thing with 328 (no P) recently and had to modify Nick's program (he has since updated it for that part). If the 1284 (no P) is anything like the 328, the only physical difference is that it uses a little bit more current, not that much though. And in some circumstances software will get upset about it.

|500x223

What are you implying with this?

Sorry, I hit the post button prematurely.

It's an easy mistake to make when ordering because even the non-P chips have a P in their part number. E.G., Atmega328-PU as opposed to Atmega328P-PU.

Ahhh, theres my problem, slightly oblivious I guess... Is there any way to program/use these on the same architecture? I've never used the non P chips.... Thanks for prompt responses and assistance.

They're identical as far as I can tell except for current consumption (and the signature). They draw more current by some small fraction. The only places I've run into an issue is when I've used software that wanted to verify the signature. Specifically, Nick's program and avrdude. Nick's program was easy to modify. With avrdude I added the -F option for command line use. And found I needed to edit the signature in avrdude.conf, at least for IDE 1.0.6. I think this is fixed in 1.6.x.

I'm not sure why there is a non-P part. It isn't less expensive. It uses a little more power. Why would anyone want it? There must be some reason.

Why would anyone want it?

Imagine you sell widgets. You spent about $1e6 in engineering to develop the widget (the "sunk" cost). The widget costs about $5e0. You make about $1e-1 on each widget. You are going to have to sell many widgets to recover the engineering cost.

Occasionally, Atmel makes a mistake. Occasionally, Atmel creates a product that has a bug (called "errata"). For example, the t24rC has this errata: "Reading EEPROM when system clock frequency is below 900 kHz may not work".

Let's say your widget was designed around the m1284 (non-P). The m1284P arrives on the market. You have a choice. Continue making and selling widgets using the m1284 -OR- hire an engineer to ensure the m1284P will work (that there is no affecting errata) and then, possibly, make and sell widgets using the m1284P. The second path adds even more sunk cost.

Given the slim margin of your widget and the large sunk cost the choice is obvious: stick with the m1284.

Thanks for the input, I finally got nick's programmer working with the non "p" version as well by changing the programmer's 1284 definitions and signature files to include the proper addresses. This chip was actually about $0.75 cheaper now that I reordered a "p" version, I realize there is a slight price difference from my vendor. I'd probably rather be using the lower power version anyway, and cannot really see an advantage other than cost for this chip.

Thanks for the help jboyton.

Just reading Coding Badly's response now, thanks for making this point as well, because it clarifies why both are stocked and commonly available. I knew they made both the P and non P models, but I didn't notice since i saw the second P in the 'PU' last time I purchased them. My mistake, but apparently I'll be able to use them still in some regard.

:)

...i saw the second P in the 'PU' last time I purchased them

I have nearly made that mistake. The Atmel folks do like the letter "P".

That makes sense Coding Badly. You always make sense. Are you ever just plain wrong? I never see it.

jengil – In 1.0.6 I had to edit avrdude.conf and change the signature. Since I also have 328p chips I had to change it back for those. Back and forth, back and forth, probably 200 times in the last month. Very annoying. In 1.6.4 all I had to do was add a new board definition in boards.txt, with the build.cpu element changed to leave out the “p”. So now it’s back and forth with Tools->Board, a little easier, still annoying. I will probably put that chip in a drawer soon and never take it out again.

Atmel… brought to you by the letter “P”.

Are you ever just plain wrong?

Just this afternoon. I made the mistake of washing the dog's bedding. I found her staring into her kennel in disbelief. It was painfully obvious what she was thinking, "that is just plain wrong."

Back and forth, back and forth, probably 200 times in the last month.

Using a bootloader, when possible, makes that problem go away. Optiboot reports a hard-coded signature instead of the actual signature.

Can't you just copy the 1284P section in avrdude.conf into a 1284 section with the new signature bytes and name change, then make a new boards.txt entry with the same name? Then you could use either type.

[quote author=Coding Badly link=msg=2323583 date=1437437109] Using a bootloader, when possible, makes that problem go away. Optiboot reports a hard-coded signature instead of the actual signature. [/quote] Thanks for that, I didn't know (I still don't have an FTDI adapter). And for the image of your dog. I could totally see that face.

CrossRoads: Can't you just copy the 1284P section in avrdude.conf into a 1284 section with the new signature bytes and name change, then make a new boards.txt entry with the same name? Then you could use either type.

No, it doesn't work.

The compiler generates a bunch of errors. I think it's looking for iom328.h, which doesn't exist. I tried duplicating iom328p.h and editing it but that wasn't enough either.

Can pick up an FTDI module pretty cheap - $6.90 from tinyosshop.com is where I get mine, with micro-usb connector and jumper to select 3.3V or 5V IO to the uC. Website says it comes with a cable too. http://www.tinyosshop.com/index.php?route=product/product&filter_name=ftdi&filter_description=true&filter_sub_category=true&product_id=186