Programming ATmega328PB ispEnterProgMode fail

Go To Last Post
70 posts / 0 new

Pages

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...

Pages