Programming ATmega328PB ispEnterProgMode fail

Go To Last Post
70 posts / 0 new

Pages

  • 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

Pages