0
\$\begingroup\$

I'm working on a small "cartridge"-like subsystem which attaches to the main device via a 20-pin connector.

On the cartridge, there is an ATmega16a microcontroller and an AT45DB081D flash. I needed to modify a couple of bytes in the flash (external to MCU), so I did the following:

  • Used a SOIC-8 test clip to connect the flash chip to an SPI interface on a Raspberry Pi.
  • Used flashrom to read the binary contents 3 separate times.
  • Used sha512sum to ensure the binaries were identical - they were.
  • Modified the binary and flashed it back to the device - it verified.

I then noticed that the host device identified the cartridge as invalid/faulty, so I reflashed the original binary.

The device still recognises the "cartridge" as faulty even after reflashing the original binary, so my question is:

Are there any mechanisms in this flash device which would allow the MCU to identify it as errant, even after reflashing the original binary as seen by flashrom?

\$\endgroup\$
5
  • \$\begingroup\$ Did you erase before re-programming? \$\endgroup\$ – Andy aka Jul 31 '19 at 10:30
  • \$\begingroup\$ No I didn't. It was my understanding that flashrom reads the existing contents of the flash, compares that with your binary, then only overwrites addresses that are different. It then verifies the write, so I can't see how the contents of the flash could be any different to what I expect. \$\endgroup\$ – Benjamin Crawford Ctrl-Alt-Tut Jul 31 '19 at 10:37
  • \$\begingroup\$ Was the original binary data correctly read out? A badly connected jumper wire could end up reading all bits as 0 or 1. Reading it three times would still always match identical garbage. \$\endgroup\$ – Justme Jul 31 '19 at 11:20
  • \$\begingroup\$ The data contained strings that would suggest it was valid. \$\endgroup\$ – Benjamin Crawford Ctrl-Alt-Tut Jul 31 '19 at 11:50
  • \$\begingroup\$ Verify the contents of the external flash, any of its lockable configuration bits, the MCU flash contents, and also the MCU fuses. Beware that if you hold an ATmega in reset while manipulating the SPI lines with something else you may accidentally perform an ISP operation corrupting the contents or fuses. Use a hot air tool to replace both the flash and the ATmega one at a time and see which the problem "follows". Debug the issue from the software of the host system, or use a logic analyzer to monitor communication and compare working and non-working cases. \$\endgroup\$ – Chris Stratton Jul 31 '19 at 16:01
0
\$\begingroup\$

I would guess that you damaged something on your "cartridge" when you attached the test clip. It sounds like you were connecting a powered Raspberry Pi in parallel with the ATmega16 and possibly other devices on your cartridge. This kind of thing must be done carefully to isolate the flash from the rest of the circuit during programming.

\$\endgroup\$
1
  • \$\begingroup\$ That's very possible. All active devices on-board accepted 3.3V VCC, but there might have been some nasty reverse powering occurring somehow. I'll check it out. \$\endgroup\$ – Benjamin Crawford Ctrl-Alt-Tut Jul 31 '19 at 12:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.