Programming ATmega328PB ispEnterProgMode fail

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

I know i now.. there's a lot of other similar topics and I have searched everything but my problem persists.. and is very strange.

 

I'm trying to program the 328Pon my custom board with ATMEL ICE and AVR MKII, without success. I've tried 3 chips, the problem is exactly the same and more interesting is that I can read the chip and set fuses on first time on every chip but it fails after that. Basically my objective is only to upload the arduino compatible bootloader the first and my board have serial programming after.

 

This were my steps for the first chip

1- Attached the MKII to 328PB chip

2- Went to Atmel Studio -> Device Programming - It reads the device signature and everything seems ok

3- Went to arduino to upload the custom bootloader using that Arduino's feature -> It fails

4- Went again to Atmel Studio and I can't read the device signature anymore.

 

Second try

I thought I fried the chip with some short so I changed the chip and I made exactly the same steps as previous. Same exactly results.

 

Third try

Changed the chip again

1- Attached the  MKII and chip

2- Went to Atmel Studio -> Device Programming - It reads the device signature and everything seems ok

3- Programmed the LOW.SUT_CKSEL fuse to activate my external 8Mhz crystal. -> verified with oscilloscope.

4- Went to arduino to upload the custom bootloader using that Arduino's feature -> It fails

5- Went again to Atmel Studio and I can't read the device signature anymore.

 

I don't understand what may be the problem. What is going on? i'm totally lost on this one..

 

 

Last Edited: Fri. Jul 20, 2018 - 11:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you read the fuses, again, after you have set them?

 

Odds are, one of the fuses you changed did something to "kill" it. So, what are the fuses before you change anything and what are they changed TO. Don't change them, just give us the list of what the AFTER is supposed to be.

 

For example, you COULD have changed the oscillator to External Oscillator when you really intend to have a crystal (which is something like "Ext. Crystal or Resonator"). Doing that will kill it, for sure. If this is it, you can recover them by supplying an external clock signal (just long enough to change the fuses) and set the fuses to what they need to be. There ARE other possible booboos. One is to turn on RSTDISBL; that will also kill it.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Fri. Jul 20, 2018 - 11:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes I can read after setting them. And I only changed to external crystal on third try. It activated it and confirmed with the oscilloscope.

 

It only stops working after trying to upload the arduino bootloader with Arduino IDE. Even the crystal stopped working after this step.

 

It seems that somehow when I've tried to upload the bootloader it changed some fuses or something like that. By default this chip is using a 1Mhz RC internal oscillator.

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

Are you unable to read the fuses after trying to upload the bootloader?  I can easily imagine that Arduino may include fuse changes in the bootloader operation. And, they may well set it to External Resonator (I think most Arduinos do have a crystal). That would kill it unless you have a crystal and a pair of 22pf capacitors connected on the board.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

After trying to upload the bootloader, the chip acts as dead. But this process is never finished, the arduino IDE (avrdude) trows an upload error at the beginning (can't remember what error).

I have the crystal and the small capacitors placed.

 

I think I will change this chip to the normal (old) 328P. I've done it successfully on previous projects.  

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

I too am having problems programming the 328PB.

Interestingly when I change device from the 328P to 328PB in the programming tools it changes the ISP clock to 458KHz..  I can't get it to  'stick' to 125KHz.

I don't think this is the actual problem but I'm trying to bring 3 new boards all with the 328PB and the ICE wont connect..  yet I do have a board that does work.

There's nothing connected to the  ISP port except my programming header and the reset has a 27k pull up as I normally do.

I have two ICEs both behave the same.

Anyone else suffering with 328PB?

 

 

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

rowifi wrote:
I can't get it to  'stick' to 125KHz.
A work-around is atprogram.exe

Atmel Studio 7 - Command Line Utility (CLI)

 

"Dare to be naïve." - Buckminster Fuller

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

Try programming something simple in studio, like blinking an led or just toggling a pin...can you down load THAT properly & see it working?  If so, then you know the problem is on the Arduino side of the equation.

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

LuisSousa wrote:

After trying to upload the bootloader, the chip acts as dead. But this process is never finished, the arduino IDE (avrdude) trows an upload error at the beginning (can't remember what error).

I have the crystal and the small capacitors placed.

 

Happy New Year Everyone.

 

I know this is an old post, but I am having the same problem with atmega328pb, TQFP.

 

I am NOT using or uploading a bootloader.

 

I am NOT changing the fuses when the problem arises.

 

I am not using POGO Pin adapters of any kind, the 6 pin ISP connector is of good quality.

 

The board that contains the atmega328pb has a 3.6864 MHz crystal and two 22pF capacitors for clocking.

(I also verified the crystal with my scope, everything is fine)

 

This is what I am doing:

Using AVRDUDE and BitClock setting 187.5 KHz with a USBASP programmer

(I have several USBASP programmers I have tried, this is not the problem)

 

Change the fuses to:

-U lfuse:w:0xcc:m -U hfuse:w:0xdf:m -U efuse:w:0xf6:m

This has worked many, many times before therefore I never need to change it.

( I did disable the bod as a test, no difference)

 

Try to read back fuse, everything OK!

 

Power cycle board and programmer.

 

Try to read back fuse again, everything OK!

 

Just as a test, try to upload a small blinky program,

NOT CHANGING fuses or lock bits or anything else,

ONLY erase flash and write flash.

 

It recognizes the chip, programs but never verifies.

 

NOW the atmega328pb is undetectable by the programmer!

 

(power cycle everything and try again, chip undetectable)

 

I removed the TQFP and soldered it on a breakout board.

I then read the atmega328pb with my Universal parallel programmer.

 

The flash is erased, not even one byte wrote.

 

Usually the SPIEN is not programmed ,sometimes there are other changes to the fuses

when I did not program the fuses at all, only the flash was programmed.

 

So what's happening:

Something is programming the fuses on the atmega328pb even when the fuse programming instructions are not sent.

 

Out of 25 atmega's I have bricked 10 of them. 

These are genuine (purchased from a reputable company).

 

Only a few of them (3 so far) have been successfully programmed.

 

Some of the atmega's are detectable after reprogramming the fuses with the universal parallel programmer (the signature bytes can be read)

 

Some of the atmega's are not detectable (the signature bytes CANNOT be read) but these are programmble if you can override the signature verification in avrdude.

 

If this is happening to me, I am sure others have this problem as well.

 

I am wondering if there is a bad batch of these atmega's out there and what (if anything) they are willing to do about it.

Again the only time this happens is when I write to the flash, I can program fuses,eeprom, lock bits, it doesn't brick the chip unless the flash is being programmed.

 

Any advice is always appreciated.

 

 

Last Edited: Thu. Jan 2, 2020 - 03:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try changing the ISP clock rate to 125kHz and try again to program.

 

Jim

 

 

 

 

 

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

ki0bk wrote:

Try changing the ISP clock rate to 125kHz and try again to program.

 

Jim

 

 

I have tried slower rates (93750 Hz), still the same result.

 

I am testing a few chips with the breakout board just in case it messes up,

this way I have a chance to repair the atmega with the parallel programmer.

Last Edited: Thu. Jan 2, 2020 - 03:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well another one bites the dust!

avrdude.exe: set SCK frequency to 93750 Hz
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude.exe: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x000000
avrdude.exe: Yikes!  Invalid device signature.
             Double check connections and try again, or use -F to override
             this check.


avrdude.exe done.  Thank you.

 

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

Does your break out board have clock source?  As you said you were using external xtal on the other board.

 

Jim

 

 

 

 

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

ki0bk wrote:

Does your break out board have clock source?  As you said you were using external xtal on the other board.

Jim

 

this is exactly what I have here:

https://www.avrfreaks.net/sites/default/files/tqfp32.jpg

 

I plug this board into my universal programmer (ZIF socket) when I want to read

what damage has been caused by avrdude and the ISP programmer. 

 

When I want to use the ISP programmer, I plug the same breakout board into another small board that contains a 32 pin socket,

an ISP connector and a crystal & capacitors, and nothing else.

 

This is the only way I can troubleshoot without removing the chip from the board every single time. If the problem re-occurs,

I can unplug the breakout board and insert it in the universal parallel programmer.

 

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

newbie123 wrote:

Well another one bites the dust!

avrdude.exe: set SCK frequency to 93750 Hz
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude.exe: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x000000
avrdude.exe: Yikes!  Invalid device signature.
             Double check connections and try again, or use -F to override
             this check.

avrdude.exe done.  Thank you.

 

Show your avrdude command line, we need to see what fuse settings your using when you bricked your chip.

Is this a M328p or pb?

 

Jim

There is a tutorial in the tutorial forum on how to unbrick when you choose the wrong fuse setting.

 

 

 

 

Last Edited: Thu. Jan 2, 2020 - 04:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
avrdude -c usbasp -p m328pb -P usb -B 4.0 -e -U flash:w:test.hex (187.5 KHz)
or 
avrdude -c usbasp -p m328pb -P usb -B 8.0 -e -U flash:w:test.hex (93.75 KHz)

its an atmega328pb

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

So no fuses have been changed, i.e. the chip is still using the default internal rc osc?

Jim

 

 

 

 

 

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

As I mentioned above:

newbie123 wrote:

Change the fuses to:

-U lfuse:w:0xcc:m -U hfuse:w:0xdf:m -U efuse:w:0xf6:m

This has worked many, many times before therefore I never need to change it.

( I did disable the bod as a test, no difference)

 

Try to read back fuse, everything OK!

 

Power cycle board and programmer.

 

Try to read back fuse again, everything OK!

 

the chip is still working at this point (using the crystal)

 

The problem occurs when I try to program the flash.

I am not programming the fuses at the same time.

Last Edited: Thu. Jan 2, 2020 - 04:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The SUT fuses are set to a short startup time, try setting it to the longest start up time, xtalsl can take a while to settle into osculating at a steady pace. 

The fact above that you can not read the signature is classic for not having a clock source, or faulty isp connections.

 

Jim

 

 

 

 

 

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

Are the chips somehow going to debug wire mode?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

ki0bk wrote:

The SUT fuses are set to a short startup time, try setting it to the longest start up time, xtalsl can take a while to settle into osculating at a steady pace. 

The fact above that you can not read the signature is classic for not having a clock source, or faulty isp connections.

 

Jim 

thanks Jim, Yes I tried that, same thing happens.

 

js wrote:

Are the chips somehow going to debug wire mode?

 

actually once the DWEN was programmed when I used the parallel programmer to read the fuses, I discovered it.

 

The results are different every time (remember i am not programming the fuses! just the flash)

 

My theory is that the chip loses the connection with the programmer somehow and then any byte of

data still being programmed by avrdude might resemble the "program fuses" command, therefore programming the fuses with the data in the flash.

 

The problem with Avrdude is that it writes the whole flash then it verifies.

 

I wrote an ISP programmer (long time ago) that actually verifies each page after it writes the page, so if there is something wrong it STOPS immediately

instead of continuing on and on until it's too late. I haven't been using it because it's too slow,

 

HOWEVER

 

using my homemade programmer on this group of atmega328pb, I discovered that it will never verify consistently.

Sometimes it gets in a whole page or two before it stops. Sometimes it will go through almost the whole flash until 

it stops. A few times it went through to the end.

 

Reading the chip with another programmer verified that it is working.

 

I even logged the SPI communication to see what is going on, I can see that it does lose connection and there is nothing returning on the MISO line.
 

For the sake of troubleshooting, the circuit (breakouot board as mentioned above) has NOTHING except a crystal and two 22pF caps, and an ISP header.

 

I have been at this almost one week I am beginning to think it must be the atmegas.

Anything else I program with my apparatus is working 100%.

(I tried an atmega8, atmega328 in an UNO board, some m168's in some pro mini boards, they all are working except these m328pb's)

 

 

 

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

newbie123 wrote:
The board that contains the atmega328pb has a 3.6864 MHz crystal and two 22pF capacitors for clocking.
Due to one of Jim's posts (edit: post #19), that will be an issue for PB megaAVR (partial swing high frequency crystal oscillator, it reduces current consumption); there are a few solutions.

ATMEGA328pb Frequency Instability issues-- Solved | AVR Freaks

edit2 : a PB megaAVR with a 16MHz crystal :

ATmega324PB_Xplained_Pro

[page 3, C1]

Reduced load capacitance crystal, some HC49 are though not the jellybean ones

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Jan 2, 2020 - 08:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

newbie123 wrote:
using my homemade programmer on this group of atmega328pb, I discovered that it will never verify consistently.

I can only conclude there is something in your homemade programmer the pb does not like.

Can you post some clear pictures and schematics of your adapters, the one with the isp connector is most suspect.

Jim

 

 

 

 

 

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

has NOTHING except a crystal and two 22pF caps, and an ISP header.

That's very worrying sad so no bypass caps and not ALL GND and VCC including AVCC connected??

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:

has NOTHING except a crystal and two 22pF caps, and an ISP header.

That's very worrying sad so no bypass caps and not ALL GND and VCC including AVCC connected??

this is strictly for programming and mainly to troubleshoot the issue, the destination board (I used over and over again) is working fine with bypass caps.

Yes VCC connected and both GND. The AVCC is connected to VCC. This is a TQFP package. On the PB version there is only one VCC and AVCC.

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

So far, I have not run into any problems with the PB versions; but I have a good ground plane under and around the oscillator. When I measure the precision of the oscillator for a few days (to a corrected time source), it is clear that the low power oscillator wins in terms of accuracy, but it is not beginner-friendly. I have an In-Circuit Programming (ISP) header on my destination boards, so the oscillator is shielded during programing, and that may be necessary for these PB chips (both 324pb and 328pb).

 

newbie123 wrote:
On the PB version there is only one VCC and AVCC

 

The 324pb and 328pB only allow 100mA max because of the loss of the ground and power pins (a 328p allows 200mA max.)

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

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

ron_sutherland wrote:

So far, I have not run into any problems with the PB versions; but I have a good ground plane under and around the oscillator.

 

The target board also has a ground plane around everything, top and bottom layers.

Because this is a TQFP, my thoughts were to save the board and simply test it on a breakout board.

You can only install it and remove it so many times before the small pads give out.

 

This way if it fails, I can just plug in the test board to my labtool universal programmer and see what the problem was.

I now have 12 atmega328pb (out of 25) that do not verify, some have no signature, or the "1E" is gone from the signature.

 

Reminds me of the AT90S1200 which was always famous for 00 00 00 signature for no reason at all. I remember a workaround for this was

to erase the chip, wait 1000mS, reset the chip, then re-enter programming mode, and resume programming.

Still there were some signature bytes erased even after doing the above.

 

ron_sutherland wrote:

I have an In-Circuit Programming (ISP) header on my destination boards, so the oscillator is shielded during programing, and that may be necessary for these PB chips (both 324pb and 328pb).

The 324pb and 328pB only allow 100mA max because of the loss of the ground and power pins (a 328p allows 200mA max.)

 

Some of the usbasp supply power to the board, others do not. (there is a small jumper pad on my usbasp to modify this)

So why would you need more than 100mA just to program the chip?

 

I have programmed the atmega328pb on this same board numerous times without any problem whatsoever.

 

So my main question again is:

Does anyone else have this problem? I do see the OP was having difficulty programming the same device.

 

WHY wouldn't microchip supply the necessary information if the chip is different? (Programming wise)

 

I am well aware of the differences in power consumption between the P series and the PB series but there is nothing mentioned

regarding programming. I have read the AT15007 app note.

 

Smells like a bad batch of chips to me, because my programming apparatus works perfectly on all other avr's except this batch of atmega328pb.

(other batches before this are easily programmable)

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

newbie123 wrote:
why would you need more than 100mA just to program the chip?

 

It is a concern related to the loss of ground and power pins, not your programming problems.

 

A difference from your issue is that I have been using an Arduino Uno with the ISP sketch to program most and a few with an R-Pi (avrdude -c linuxspi).

 

I use a jellybean HC49 crystal with 20pF load capacitance (27pF on each side, 20pF = 6.5pF +(27pF*27pF)/(27pF+27pF)). The datasheet said up to 22pF load capacitance. I hope it keeps working with my parts; the timing accuracy is within spec, as I said. I fear that I could run into some that don't want to start when cold (see post #22).

 

https://blog.adafruit.com/2012/01/24/choosing-the-right-crystal-and-caps-for-your-design/

 

I will include the layout of part of a board that seems to work for reference.

 

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

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

Its not a clocking issue.

 

I injected a 32KHz square wave into xtal1 to see if it makes a difference, it does not.

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

Last note and I'm out. The clock failure detection bit (CFD fuse in the Extended Fuse) caused an issue, but I forgot about it.

 

https://github.com/MCUdude/MiniCore/commit/33e4b32abe9a493300fbff86fb41340a1a7fa5bd

 

Does your avrdude setup do that?

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

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

ron_sutherland wrote:

The clock failure detection bit (CFD fuse in the Extended Fuse) caused an issue, but I forgot about it.

 

Thank you for that!

I was thinking this might be a problem but the fuse is not listed in the atmega328pb datasheet.

statements like:

are very confusing when they don't make sense. They should proof read their datasheets, I find lots of mistakes like this all the time.

 

I assume the CFD works when the other clocks fail. The datasheet mentios a fuse but it's no where to be found.

Again I don't see the fuse listed in any of the three fuses. I am guess ing its bit 4 in the extended fuse byte, however

I don't like to "GUESS" when it comes to fuses especially when the device is an smd one.

 

my datasheet

Last Edited: Fri. Jan 3, 2020 - 09:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I recall something about CFD not being disabled on the parts I got from Digikey, but that was some time ago. I added an avrdude"-C +328pb.conf" to my Makefile, and the problem went away.

 

https://github.com/epccs/RPUpi/blob/master/Remote/Makefile#L65

 

https://github.com/epccs/RPUpi/blob/master/lib/avrdude/328pb.conf

 

This is from the datasheet I have:

 

 

and its rev

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

Last Edited: Sat. Jan 4, 2020 - 05:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thank you for responding Ron,

 

the fuses were always programmed

-U lfuse:w:0xcc:m -U hfuse:w:0xdf:m -U efuse:w:0xf6:m

I tried disabling the BOD, still it does not affect bit #3.

-U lfuse:w:0xcc:m -U hfuse:w:0xdf:m -U efuse:w:0xf7:m

So the CFD bit has been disabled (0) all along.

 

I tried to program the extended fuse byte to 0xFF (just as a test)

however avrdude won't verify that value,

it reads back 0xF7.

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

A patch for avrdude was provided, but as far as I know, the only way to set or clear the CFD bit with avrdude is with MCUdude/MiniCore or a config file like I use. I do not recall the problem it caused, but I think it was a show stopper (some parts worked, and some did not... hmm).

 

https://savannah.nongnu.org/patch/?9811

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

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

So the CFD bit has been disabled (0) all along.

Zero means ON or programmed.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

For reference, this is the parent part setting (facchinm is from Arduino).

 

https://github.com/facchinm/avrdude/blob/master/avrdude.conf.in#L8761

 

And this is how avrdude uses that stuff.

 

https://www.nongnu.org/avrdude/user-manual/avrdude_13.html#Part-Definitions

 

And yet another trap I forgot about; avrdude -v <= 6.2 and "-c stk500v1" returns "0" for unused bits ( -v >= 6.3 was changed). I have no clue what "-c usbasp" will do or what version of avrdude you are using.

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

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

js wrote:

So the CFD bit has been disabled (0) all along.

Zero means ON or programmed.

I think (according to the datasheet Zero is disabled.

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

ron_sutherland wrote:

For reference, this is the parent part setting (facchinm is from Arduino).

 

https://github.com/facchinm/avrdude/blob/master/avrdude.conf.in#L8761

 

And this is how avrdude uses that stuff.

 

https://www.nongnu.org/avrdude/user-manual/avrdude_13.html#Part-Definitions

 

And yet another trap I forgot about; avrdude -v <= 6.2 and "-c stk500v1" returns "0" for unused bits ( -v >= 6.3 was changed). I have no clue what "-c usbasp" will do or what version of avrdude you are using.

I am using avrdude 6.3. 

 

Not sure if it was already patched?

 

I will have to check tomorrow.

 

If not, I have NO IDEA on where to begin to patch it, I won't be able to compile it if necessary.

 

Thanks for your advice.

Happy New Year!

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

according to the datasheet Zero is disabled.

 Yes the CFD is disabled but the fuse is programmed (0=programmed). See #32 above

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

newbie123 wrote:
I won't be able to compile it if necessary.
There are instructions on how to build AVRDUDE on for Windows.

Which Windows?  (due to post #12)

If Windows 10 then Debian is available and buster nearly has the current AVRDUDE.

 

Get Debian GNU/Linux - Microsoft Store

https://packages.debian.org/search?keywords=AVRDUDE&searchon=names&suite=all&section=all

http://svn.savannah.gnu.org/viewvc/avrdude/

WSL 1 has USB and COM; these are planned for WSL 2 :

https://docs.microsoft.com/en-us/windows/wsl/wsl2-faq#can-i-access-the-gpu-in-wsl-2-are-there-plans-to-increase-hardware-support

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Sat. Jan 4, 2020 - 05:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or try the 328pb.conf file from post #32. Place it in the folder you are going to run avrdude from (e.g., probably where the hex file is). Then try the -C option (e.g., "avrdude -v -p m328pb -C +328pb.conf -c usbasp -P usb -B 8.0 -e -U efuse:w:0xFD:m")

 

 

update: efuse rather than flash upload

 

update2: I have been enabling the CFD all this time (believed I was turning it off), so my lack of programing issues may have little to do with a working crystal (what a cluster_f).

 

update3: (the Spin Doctor) It is known that the 328pb has startup problems with jellybean HC49 20pF load capacitance crystal, but CFD ensures easy programming, and once the crystal is going, it *switches* to that time base with very good accuracy and stability. That *switches* stuff is wishful thinking, I need to look at the datasheet some more.

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

Last Edited: Sat. Jan 4, 2020 - 09:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just an update:

 

I received a TQFP spring loaded adapter today.

 

For curiosity, I wanted to see what the fuse values were in two of the atmega328PB

devices that crapped out when I was trying to program the flash

(AGAIN I was not trying to program the fuses)

 

My Labtool programmer warns if any pins are poorly connected, so the results are valid.

Just to be certain, I programmed the flash after reading the device and it verified.

The fuses were restored on two devices only, I have yet to recover the other ones.

 

Here are the results using my parallel programmer:

 

one device: 

FuseL: 0x1C

CKDIV8

CKOUT

SUT1

CKSEL1

 

FuseH: 0x1B

reset disabled

Debug wire enabled

BOOTSZ1 

SPIEN

 

FuseExt: 0xF7 (notice this one programmed correctly)

CFD disabled, bod disabled

 

another one:

FuseL: 0x86

CKOUT

SUT1

SUT0

CKSEL0

CKSEL3

 

FuseH:0x1F

reset disabled

Debug wire enabled

SPIEN

 

FuseExt: 0xF7 (again this one is good)

CFD disabled, bod disabled

 

Just wondering How can this happen when the flash is the only section being programmed?

Originally I programmed the fuses (BEFORE PROGRAMMING THE FLASH) and they verified:

-U lfuse:w:0xcc:m -U hfuse:w:0xdf:m -U efuse:w:0xf7:m

or

-U lfuse:w:0xcc:m -U hfuse:w:0xdf:m -U efuse:w:0xf6:m

 

Last Edited: Tue. Jan 7, 2020 - 02:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought it was just me! Mega328PB seems to program, but it runs at the wrong speed then it refuses to connect to the programmer again. The external crystal is not oscillating. I do seem to remember some boards ended up in debug mode, but I've a fail rate of about 50% on a product I've made hundreds of using the Mega328P..

I'm programming using the same Elf file as I have used for years. Just ignoring the CPU type check.

Using the latest Atmel AVRProg programmer.

 

**EDIT **

So clearly my issue is that the Fuses for the oscillator were not valid - yet some devices chose to function while others didn't.

I took a non communicating chip ( non oscillating ) and changed the crystal from 16MHz to 12Mhz and I could then connect to it with the programmer.

I then corrected the oscillator fuses which were invalid and made them valid, changed the crystal back to 16MHz and the part is recovered.

 

Last Edited: Wed. Mar 18, 2020 - 04:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rowifi wrote:
The external crystal is not oscillating.
PB-series megaAVR require a crystal or resonator with reduced load capacitance.

Recommended Capacitor Values | AVR® Microcontroller Hardware Design Considerations

Pololu - A-Star 328PB Micro - 5V, 20MHz

 

"Dare to be naïve." - Buckminster Fuller

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

Interesting. I have 22pF caps. Changing the Fuses after swapping xtals does fix it, but I will lower the caps to be sure. I probably have a few more to experiment with so I'll change the caps first and see how it pans out.

 

*** EDIT ***

No , reducing the caps to 15pF did not swing it into life.

The chip itself is oscillating because the code is running - albeit at the wrong speed ( probably half ). There is no activity on the crystal and even with a slow programming freq it wont talk.

The fix will be as above I suspect.

Last Edited: Wed. Mar 18, 2020 - 05:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Example Layout of ATxmega32A4 and ATmega324PB Devices | AVR® Microcontroller Hardware Design Considerations

for one part identification for PB megaAVR high frequency crystal/resonator oscillators.

Timing device manufacturers recognize the issue with reduced current high frequency oscillators and have created reduced load capacitance crystals and resonators.

PB megaAVR have CFD that will switch the clock to the internal 8MHz RC oscillator when, not if, the high frequency external timing device oscillators fails (ESD/EFT/EMI/EMC/lightning)

 

"Dare to be naïve." - Buckminster Fuller

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

rowifi wrote:
So clearly my issue is that the Fuses for the oscillator were not valid

Did you work out in what way, exactly, they were "not valid" ?

 

some devices chose to function while others didn't

You have various settings for frequency range, low-power or full-swing, startup time, etc - sounds like you've got something "marginal" ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry for the continual edit.
The Production file being used has always worked without problems for the MEGA328 / MEGA328P From memory ( I can check ) the xtal setting was for full swing with longest startup times.
All boards have 16MHz, 20pF well placed components.
If a 328PB is programmed with this same production file, some boards will run exactly as intended, and will continue to connect to the programmer.
Some boards will run at what appears to be half speed. I guess the is the clock fail circuit, however it is not possible to access the chip using the programmer.
Getting the chip to function correctly requires a slower xtal, whereupon the external oscillation is visible and the programmer can then change the xtal settings to a valid one for this chip.
The issue that appears to temporarily brick the chip is that it won't connect to the programmer while the clock fail mode is running.. the programmer speed is low at 125KHz

From the app notes, I took he following literally
''Existing code for these devices will work in
the new devices without changing existing configuration or enabling new
functions. The code that is available for your existing ATmega328 variants
will continue to work on the new ATmega328PB device.''

Last Edited: Thu. Mar 19, 2020 - 08:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for hanging in there.

rowifi wrote:
... however it is not possible to access the chip using the programmer.
The reset signal will be asserted during AVR ICSP though not all programmers generate a clock signal (to be sunk by XTAL1 or XTAL2)

Pololu - 5.10. Using the clock output to revive AVRs

 


AN_42559 AT15007: Differences between ATmega328/P and ATmega328PB

 

"Dare to be naïve." - Buckminster Fuller

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

Hello ! 

I have the same king of trouble with 328-PB (is PB for Problem ? laugh)

1 - Using Atmel studio, I switch from the internal 8 Mhz to my 16 Mhz. That's works perfect, my MCU is not bricked yet, because I can still read the fuses. 
2 - Then I try flashing the memory with Blink.ino.hex (which is a .hex generated for ATMEGA 328P (5V, 16Mhz) in arduino IDE. It is just the "Blink" example). 
Please note that I do not flash the file "Blink.ino.with_bootloader.hex", that contains the bootload (as written ... )

3 - Get an flash verification error (read 0x00 instead of 0x0C blabla)

4 - There my MCU is bricked. 

Did anyone here successfully solved this issue ? 
Is there a way to revive theses bricked MCUs ? 

Thanks a million 

PeterMike

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

PeterMike wrote:
Get an flash verification error

 

So this has nothing to do with the topic of the thread: "Programming ATmega328PB ispEnterProgMode fail

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PeterMike wrote:
3 - Get an flash verification error (read 0x00 instead of 0x0C blabla)
AVR NVMC consume a significant current with significant di/dt that may make the AVR's VCC regulator unstable; if the burn succeeds with a battery substitute for that regulator then do a further review of mega328PB VCC and GND.

PeterMike wrote:
Is there a way to revive theses bricked MCUs ?
yes

Tutorials | AVR Freaks

first sticky thread

 

"Dare to be naïve." - Buckminster Fuller

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

Yes it does actually ! 

After the flash verif error shows up, I cannot anymore program the chip : get something like "could not enter programming mode"
(That's what I call bricked, sorry for my unclear message)
Exact same problem described by LuisSousa in the first post. 

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

gchapman wrote:

PeterMike wrote:
Is there a way to revive theses bricked MCUs ?
yes

Tutorials | AVR Freaks

first sticky thread

 

Yes, I know that. But I'm not facing an "external clock not working" or "external clock not present" as my external 16Mhz was working : once I switched on it, I was still able to read fuses / chip id. 
Therefore, I won't be able to revive the chip applying a 1MHz clock signal to the XTAL1, would I ? 
 

Last Edited: Mon. Apr 20, 2020 - 10:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PeterMike wrote:
Did anyone here successfully solved this issue ? 
Is there a way to revive theses bricked MCUs ?

You didn't say, is the chip through hole or smd?

I got a TQFP adapter because I had quite a few of these that were bricked.

If you can't fix it by following these tutorials, then

You can fix it with parallel mode OR get a fuse doctor.

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

I thought I posted what the problem was.. for me anyway.
The pb chips are NOT 100% code compatible if you use a production file.
The fuses can be in an invalid state OSCILLATOR FAULT DETECT or something like that will not be set correctly. The oscillator runs but it won't program anymore at the higher speeds.
I changed the xtal to a lower value, and it worked, then I could set the fuses correctly and replace with 16 MHZ at all was fine after that. Repeatable on many PB chips.

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

newbie123 wrote:

PeterMike wrote:
Did anyone here successfully solved this issue ? 
Is there a way to revive theses bricked MCUs ?

You didn't say, is the chip through hole or smd?

I got a TQFP adapter because I had quite a few of these that were bricked.

If you can't fix it by following these tutorials, then

You can fix it with parallel mode OR get a fuse doctor.

Thank's you for your reply ! 

Yes it's SMD ... 

I still have access to XTAL1 and GND. So I should be able to unbrick. 
I'll let you know ! 

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

rowifi wrote:
I thought I posted what the problem was.. for me anyway. The pb chips are NOT 100% code compatible if you use a production file. The fuses can be in an invalid state OSCILLATOR FAULT DETECT or something like that will not be set correctly. The oscillator runs but it won't program anymore at the higher speeds. I changed the xtal to a lower value, and it worked, then I could set the fuses correctly and replace with 16 MHZ at all was fine after that. Repeatable on many PB chips.

Ok I will try the to set XTAL1 at 1Mhz, see if I can reprogram. 

It is still mysterious that when I program the flash only, the fuses change isn't it ? 

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

PeterMike wrote:

It is still mysterious that when I program the flash only, the fuses change isn't it ? 

Yes this happened to me.  Didn't matter what programmer I used, avrdragon, usbasp, avrisp.

 

If you are using avrdude you need to update the avrdude.conf file so it works with the 328PB device.

See my post #12 in this thread.

Last Edited: Thu. Apr 23, 2020 - 12:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What I meant was to physically change the external crystal from 16MHz to 12Mhz (which is what I had to hand) which then allowed the programmer to connect.
If it's already been programmed to use the internal oscillator and won't program I don't know what to do, perhaps try an external crystal, but not to high frequency I guess.
All by target boards were initially programmed from a production file that was designed to program a 168 or 168P. The first program action appeared to work, but most (not all) devices would subsequently not connect until after the fix.
What threw me for ages was that the crystal could be seen to be oscillating at 16MHz , yet the programmer would not find the device until I changed it.
Note also the crystal capacitors should be much smaller than the normal chips. I didn't notice that requirement until later, but I didn't change them from 22pf and all was ok, but perhaps not recommended.

Last Edited: Thu. Apr 23, 2020 - 06:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi ! 

So I cutted the line between XTAL1 and my external circuit. Applied the 1Mhz signal to XTAL1 (0-4V). But it did not work. I'm still getting this error : 

Severity:        INFO
ComponentId:    20000
StatusCode:    0

Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00 (Command has failed to execute on the tool)

Unable to enter programming mode. Verify device selection, interface settings, target power, security bit, and connections to the target device.

On another boad, I simply lowered the capas. From 15pF to 8.2 as you suggested rowifi. Same error ... 

I'm not  

 

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

External crystal and external clock are different modes. In my case the original firmware set the chip for external crystal, but the oscillator fail fuse (s) was indeterminarets because the original production file does not access it.
I replaced the external crystal at 16MHz with a 12MHz one. I did not apply an external clock signal.

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

PeterMike wrote:
Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00 (Command has failed to execute on the tool)

Unable to enter programming mode. Verify device selection, interface settings, target power, security bit, and connections to the target device.

What fuses have you programmed?

Do you remember what values were for each fuse?

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

I don't. Not off hand, but if you cannot connect to it then you can't change them anyway.
If you're starting with a fresh device, then make sure the programmer shows you all the fuses and their current states, particularly the clock monitoring fuse. If it doesn't show the fuse then you don't have anychance to program it correctly.

When I finally got access to the device using the programmer, the clock monitor showed 'invalid' for the fuse setting. Once I set it to a valid value I had no further problem reprogramming the chip.

But as I said, the initial programming was done using a production file using AVR studio and an AVR Prog programmer. The production file was for a Mega328, so it clearly omitted or had an invalid value where the clock monitor fuse was supposed to be ( 0xFF if I remember ).
Despite oscillating, the chip refused to connect or function until I physically changed the crystal to a lower value. Not all chips failed but 50% did and all were recovered to a working state once the fuse was corrected.

That's all I can offer, but it had plagued me with many faulty circuits until I decided it needed analysis.

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

newbie123 wrote:

PeterMike wrote:
Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00 (Command has failed to execute on the tool)

Unable to enter programming mode. Verify device selection, interface settings, target power, security bit, and connections to the target device.

What fuses have you programmed?

Do you remember what values were for each fuse?

 

Yes ! 
From : 
E : 0xF7
H : 0xD9

L : 0xE2

I went to :
 

E : 0xF7
H : 0xD9

L : 0xFF

As you know, this change on L fuse from 0xE2 to 0XFF is made to switch clock source from the internal 8 Mhz to the external 16Mhz . 
Tried on 6 boards, the switch worked perfectly: I was still able to read the device id, fuses etc ... 

Then I tried to flash a firmware (using both avr dude, not updating the fuses and avr studio): a arduino blink example (without bootloader) for ATmega328P, not PB. Got the error. Could not do anything then ... 

 

 

Last Edited: Sat. Apr 25, 2020 - 10:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rowifi wrote:

I don't. Not off hand, but if you cannot connect to it then you can't change them anyway.
If you're starting with a fresh device, then make sure the programmer shows you all the fuses and their current states, particularly the clock monitoring fuse. If it doesn't show the fuse then you don't have anychance to program it correctly.

When I finally got access to the device using the programmer, the clock monitor showed 'invalid' for the fuse setting. Once I set it to a valid value I had no further problem reprogramming the chip.

But as I said, the initial programming was done using a production file using AVR studio and an AVR Prog programmer. The production file was for a Mega328, so it clearly omitted or had an invalid value where the clock monitor fuse was supposed to be ( 0xFF if I remember ).
Despite oscillating, the chip refused to connect or function until I physically changed the crystal to a lower value. Not all chips failed but 50% did and all were recovered to a working state once the fuse was corrected.

That's all I can offer, but it had plagued me with many faulty circuits until I decided it needed analysis.

Tried with another 16 Mhz.
And also a 8 Mhz. 

Still cannot reprogram :/

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

Try this on a device that is not bricked:

 

Fastest Startup:
Low: C6
High: DF
Ext: F7

 

Slowest Startup:
Low: F7
High: DF
Ext: F7

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

Thank you ! 

But I have no longer not bricked boards. 

I'm currently updating my design, with a m328P this time. 
It's around 50% more expensive than the PB. But I think it's worth it (to avoid theses troubles) doesn't it ?  

Last Edited: Sun. Apr 26, 2020 - 09:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PeterMike wrote:
I think it's worth it (to avoid theses troubles) doesn't it ?

 

Yes this is what I did. (switched back to atmega328p from atmega328pb)

Never one single problem!

 

Although one of my boards uses PE2 & PE3 which are not on the m328P.

So in this case I have no choice.

 

I have a TQFP adapter that I use to program and test before soldering the device on the board.

This way i can repair it if something goes wrong.

 

Thankfully this is not a high production item, I would have lost

a lot of boards and $$$!

 

I found that the fuse values I posted above are working for me, although I have only programmed the device

a dozen times or so with these fuses. So far no bricked devices.

 

I chose "External Full Swing Crystal" instead of

the obvious

"External Low Frequency Crystal"

and the board is working and programming without bricking.

 

Are you able to remove the atmega from your boards to attempt repair?

Or at least to find out what fuse values were actually programmed

(even though you didn't program the fuses)

 

 

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

newbie123 wrote:

Yes this is what I did. (switched back to atmega328p from atmega328pb)

Never one single problem!

 

Just ordered the new hardware with 328P.

newbie123 wrote:

I found that the fuse values I posted above are working for me, although I have only programmed the device

a dozen times or so with these fuses. So far no bricked devices.

I wish I could test that ! 

 

newbie123 wrote:

Are you able to remove the atmega from your boards to attempt repair?

Or at least to find out what fuse values were actually programmed

(even though you didn't program the fuses)

 

Unfortunately I use QFN package. That makes king of hard to solder new one. 

newbie123 wrote:

I chose "External Full Swing Crystal" instead of

the obvious

"External Low Frequency Crystal"

and the board is working and programming without bricking.

 

What sounds obvious to me is the opposit:  according to the datasheet, low frequency means something like 32Khz. 
For 8/16Mhz I would indeed choose External Full Swing Crystal, shouldn't I ? 

Last Edited: Mon. Apr 27, 2020 - 12:27 PM