Error uploading to ATtiny85/84 with ISP

I will describe my problem as best I can, starting with the ATtiny85. Apologies if it is a bit long, Programming is via Arduino IDE (version 1.8.7) together with DrAzzy’s ATtiny core.

Program is a version of the original DCC++ base station adapted to run on the 85. All code apart from that associated with Mobile Decoder control is stripped to make it fit in the 8Kb of flash memory. I use a second ATtiny85 as controller. Communication between the two is via I2C. The system works great and I am running my small layout using it. (Original discussion is here.)

I now started experimenting with a new version to control Accessory Decoders - need to control those turnouts (this time stripping the mobile decoder code). I started by just loading my original mobile version onto an ATtiny85. Uploading is done using Arduino ISP with an UNO. Upload worked fine and the DCC signal LED light as expected. To verify I am looking at the correct LED, and shows what it is assumed to show, I added the normal diagnostic code to slow the DCC signal down to about 2.5Hz. Diagnostic is normally enabled via an instruction from the controller. Since that is not connected yet, I added it to the end of the Setup() function. Sketch uploaded fine and the LED slowed down to the expected approximate 2.5Hz.

When the processor is slowed down (by 256x), all communications obviously cease and it is necessary to either reset or recycle the power. Restarting, however, runs the same slowed down version so I need to upload the code again with the slowdown removed. This is where the problem started. The ISP programmer now gives an “Invalid device signature” error. I substituted the 85 with a different one and the upload works fine (confirming there is no connection problems). Replace the problem 85 and the error is back (the code is still running pulsing the LED).

Setup is very minimal. ATtiny85 on breadboard with 5V and 0.1uf cap to pin 8, ground to pin 4 and ISP to respective pins. LEDs with resistors to pins 1 and 3.

I initially started with an ATtiny84 (with adapted code), followed the same procedure as above and had the same resulting error message. I thought my little home-made breakout board might have gone faulty, hence the switch to the 85.

Attached the verbose output from the aborted IDE upload.

I would appreciate any ideas to get the upload working again.

Willem

ErrorMessage.txt (3.82 KB)

Try this:

  • Attempt an upload.
  • After the upload fails, copy the avrdude command from the black console windows at the bottom of the Arduino IDE window. You will need to scroll up to see it.
  • Edit the avrdude command as follows: Quote paths that contain a space. Add the option -B32.
  • Run the command from the command line.

The -B32 slows down the bitclock of the programmer and will hopefully allow it to communicate with the slow processor.

Note that you need to leave the Arduino IDE open during this process, as the temporary build folder containing the compiled .hex file you're uploading will be deleted when you exit the Arduino IDE.

@pert

Thanks for your reply.

I tried your suggestion on both the problem 84 and 85 but unfortunately, no luck. I got the same error message (attached).

Using a new 85, I next tried adding the slow down instructions in a separate function. Called the function form the loop using a button. It works correctly and when restarting the 85 it reverts back to full speed and I can be still upload to it. It seems that once the setup slows the processor down, at startup, it cannot be recovered.

I do not know exactly how an AVR processor behaves at startup - need to read up on that. It is, however, a bit disconcerting that by changing the system speed with a program, in the setup() function, you basically brick the processor. I would have thought that when starting an upload the processor gets reset to the fuse settings. Apparently not.

I wonder if this is a peculiarity of the ATtiny’s or the AVR MCUs in general. I am certainly not going to try it on any of my other MCUs.

That was quite a lesson. The ATtiny85 (a DIL package) is not really a problem. The ATtiny84, however, is a VQFN package and is soldered to a small breakout board. I cannot really replace it, it is easier to manufacture a new board - still quite a process.

If you have any further ideas I would really appreciate them. Thanks for the help.

Willem.

AVRdudeMessage.txt (3.62 KB)

If you have any further ideas I would really appreciate them.

Maybe play with this in the ArduinoISP sketch Line 45.

// Configure SPI clock (in Hz).
// E.g. for an ATtiny @ 128 kHz: the datasheet states that both the high and low
// SPI clock pulse must be > 2 CPU cycles, so take 3 cycles i.e. divide target
// f_cpu by 6:
//     #define SPI_CLOCK            (128000/6)
//
// A clock slow enough for an ATtiny85 @ 1 MHz, is a reasonable default:

#define SPI_CLOCK 		(1000000/6)

Also try burning bootloader/set fuses again with the timing slowed down.

Bingo.

You guys are absolutely amazing.

I followed @kprims’ advice and changed the ArduinoISP sketch SPI_CLOCK define to 128000/6. Uploaded the sketch to both the ATtiny84 and 85 without any error (slowly though). I then switched back to the normal ArduinoISP setting and could upload and burn the bootloader to both.

Everything seems to be back to normal and I do not have to build another ATtiny84 - yet. I can now proceed with what I started with.

Gentleman, I am very grateful to all of you for the splendid advice - this forum rocks. Again thanks.

Willem.