Fuse settings question


Charles Mims <chmims@...>
 

Are the fuse settings the same for ATmega328 and the ATmega328p.

Charles
KG5ZLH


ajparent1/KB1GMX
 

A atmega328 is a family name, the specific part used and fits the socket is
the atmega328P in a 28 pin narrow DIP package.

Based on that no way to say as it could be something else like a atmega238PU
(used on most Arduino Nanos, TQFP package).  

Allison
-------------------------------
Please reply on list so we can share.
No private email, it goes to a bit bucket due address harvesting in groups.IO


Jonathan Dog
 

Allison I believe you're in error about this -- there is a part ATmega 328-no-suffix and a ATmega 328P, the P stands for "pico-power", a somewhat hyperbolic name for the low-power version.

According to the datasheet, the packaging code follows after, as "328P-PU", but the device I'm looking at isn't marked like that.

However, as I believe QRP Labs only uses 328P, this is probably only of background interest to this group.

Following notes are from the ATmega48A/PA/88A/PA/168A/PA/328/P Datasheet

Fuses

The fuses are the same for the two parts, in

  • Table 28-6. Extended Fuse Byte for ATmega328/328P
  • Table 28-8. Fuse High Byte for ATmega328/328P
  • Table 28-9. Fuse Low Byte

Differences

The part signatures are different, in "Table 28-10. Device ID":

  • ATmega328 0x1E 0x95 0x14
  • ATmega328P 0x1E 0x95 0x0F

Other differences

  • The power differences are shown in "29.2.7 ATmega328 DC Characteristics" and "29.2.8 ATmega328P DC Characteristics" where you will see that the P part has lower power consumption in some circumstances.
  • There are a couple of instructions (jmp, call) which are only available on -P. See "37. Instruction Set Summary", where it says "Note:1. These instructions are only available in ATmega168PA and ATmega328P."
  • The P part has brownout disable: "10.2 BOD Disable" where it says "Note: 1. BOD disable only available in picoPower devices ATmega48PA/88PA/168PA/328P" and some extra bits in the control register controlling brownout sleep: see "10.11.2 MCUCR – MCU Control Register".
  • There might well be other differences I haven't spotted
  • The packaging is listed in "38.7 ATmega328" and "38.8 ATmega328P", and there is, for example a "ATmega328-PU" and a "ATmega328P-PU", with -PU indicating plastic 0.3-in 28-pin DIP
  • The P part is listed as having an extended temperature range available, such as the "ATmega328P-PN"

Surpisingly my CPU from QRP labs is physically marked "ATMEGA328P U" but avrdude reports "Device signature = 0x1e950f", the signature for 328P. Other chips I have are marked "ATMEGA328P-PU" as expected, another is "MEGA328P AU" and is in a TQFP package.


Charles Mims <chmims@...>
 

The reason I ask this question is using avrdude if I enter ATmega328p it does not execute, using ATmega328 it then will complete the 1.05 firmware installation but I then get the dreaded 'use original IC'.
Hans has resolved that problem with additional software.  However I am anxious not to repeat the problem in the future.  I am running this on a Mac.

Charles


On Fri, May 15, 2020 at 5:33 AM Jonathan Dog <jonathan2dog@...> wrote:

Allison I believe you're in error about this -- there is a part ATmega 328-no-suffix and a ATmega 328P, the P stands for "pico-power", a somewhat hyperbolic name for the low-power version.

According to the datasheet, the packaging code follows after, as "328P-PU", but the device I'm looking at isn't marked like that.

However, as I believe QRP Labs only uses 328P, this is probably only of background interest to this group.

Following notes are from the ATmega48A/PA/88A/PA/168A/PA/328/P Datasheet

Fuses

The fuses are the same for the two parts, in

  • Table 28-6. Extended Fuse Byte for ATmega328/328P
  • Table 28-8. Fuse High Byte for ATmega328/328P
  • Table 28-9. Fuse Low Byte

Differences

The part signatures are different, in "Table 28-10. Device ID":

  • ATmega328 0x1E 0x95 0x14
  • ATmega328P 0x1E 0x95 0x0F

Other differences

  • The power differences are shown in "29.2.7 ATmega328 DC Characteristics" and "29.2.8 ATmega328P DC Characteristics" where you will see that the P part has lower power consumption in some circumstances.
  • There are a couple of instructions (jmp, call) which are only available on -P. See "37. Instruction Set Summary", where it says "Note:1. These instructions are only available in ATmega168PA and ATmega328P."
  • The P part has brownout disable: "10.2 BOD Disable" where it says "Note: 1. BOD disable only available in picoPower devices ATmega48PA/88PA/168PA/328P" and some extra bits in the control register controlling brownout sleep: see "10.11.2 MCUCR – MCU Control Register".
  • There might well be other differences I haven't spotted
  • The packaging is listed in "38.7 ATmega328" and "38.8 ATmega328P", and there is, for example a "ATmega328-PU" and a "ATmega328P-PU", with -PU indicating plastic 0.3-in 28-pin DIP
  • The P part is listed as having an extended temperature range available, such as the "ATmega328P-PN"

Surpisingly my CPU from QRP labs is physically marked "ATMEGA328P U" but avrdude reports "Device signature = 0x1e950f", the signature for 328P. Other chips I have are marked "ATMEGA328P-PU" as expected, another is "MEGA328P AU" and is in a TQFP package.


Jonathan Dog
 

Charles -- what signature bytes does avrdude report for your device? Jonathan.


Charles Mims <chmims@...>
 

When I run avrdude using -p ATmega328p I get the following

avrdude: Device signature = 0x1e9514 (probably m328)
avrdude: Expected signature for ATmega328p is 1E 95 0F
               double check chipe, or use -F to override check

Running avrdude using -p ATmega328 it installs the firmware update, but then the ' use original IC' message

Charles
KG5ZLH


Alan G4ZFQ
 

Running avrdude using -p ATmega328 it installs the firmware update, but then the ' use original IC' message
Charles,

You need to contact Hans.
It seems some chips had the wrong fuse setting, unless something very funny is happening.

73 Alan G4ZFQ


Charles Mims <chmims@...>
 

Fortunately Hans has already provided the solution to repair the damage. I’m trying to avoid this happening with the next firmware update

Charles
KG5ZLH

On May 16, 2020, at 11:16 AM, Alan G4ZFQ <alan4alan@gmail.com> wrote:



Running avrdude using -p ATmega328 it installs the firmware update, but then the ' use original IC' message
Charles,

You need to contact Hans.
It seems some chips had the wrong fuse setting, unless something very funny is happening.

73 Alan G4ZFQg tolearn how to avaid




Scott - N1ST <n1st@...>
 

Upgrade from 1.04 to 1.05.
I was being so careful following doc on the group, yet I'm now receiving the error that Charles did - ' use original IC' .  I didn't change any fuses. My chip apparently is the 328 non P.  Should I have changed the Hi fuse from D9 to D1?
What did I do wrong, and how do I fix this?

i Charles, I'm running into the same issue - my chip is being recognized as 0x1e9514.  How do I proceed without running into  'use original IC'.


Alan G4ZFQ
 

Scott
I'm now receiving the error that Charles did - ' use original IC' .  I didn't change any fuses. My chip apparently is the 328 non P.  Should I have changed the Hi fuse from D9 to D1?
Yes H fuse must be D1 otherwise the EEPROM gets erased.
You need to contact Hans.

What did I do wrong, and how do I fix this?
Are you absolutely sure? You read the fuses before you did anything else?

73 Alan G4ZFQ


Charles Mims <chmims@...>
 

The immediate solution to your problem is to contact Hans who can you the necessary files and info to fix the problem.

I'm still not sure what I should do the next time I update firmware to prevent the same problem.
I am basically a 'monkey see, monkey do' computer user.  No expert, but it seems to me there is a problem associated with certain QCX.  To me it looks like they have in a common an ATmega238 and not the ATmega329p.  Also the hfuse setting is 0xD9.  This seems to persist even after telling the chip to set the hfuse to 0xD1.  I say this because after updating the firmware and eeprom with a hfuse setting of 0xD91and having a functioning QCX again, when I check the fuse setting on myATmega328 is still show hfuse as 0xD1.  My fear is the next firmware update I will have the same problem. 

There another thread on this problem 'Update QCX Firmware to v1.05 Snag'  That discusses this same problem thate might help.

Charles


jjpurdum
 

All:

I've been doing multiple firmware updates to my QCX using the attached instructions in conjunction with ArvDudess, a Windows-based free app that doesn't work from the command line. It does require me to have an Uno to attach the ISP header, but that's easy to do following the instructions.

It works every time for me.

Jack, W8TEE

On Saturday, May 23, 2020, 11:49:09 AM EDT, Charles Mims <chmims@...> wrote:


The immediate solution to your problem is to contact Hans who can you the necessary files and info to fix the problem.

I'm still not sure what I should do the next time I update firmware to prevent the same problem.
I am basically a 'monkey see, monkey do' computer user.  No expert, but it seems to me there is a problem associated with certain QCX.  To me it looks like they have in a common an ATmega238 and not the ATmega329p.  Also the hfuse setting is 0xD9.  This seems to persist even after telling the chip to set the hfuse to 0xD1.  I say this because after updating the firmware and eeprom with a hfuse setting of 0xD91and having a functioning QCX again, when I check the fuse setting on myATmega328 is still show hfuse as 0xD1.  My fear is the next firmware update I will have the same problem. 

There another thread on this problem 'Update QCX Firmware to v1.05 Snag'  That discusses this same problem thate might help.

Charles


Arv Evans <arvid.evans@...>
 


QRP-Labs has documented earlier attempts to duplicate QRP-Labs hardware
with copies that are not up to QRPLabs standards but are expecting QRP-Labs
to support and repair their faulty non-QRP-Labs systems.

The "use original software" message may be related to tests in the original
software to keep others from stealing it and installing it on plagiarized hardware. 
Fuse settings may be part of the protection scheme, but there may be more to
it than that.  

If you are running into problems trying to install QRP-Labs software on a new
or reprogrammed micro-controller then it may be appropriate to contact
QRP-Labs so they can tell you how to fix your problem.

Arv
_._


On Sat, May 23, 2020 at 9:49 AM Charles Mims <chmims@...> wrote:
The immediate solution to your problem is to contact Hans who can you the necessary files and info to fix the problem.

I'm still not sure what I should do the next time I update firmware to prevent the same problem.
I am basically a 'monkey see, monkey do' computer user.  No expert, but it seems to me there is a problem associated with certain QCX.  To me it looks like they have in a common an ATmega238 and not the ATmega329p.  Also the hfuse setting is 0xD9.  This seems to persist even after telling the chip to set the hfuse to 0xD1.  I say this because after updating the firmware and eeprom with a hfuse setting of 0xD91and having a functioning QCX again, when I check the fuse setting on myATmega328 is still show hfuse as 0xD1.  My fear is the next firmware update I will have the same problem. 

There another thread on this problem 'Update QCX Firmware to v1.05 Snag'  That discusses this same problem thate might help.

Charles


Scott - N1ST <n1st@...>
 

Hans did help me resolve the issue.  Thanks Hans!  Contact Hans directly if you run into this.

I believe that the 'use original IC' error occurs because the H fuse needs to be D1,  It seems that it's D9 on some chips.  Hans feels that it gets changed from D1 to D9 somehow.
Perhaps D1 vs D9 is related to these being 328 vs. 328P?   Mine is an M328 according to the signature.  Does anyone know what D1 and D9 mean?  The 328p is the low power version.  Is the high fuse value related to that?
Before I updated my flash, I read the fuses, and H was definitely D9, but there were conflicting posts on this group - set it to D1 vs. leave the fuses alone, so I left it along and caused the problem.
Charles - the value you're seeing for H may be "remembered" by the program.  Try explicitly reading the fuses again.  My chip kept the fixed D1 setting according to the read of the fuses.


Alan G4ZFQ
 

Before I updated my flash, I read the fuses, and H was definitely D9, but there were conflicting posts on this group - set it to D1 vs. leave the fuses alone,
The High fuse MUST be D1.
It has seemed to me that some of the chips has had this fuse set to D9, Hans has always said this is virtually impossible.
But it should be checked first and changed if it is not D1.
I am the only one who has updated my instructions to check first, all the other tutorials I see do not say that.

Once the new .hex has been flashed it is too late.
Those (the majority?) that say they updated several times without trouble must have the fuse set correctly.
Normal flashing does not change the fuses, they are fixed unless changed on purpose.

73 Alan G4ZFQ

so I left it along and caused the problem.
Charles - the value you're seeing for H may be "remembered" by the program.  Try explicitly reading the fuses again.  My chip kept the fixed D1 setting according to the read of the fuses.


 

The documentation on the QRP-LABS site should be updated regarding checking the HI fuse for X’D1’ for the first re-flash of the firmware.

If the HI  fuse is not correct, is the micro totally bricked or can the problem  be fixed using the  .eep file?
--
73, Bernie, VE3FWF


Scott - N1ST <n1st@...>
 

It can be un-bricked by working with Hans.


Arv Evans <arvid.evans@...>
 

If I were trying to protect my proprietary software from being plagiarized
I would probably copy a key (maybe the CPU serial number) into the .eep 
file and then include code in flash memory to test for a match between 
CPU serial number and that key in the .eep space.  There are several other 
ways to do this.  Multiple tests could be done, or even encrypt the 
embedded key and test for proper decryption.  

Arv
_._


On Sat, May 23, 2020 at 5:07 PM Ham Radio <bernard.murphy@...> wrote:
The documentation on the QRP-LABS site should be updated regarding checking the HI fuse for X’D1’ for the first re-flash of the firmware.

If the HI  fuse is not correct, is the micro totally bricked or can the problem  be fixed using the  .eep file?
--
73, Bernie, VE3FWF


Larry AC8YE
 

Arv,
Any non-trivial decryption would require additional flash resources that do not exist.  I'm sure Hans is down to counting bits at this point.
Larry AC8YE


On Sat, May 23, 2020 at 7:54 PM Arv Evans <arvid.evans@...> wrote:
If I were trying to protect my proprietary software from being plagiarized
I would probably copy a key (maybe the CPU serial number) into the .eep 
file and then include code in flash memory to test for a match between 
CPU serial number and that key in the .eep space.  There are several other 
ways to do this.  Multiple tests could be done, or even encrypt the 
embedded key and test for proper decryption.  

Arv
_._


On Sat, May 23, 2020 at 5:07 PM Ham Radio <bernard.murphy@...> wrote:
The documentation on the QRP-LABS site should be updated regarding checking the HI fuse for X’D1’ for the first re-flash of the firmware.

If the HI  fuse is not correct, is the micro totally bricked or can the problem  be fixed using the  .eep file?
--
73, Bernie, VE3FWF


Arv Evans <arvid.evans@...>
 


Larry

if (a != b) { Serial.println ("security code violated");
exit(1);  // product validation is simple!
}

Possibly was in the code from the time when an Ebay vendor tried to sell U3 
boards and expected QRP-Labs to support their marginal products.

Arv
_._

On Sat, May 23, 2020 at 6:02 PM Larry Howell <larry.howell.47@...> wrote:
Arv,
Any non-trivial decryption would require additional flash resources that do not exist.  I'm sure Hans is down to counting bits at this point.
Larry AC8YE

On Sat, May 23, 2020 at 7:54 PM Arv Evans <arvid.evans@...> wrote:
If I were trying to protect my proprietary software from being plagiarized
I would probably copy a key (maybe the CPU serial number) into the .eep 
file and then include code in flash memory to test for a match between 
CPU serial number and that key in the .eep space.  There are several other 
ways to do this.  Multiple tests could be done, or even encrypt the 
embedded key and test for proper decryption.  

Arv
_._


On Sat, May 23, 2020 at 5:07 PM Ham Radio <bernard.murphy@...> wrote:
The documentation on the QRP-LABS site should be updated regarding checking the HI fuse for X’D1’ for the first re-flash of the firmware.

If the HI  fuse is not correct, is the micro totally bricked or can the problem  be fixed using the  .eep file?
--
73, Bernie, VE3FWF