Hello,
I’m trying to burn a bootloader to an ATmega8A AU 1451 that’s soldered to the PCB of an ESC I want to reprogram. I’ve uploaded the ArduinoISP Sketch to an Arduino Nano (old Bootloader), installed MiniCore and followed the instructions given there.
Here’s my wiring:
The legs for the xtal of the ATmega8 are not soldered to the board, so it’s using the internal crystal.
When clicking on “burn Bootloader” I get the following error:
Arduino: 1.8.19 (Windows Store 1.8.57.0) (Windows 10), Board: "ATmega8, No bootloader, EEPROM retained, Default, BOD 2.7V, LTO enabled, Internal 8 MHz"
avrdude error: Yikes! Invalid device signature.
avrdude error: expected signature for ATmega8 is 1E 93 07
Double check connections and try again, or use -F to override this check.
Error while burning bootloader.
Here's the verbose error:
Arduino: 1.8.19 (Windows Store 1.8.57.0) (Windows 10), Board: "ATmega8, No bootloader, EEPROM retained, Default, BOD 2.7V, LTO enabled, Internal 8 MHz"
B:\Anton\Documents\ArduinoData\packages\MiniCore\tools\avrdude\7.2-arduino.1/bin/avrdude -CB:\Anton\Documents\ArduinoData\packages\MiniCore\hardware\avr\3.0.1/avrdude.conf -v -patmega8 -cstk500v1 -PCOM3 -b19200 -e -Ulock:w:0xff:m -Uefuse:w:{bootloader.extended_fuses}:m -Uhfuse:w:0b11010111:m -Ulfuse:w:0b10100100:m
avrdude: Version 7.2-arduino.1
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is B:\...\ArduinoData\packages\MiniCore\hardware\avr\3.0.1\avrdude.conf
Using Port : COM3
Using Programmer : stk500v1
Overriding Baud Rate : 19200
avrdude stk500_getsync() warning: attempt 1 of 10: not in sync: resp=0x15
avrdude stk500_getsync() warning: attempt 2 of 10: not in sync: resp=0x15
AVR Part : ATmega8
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : possible i/o
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 4 20 128 0 no 512 4 0 9000 9000 0xff 0xff
flash 33 10 64 0 yes 8192 64 128 4500 4500 0xff 0x00
lfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
calibration 0 0 0 0 no 4 1 0 0 0 0x00 0x00
Programmer Type : STK500
Description : Atmel STK500 version 1.x firmware
avrdude stk500_getparm() error: protocol expects OK byte 0x10 but got 0x14
avrdude stk500_getparm() error: protocol expects sync byte 0x14 but got 0x02
avrdude stk500_getparm() error: protocol expects sync byte 0x14 but got 0x10
Hardware Version: 49863976
Firmware Version: 0.2
Topcard : STK502
Vtarget : 1.8 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us
avrdude stk500_initialize() error: protocol expects OK byte 0x10 but got 0x01
avrdude main() error: initialization failed, rc=-1
- double check the connections and try again
- use -B to set lower the bit clock frequency, e.g. -B 125kHz
- use -F to override this check
avrdude stk500_disable() error: protocol expects sync byte 0x14 but got 0x10
avrdude done. Thank you.
Error while burning bootloader.
Any help would be greatly appreciated, I don’t know how to troubleshoot this.
Interesting. As you can see, there is a communication out of sync. Hard to say why. Still, it can be problem with ISP wire or some other HW problem. Check it again. What about upper wires from red board, are they connected somewhere? Do you have red board schematics?
Try to run the command from CMD line with -vvvv for very detailed log but without any write and erase, it means without -e and all behind.
The upper wires form the breadboard are not connected to anything. I did try connecting them to power so the ATmega8 gets its own 5V form the regulator on the red board, but that didn’t change anything.
It’s one of the generic yellow 30A ESCs by no particular brand. They usually show up when you search for ESC and sort by price
I have also successfully programmed an ESC with BLheli, but did all of that using the BLheli configurator.
I have measured 10k from the ATmega8 reset pin to 5 V and 11k to GND. I tried pulling the pin up or down using a 1k resistor, but to no avail.
This is the command from log you have posted. I just modified -v to -vvvv and cut the -e and the rest.
Try to check the reset pulse, e.g. with the DMM. It means DC voltage between RESET pin and GND on the target MCU should be 5V and you should see a drop to 0V as the uploading process starts.
Have you actually connected anything to the reset pin of the Atmega8? It is the fourth pin from the left on the top row in your picture. I don't see any wires going to it.
I have the exact HW30A esc, that you referred to the schematic. On mine the reset is connected to nothing. With my TQFP programmer foot I could extract the firmware and eeprom contents without a problem.
Ok, yours has the programming pads exposed. That's convenient.
Yesterday I was able to program the version as seen in Github with the SimonK/BLheli (tgy.hex) firmware and that worked just fine as long as my servopulses were within the standard range of 1000-2000 us. Then I programmed it back to the original firmware and eeprom content, that I had extracted first.
I did notice however that none of my USBASP programmers could not talk to it, but my USBTinyISP could. I did not look in the schematic if maybe some components were connected to the Miso, Mosi or Sck pins of the AT8, that interfered with the USBASP.
I don't have your version, or maybe I have, but I just opened one of the many 30A el-cheapo ESC's that I have.
There is no response from the target MCU. I would say bad wires or MCU does not start. ISP sketch is working as expected. If the MCU is not dead then definitely must be something with these 6 wires.
It does not seem right to me. It can be a problem. RESET pin is 4th leg from left in upper row on your picture. There is obviously a trace to a resistor, the right one above MCU. I can't read the value. Check it visually if the wire is connected correctly. Also check it with the DMM as the upload starts the DC voltage have to drop visibly from 5V to 0V for a moment.
I can tell that the MCU is not dead because it does its job in the circuit (turns the motor) and makes it beep as soon as power is connected.
I have confirmed with my multimeter that the reset pin of the ATmega8 is pulled low when trying to burn the bootloader. The pin is connected to a 10k pull up resistor (the one you saw in my picture). The trace to the reset pad I soldered the green wire to comes up from underneath the chip, so I think that’s why we can’t see the connection to the chips reset pin.
Could you tell form the response to the command I send if the reset pin or ISP programming have been disabled?
Could I connect a transistor to pin 10 of the Arduino so that instead of resetting the ATmega8 it cuts its power and resets that way (in case the reset pin is disabled)?
Yes, definitely. Worth the shot. Post the output log.
Maybe ATmega will need longer time to start. I am not sure now if it is significant for this case, but try it first. It is good idea anyway. Kudos!
However, it can be SPI disabled. In this case only paralel programming would help.
You can test if reset is disabled by connecting reset to ground and see if your ESC still works. The fact that they added a 10K resistor between RST and VCC would suggest reset is not disabled.
Unless the HW folks designed for a non-locked MCU and they decided to lock it afterwards.
Just thought of this.
You have programming pads on the PCB, which means it is manufactured with a unprogrammed AT8 and then programmed afterwards via the programming pads (using pogo pins).
For programming afterwards, even if it is only once, you need a working RST pin. After/during programming they could set the lockbits to disable SPIEN and/or RST.
I finally got around to trying this, but I don’t have good news:
The reset pin of the ATmega8 appears to be disabled. I connected it to ground, but the ESC keeps on happily beeping as if nothing happened.
The cut-power-using-transistors-as-a-reset-idea also didn’t work. Disconnecting the GND of the ATmega8 using an NPN transistor didn’t do much. Using a circuit with a PNP transistor to disconnect 5 V did turn off the ATmega8 using the pin 10 reset pin, but I still couldn’t burn the bootloader.
So SPI is probably also disabled, and I’m not really willing to get into high voltage parallel programming, so I’m kind of out of options now. Seems like this MCU will keep its code.
