Electronics > Microcontrollers

Atmega168 self-destruct on read?

(1/3) > >>

obiwanjacobi:
I was trying to retrieve the firmware from an Atmega168(20AU). I traced down the ISP pins and soldered a header on the PCB.
I was using an Arduino UNO as ISP and used avrdude on the command line to read the flash.

When I powered the target board up, I could see the original startup message on the display.

I tried reading the flash and avrdude gave me an error that the part-code was not correct. I used the -F flag to ignore it to read the flash.
I got a 16k file with all zero's and the target board no longer shows it's welcome message after a reset.

I think I blew something up.  ::)

Q: Is it possible to program an atmega168 in such a way that it erases itself when read?

Was there something I should have done first? (I later realized that I could have started with reading the fuses...)

---

This is the device in question:
https://www.eevblog.com/forum/repair/repair-attempt-tc-electronic-nova-system-dsp-audio-(guitar)/msg593928/#msg593928

T3sl4co1l:
I haven't exactly misused my tools intentionally, so I can't say for sure, but it's a common problem using the old MEGAs, the ISP pins are also the SPI peripheral, so you usually need some facility to isolate those pins from attached peripherals (if used) when programming.  Or only program out-of-circuit.

If so, it's extremely likely that you 1. neglected to trace the circuit and see what else is connected to these pins, and 2. the connected device asserted MISO during programming, corrupting commands/data.  I don't know what commands this would assert, but it might well be an erase cycle is among them.  It could also be that it got programmed with trash, or that the fuses are all wrong.

Lesson: if AVRdude reads all zeroes, you have data corruption.  You will not read or write anything meaningful by forcing to proceed. Check your connections and try again.

Tim

westfw:

--- Quote ---Q: Is it possible to program an atmega168 in such a way that it erases itself when read?
--- End quote ---
No.  But you shouldn't have needed -F, and the "part code incorrect" message could have meant that something was mis-wired, and using -F forced avrdude to proceed anyway, and damaged the chip.
The "use -F to override" "suggestion" ought not be there; it's hardly ever the correct solution.

obiwanjacobi:
After reading your comments I realize that I indeed forced the situation (and yes I neglected to trace out where these pins were connected to other than the ISP header). What a stupid mistake - it seems so obvious now. Thanks.

obiwanjacobi:

--- Quote from: T3sl4co1l on May 19, 2024, 04:03:47 pm ---[..] the ISP pins are also the SPI peripheral, so you usually need some facility to isolate those pins from attached peripherals (if used) when programming.  Or only program out-of-circuit. [..]

--- End quote ---

But why would they then have an ISP header on the board?

After some reverse engineering of the PCB I don't think the MCU can be programmed in-place.

The ATmega168's MOSI (PB3) is used as an output - while during programming this is an input (not critical).
But more important the MISO (PB4) is used as an input thus (the peripherals' output) clashing with the output it will be during programming.
The RESET pin seems to be routed somewhere on the PCB but I cannot find where it goes/connected to (as of yet).

I just don't understand why they'd have a ISP header when this would never work, not even for first time programming (unless they leave off a bunch of ICs).
Or am I making a mistake in my reasoning?

The question is now: what did I blow up with my stunt of trying to read the MCU? Just the MCU or also the peripheral chip that outputs to PB4?

Navigation

[0] Message Index

[#] Next page