Hi,
I'm trying to use Arduino IDE 1.8 to reprogram a motor for a garage door.
This motor has a board with a AT90S2313 AVR, and apparently, the flash memory is erased.
But when exporting the program, the signature of the AT90S2313 doesn't match the ATtiny2313.
Error report says : "Double check chip, or use -F to override this check."
Hi @papi_78. The first thing I should say is that, in 99% of the cases, using the -F flag will not solve upload failure.
I feel the need to point this out because the question of how to use the -F flag comes up here on the forum regularly and so others who want to do that in other contexts will likely find this thread during their research. Most of the time when people see this people it is because communication was not established with the target chip at all (either due to bad wiring or permanent physical damage to the chip) and so a garbage signature (e.g., 0x000000) was read. Alternatively, it might be that the user accidentally selected an inappropriate board in Arduino IDE and the signature check is working as intended. In either of these cases, the suggestion to use the -F flag is a "red herring" which will only distract the user from more productive efforts to fix the problem that caused the signature verification failure.
It sounds like yours might possibly be one of the rare cases where there is some logic behind overriding the signature check. Since we don't have any confidence this will help, the best way to proceed is to run the avrdude command from the command line terminal rather than spending time adjusting the ATTinyCore platform configuration files to add the -F flag.
The signature check is there for a good reason. Overriding it might result in the target being put into an unrecoverable state, or cause permanent damage. You should only override the check if you know for sure it is safe, or are willing to accept the loss of the target hardware for the sake of the experiment.
If you wish to proceed, try this:
Select File > Preferences... (or Arduino > Settings... for macOS users) from the Arduino IDE menus.
The "Preferences" dialog will open.
Uncheck the box next to "Show verbose output during: ☑ compilation" in the "Preferences" dialog.
Check the box next to "Show verbose output during: ☐ upload".
Click the "OK" button.
The "Preferences" dialog will close.
Attempt an upload, just as you did before.
Wait for the upload to fail.
Examine the contents of the black output panel at the bottom of the Arduino IDE window. There you will see the avrdude command Arduino IDE generated. Select the entire text of that command.
Press the Ctrl+C keyboard shortcut (Command+C for macOS users).
This will copy the selected text to the clipboard.
Many thanks for your reply.
I will made some additionnal investigations to verify if the AT90S2313 of the board is really alive or not.
My initial investigations showed that the CPU still seemed functional, but I don't have much way of knowing if this is the case or not. The other problem is to know if the program lock has been set or not.
And it sounds really strange to me that the flash was erased, because this motor was unpluged during months.
Anyway, destroyed for destroyed, the force procedure will be the last try to test if this cpu can be reactivated or not.
My B plan after that will be to remove the CMS cpu chip from the board and to find a way to wire an external arduino to pilot the analog part of the motor driver.
This will not easy because I have no equipment to maintain CMS board.
You could buy a real ATtiny2313 and program it; I'm not sure how compatible they are WRT programming algorithms (Hmm: not very - see below), but they're basically code and pin compatible.
See https://ww1.microchip.com/downloads/en/Appnotes/doc4298.pdf
Changes have been made to the programming interfaces. The changes are valid for both serial programming (ISP) and parallel programming.
• Programming of both flash and EEPROM is now done in pages instead of per byte. The EEPROM can however also be programmed pr byte over the serial interface
If you're having trouble because the Tiny2313 signature doesn't match your chip's - why not just try to flash the chip using the correct signature?
Copy the avrdude command line from the Arduino output, change the signature to AT90 and try again. It will be safer than using the -F force flag
Hi guys,
I'm trying to verify the AT90s health, and I'm getting the signature 0x000102.
avrdude: set SCK frequency to 187500 Hz
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
Une erreur est survenue lors du transfert du croquis
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x000102
avrdude: Expected signature for ATtiny2313a is 1E 91 0A
Double check chip, or use -F to override this check.
It seems not to be a wiring issue (reset pin is high) and I double check it.
But did I have a problem with the USBasp firmware to work in slow clock ? I read on the internet that it could be the reason why the return code is 0x000102.
With AVRDUDESS I have exactly the same issue and the same error report.
Additionnal information : the cristal on the board seems to be 3.58MHz.
On XTAL2 I can see the XTAL waveform.
But when touching XTAL1 with the probe or anything, the board gets crazy : the relays are cliking without any logic, LED is flashing and board hanged after a short while. A reset action clears it.
This reaction on XTAL1 sounds strange for me ...
Does this mean that you got it working with USBasp by slowing the bit clock?
Did you reduce the bit clock in AVRDUDESS? It's in the programmer panel at the top of the dialog. When I programmed a TINY85 I seem to recall that I reduced the bit clock to 187.5KHz in order to program it.
Thanks b707 : it confirms my fears. Usually, manufacturers are locking the cpu after the flash.
In parallel, I solved all my problems with the USBasp and clock error message by flashing the latest "official" firmware in the china clone.
But now it is more & more clear that the CPU is out of usage. I cannot erase it with AVRDUDESS. It returns a "target does not answer".
This is weird because I'm receiving 0x000102 on first connection, and after a target doesn't answer.
I think I will stop to waste time and will remove the AT90S to find a solution to implement a kind of pigg-back on the board with a UNO to get the control of the analog part.
Problem : fuses are not accessible with serial programming mode. Only high voltage parallel mode has acces to it.
So, it sounds strange to find a serial programming plug on the PCB and to find a locked processor, because the manufacturer cannot upload the firmware and lock the CPU after with it.
The only solution is to use pre-progammed chips, but in that case, why implementing a serial programmation plug on the PCB ?
Anyway, I have no reflow material to remove the CPU and to erase it with a parallel programmation mode.
It was a warning, not an error. The warning is actually misleading.
The firmware that is shipped on the Chinese USBasp programmers (e.g., the "Baite" branded USBasp) is actually technically superior to the official firmware provided by the creator of the USBasp in that the Chinese firmware does automatic SCK frequency adjustment while the official firmware does not.
So this warning message tricks you into installing a technically inferior firmware, after which you will have to manually adjust SCK frequency either via the jumper on the USBasp (if your USBasp even has one, since it is superfluous when the Chinese firmware is installed) or via the AVRDUDE -B (bitclock) flag.
The Chinese firmware is proprietary and the firmware binary is not available (the manufacturers of the Chinese USBasp lock the chip so it is not possible for us to read the Chinese firmware binary from these USBasps), so there is no way to go back to the Chinese firmware after you replace it. Fortunately this isn't a problem because community members have created an alternative USBasp firmware that is open source and superior even to the Chinese firmware. I use this firmware on all my USBasp for years and it works perfectly:
@ptillisch you should recommend the better open source USBasp firmware instead of PeterVH's outdated fork.
NerdRalph's USBasp firmware is much newer, supports the USBISP hardware and have automatic SCK frequency adjustment. An alternative is this fork of NerdRalph's firmware which is WCID compliant, which means that no driver should be necessary on Windows.
But if you think the warning message is misleading, please create an issue over at the Avrdude Github repo. A new version of Avrdude is right around the corner and this can easily be fixed if you have a suggestion to a more appropriate warning message.
The signature check is there for a good reason. Overriding it might result in the target being put into an unrecoverable state, or cause permanent damage. You should only override the check if you know for sure it is safe, or are willing to accept the loss of the target hardware for the sake of the experiment.
