1
\$\begingroup\$

I have a working device with flashed ATtiny13A inserted in DIL8 socket. I am guessing that the uC does not have a locking bit set (since I was able to read it [?]). That is all I know at this point.

I tried dumping the flash contents into a Intel *.hex file and "succeeded" using USBasp programmer and AVRDUDESS (GUI for AVRDUDE). I tried several dumping formats (V1a trough V1c). Picture attached.

AVRDudess read settings used

After a dump, I inserted a brand new ATtiny13A into the programmer socket and used the V1b (Intel hex) to burn / write the hex into the uC. Everything went fine according to AVRDUDE(SS), but I even went on and verified - no issues reported.

Now, when I insert this newly flashed uC instead of the original, the circuit is not working. What am I missing here? Is there a locking bit preventing this from working ... do I need to pay attention if the fuses are set and how to double check all of this?

\$\endgroup\$
8
  • \$\begingroup\$ Maybe it is a EEPROM problem, you are not copying it. The software may be doing stuff with the EEPROM that you didn't copy so it going into failure mode ? I can't comment on your procedure as I have never done that. Try to read the EEPROM just to see if there is something in it \$\endgroup\$ Commented Mar 14, 2022 at 8:44
  • \$\begingroup\$ @Mat That is one solid observation! I thought EEPROM section was only for reading older EEPROMs using sockets adapter board for my USBasp programmer. May I ask you for word of advice if I can read / dump the EEPROM the same way I did for flash memory? I mean if this is a standard procedure, I suppose AVRDUDE(SS) would be able to do it ... And if it is - I write them both to the new empty mC - right? Thank you. \$\endgroup\$ Commented Mar 14, 2022 at 8:52
  • \$\begingroup\$ It depends on the circuit. Most likely you did not read the fuse bit settings and applied them also to the new MCU. Did you try that? \$\endgroup\$ Commented Mar 14, 2022 at 8:55
  • \$\begingroup\$ I have no idea you need to check on your programmer if it's something possible. Yes you can then "just" write the flash and EEPROM to the new µC considering that the read works \$\endgroup\$ Commented Mar 14, 2022 at 8:55
  • 1
    \$\begingroup\$ I would like to thank you both @Justme and Mat for setting me on the right path - I've managed to copy over the contents successfully and my circuit is now working with the duplicated MCU. Strange thing was that I've read lock bit LB = 0x3F, but did not write it to a new MCU and everything worked. I burned flash dump + EEPROM dump, together with writing only the fuse values (without lock bits). Learned a lot today thanks to you guys! \$\endgroup\$ Commented Mar 14, 2022 at 9:50

1 Answer 1

Reset to default
3
\$\begingroup\$

Fuse bits need to be set correctly for the program to run as intended, which includes correct clock settings, clock speed, and BOD levels if used.

Without correct settings the software will not even run at all or at proper speed, so e.g. EEPROM contenta may be irrelevant. You can of course check if the EEPROM is empty or not so it may not need to be copied at all.

\$\endgroup\$
1
  • \$\begingroup\$ True. EEPROM dump is not exactly empty, but it is not huge as well - just like 3 lines of string values. But, after only writing the EEPROM (at this point flash memory was written already) - the situation did not improve ... Only after clearing the MCU completely, burning flash + EEPROM dumps inside the same session consecutively and setting the fuses while at it (whose values I've read previously from the source MCU) - did it all start functioning afterwards. \$\endgroup\$ Commented Mar 14, 2022 at 11:32

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.