(atmega88pa) safemode: lfuse changed! was f7, and is now 0

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

Hello,

 

I have a big problem with an OSD (on screen display) based on an atmega88pa.

I was trying to flash it with an updated firmware, and something went wrong.

After the reading, erasing, writing and reading cycle, the verification failed, and the fuses went zero:

 

verification error, first mismatch at byte 0x0000
0x00 != 0xb7
verification error: content mismatche
safemode: lfuse changed! was f7, and is now 0
safemode: and is now rescued
safemode: hfuse changed! was dc, and is now 0

Now the led on the OSD doesn't light up anymore and I can't connect with usbasp, it gives me:

 

avrdude.exe -p m88p -c usbasp -U lfuse:w:0xF7:m -U hfuse:w:0xDC:m

avrdude.exe: error: programm enable: target doesn't answer. 1
avrdude.exe: initialization failed, rc=-1
             Double check connections and try again, or use -F to override
             this check.


avrdude.exe done.  Thank you.

 

after searching, I'm triend the external oscilator method, I'm using an arduino uno to simulate a 1Mhz osciloscope on a pin I link to TOSC1 pin on the atmega88pa ship (I did it some years ago to save a remote controller after a bad flashing), but it's not giving any result, the atmega88pa is still unreachable when trying to set the original fuses :

 

D:\> avrdude.exe -p m88p -B 1000 -c usbasp -U lfuse:w:0xF7:m -U hfuse:w:0xDC:m

avrdude.exe: set SCK frequency to 1000 Hz
avrdude.exe: error: programm enable: target doesn't answer. 1
avrdude.exe: initialization failed, rc=-1
             Double check connections and try again, or use -F to override
             this check.


avrdude.exe done.  Thank you.

Do you have any other tracks i could try to save this osd?

 

thanks in advance,

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

You may have to use HVPP or a new chip. If the chip is T/H then a STK500 (if you can get a hold of one) should do the trick.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Sadly I dont have access to such tools, and the whole thing is 2 by 4cm, difficult to work in. Before I consider it dead can I try something else with my limited tools?

Attachment(s): 

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

Where is the programmer connected to? I can only see 3 wires instead of 6.

 

Edit also I don't see an Ext fuse value being sent to the programmer.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Fri. May 15, 2020 - 05:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use the connectors on the other side of the board (see attachement, except MOSI who where cut there, I soldered it on the front side instead (pin 15 on the shema attached).

I'm connecting the adruino to pins 7 and 8 of the atmega88pa (soldered to the existing, now cut, oscilator).

I am almost sure the connections are good, but I keep getting the same  error message:

 

D:\> avrdude.exe -p m88p -B 1000 -c usbasp -U lfuse:w:0xF7:m -U hfuse:w:0xDC:m

avrdude.exe: set SCK frequency to 1000 Hz
avrdude.exe: error: programm enable: target doesn't answer. 1
avrdude.exe: initialization failed, rc=-1
             Double check connections and try again, or use -F to override
             this check.

avrdude.exe done.  Thank you.

I used 4Mhz on the adruino oscillator and 1Mhz on the usbasp, also 1Mhz on the oscillator and 500khz on the usbasp, still no results, can you suggest any better values ? or my problem is elsewhere ?

 

thanks

Attachment(s): 

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

Drop the ISP frequency right down, try it at 100kHz and see if it makes any difference.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

I don't see a bypass cap on VCC/GND pin pair? should be located near the chip.

atbob88 wrote:

-B 1000

Most china made USBasp's, detect and sets this value for you and ignore this param.

Try reading the signature, until that works, nothing will.

How is the board powered?  from the USBasp?

 

Jim

 

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Brian Fairchild wrote:

Drop the ISP frequency right down, try it at 100kHz and see if it makes any difference.

 

I tried, even at 500hz (the lowest I could get) without any result.

 

 

ki0bk wrote:

How is the board powered?  from the USBasp?

I tried powering it with the usbasp (vcc & gnd ) and from it's own 7.2v power input, same result.

 

I think I tried everything from this approach, now I will make the circuitery and try the HVPP method.

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

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

 

I tried the external oscilator method (with an arduino uno as oscilator) with no success.

I wanted to make a HVPP but found it impossible (with my limited tools and soldering skils) to connect this number of pins to a HVPP, the chip is very small and on a board, if only it could be recovered with HVSP it would be much easier.

for now I stoped trying, if I found a beter and "feusable" way I will try it.

 

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

If RSTDISBL got programmed somehow, then HVPP is your only way out.

 

However note that there are some oscillator modes which, if configured, may require a very slow clock be injected (say, if the low-frequency crystal oscillator is configured).  Further, if the CKDIV8 fuse is also programmed, the system clock will be ⅛ of that.  And finally, the programming clock must by < ¼ of the system clock.

 

So, try generating and injecting a 32 kHz clock signal into XTAL1.  If CKDIV8 is programmed, this will result in a 4 kHz system clock, so use an ISP clock less than 1000 Hz.

 

If this doesn't work, then it is likely that RSTDISBL is programmed, requiring HVPP.  Another possibility is that the chip is just dead.   Toss it in the bin.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

If RSTDISBL got programmed somehow

Or if the chip is in dW mode, but I looked at the fuses before with the values given above and neither is the case.

 

HOWEVER we don't really know what the fuses are set at because they cannot be read.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

joeymorin wrote:

Another possibility is that the chip is just dead.

 

I don't think it's dead as it all happened after a flashing software reseted the fuses, I don't think fuse change can damage a chip further than locking it.

I will try lowering the oscilator frequency.

 

js wrote:

HOWEVER we don't really know what the fuses are set at because they cannot be read.

 

from the initial flashing tool output, lfuse and hfuse are now 0, if we can trust this reading, can we somehow understand the current setting, oscillator frequency etc ? 

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

atbob88 wrote:
I don't think fuse change can damage a chip further than locking it.
Not fuse changes per se, but there are undocumented ISP (and HVPP) instructions which can alter the internal configuration of the chip (signature row, calibration byte, etc).  Some of those can render the chip permanently unreachable.  If a wiring issue during your last programming session just happened to result in your chip seeing 'the wrong sequence', then you'll be out of luck.

 

It's not a common occurrence.  It's happened to me once (I think).  There has been threads on the subject:

https://www.avrfreaks.net/forum/undocumented-signature-row-contents?page=all

In particular, see the post within that thread here:

https://www.avrfreaks.net/comment/1100311#comment-1100311

It contains links to off-site material.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

atbob88 wrote:

from the initial flashing tool output, lfuse and hfuse are now 0, if we can trust this reading, can we somehow understand the current setting, oscillator frequency etc ? 

Probably 'no, and no'.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

I was trying to flash it with an updated firmware, and something went wrong.

Does the original software still function?  That would say the chip is still operating.

 

      Now the led on the OSD doesn't light up anymore ...maybe that answer the above as NO?  Not sure what LED refers to.

 

Immediately before you tried the update, was your programmer able to communicate with the chip (read the fuses)? 

Never attempt any flashing, until you have a verified functional, solid, glitch-free connection. 

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

Last Edited: Fri. May 22, 2020 - 06:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0



lfuse and hfuse are now 0, if we can trust this reading,

I don't believe you can trust this reading, the programmer simply can't communicate with the chip.

 

If the fuse were changed as shown and the EXT fuse was not touched by the programmer then this is what you have:

 

 

only bit 0 of the EXT fuse seem to do anything and it changes the EXTENDED.BOORST

 

HOWEVER you are changing the BOD to 4.3V so I'm hoping that your board is running from 5V??

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly