Atmega168 self-destruct on read?

[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]

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

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]

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

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?

[T3sl4co1l]

Clashing logic outputs is discouraged, but rarely fatal.  Typically the stronger one dominates, everything else reads a valid logic level, and that's that.  The loser sees high power dissipation, but probably not for long enough to be damaged.

I doubt anything is damaged on your board... just braindead.

Perhaps they had a means to disable the offending components: jumpers, a disable code before programming, other headers with functionality you haven't discovered yet, or just removing whole components (resistors, jumpers, chips) in the rare event that an ISP cycle must be done (chips would then be programmed from the factory for assembly).  Seems unlikely an ISP header would be left in in the latter case, but *shrug*, header stock is cheap.  I have no way to tell from here.

Tim

[coromonadalix]

@Teslacoil   shitty ways to explain ....   simply put   you'll read nothing good,  done that  many times,  no damages

And for the icsp port if it's available and other parts are not conflicting,  you can read and reprogram in situ,  sometimes  you may need to add wires and or remove a part on the mcu programming pins ....  or  put the hole circuit in constant reset, because while programming you may get some bad behaviour, thrust me i know  loll


To program you have to change the fuses accordingly and put back a firmware ....

Only thing  who comes to mind is :   many have tried the glicthing tricks,  not sure it could work on theses mcu's

[obiwanjacobi]

I have an almost complete schematic of the board now and I think that the outputs of the peripherals that could clash with the SPI interaction were disconnected.

There are two tiny ICs that have VCC+GND and connect to the output of the peripheral (74HC165 serial output) and the MCU input - but also have an enable signal.
Because two of these ICs outputs connect to the same pin on the MCU I gather their outputs are floating when not enabled.

I can't read the markings on the IC - even with my optical amplifiers... 

I also discovered a jumper on one of the SPI lines (MOSI or MISO can't remember which) that I overlooked.
So one of those must have been disconnected when I tried to read the MCU...

Next step is trying to write some code to interact with the hardware.

[obiwanjacobi]

We're in like Flynn...


I temporary put a pot on the display's contrast pin for I didn't want to write PWM pin code just yet...

[Psi]

Yeah, -F is never the answer.
Never try to use it in anger when things are not working, it's never the solution.

The only time I've ever had a legit use for -F was when trying to program a device that avrdude did not yet support.
There was another MCU that was effectivity the same as the unsupported one and using -F got it working well enough to do what I wanted.

[obiwanjacobi]

Yeah, yeah I've got it. 
But what's done is done and we go from there...