First, I'm not sure the burning bootloader is my problem solution, but I have no other idea. The problem is related to the device signature and occurred after I accidentally flashed software that exceeds RAM (170%) after that any attempt to flash anything else is not possible since the following issue:
Connecting to programmer: .
Found programmer: Id = "CATERIN"; type = S
Software Version = 1.0; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.
Programmer supports the following devices:
Device code: 0x44
avrdude: ser_drain(): read error: The I/O operation has been aborted because of either a thread exit or an application request.
avrdude: AVR device initialized and ready to accept instructions
Reading | avrdude: ser_send(): write error: sorry no info avail
avrdude: ser_recv(): read error: The device does not recognize the command.
avrdude: butterfly_recv(): programmer is not responding
################################################## | 100% 0.00s
avrdude: Device signature = 0xffffff (probably .reduced_core_tiny) (retrying)
Reading | avrdude: ser_send(): write error: sorry no info avail
avrdude: ser_recv(): read error: The device does not recognize the command.
avrdude: butterfly_recv(): programmer is not responding
################################################## | 100% 0.00s
avrdude: Device signature = 0xffffff (probably .reduced_core_tiny) (retrying)
Reading | avrdude: ser_send(): write error: sorry no info avail
avrdude: ser_recv(): read error: The device does not recognize the command.
avrdude: butterfly_recv(): programmer is not responding
################################################## | 100% 0.00s
avrdude: Device signature = 0xffffff (probably .reduced_core_tiny)
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.
avrdude: ser_send(): write error: sorry no info avail
avrdude: ser_recv(): read error: The device does not recognize the command.
avrdude: butterfly_recv(): programmer is not responding
avrdude: error: programmer did not respond to command: leave prog mode
avrdude: ser_send(): write error: sorry no info avail
avrdude: ser_recv(): read error: The device does not recognize the command.
avrdude: butterfly_recv(): programmer is not responding
avrdude: error: programmer did not respond to command: exit bootloader
avrdude done. Thank you.
*** [upload] Error 1
I assume that bootloader flash will solve the problem (If you see another solution please let me know). I use Leonardo board as a programmer, but it is not the original Arduino. The target (the board I develop the software) is an original Arduino Leonardo. I connected the ICSP in the following way (left: programmer, right: target):
pin 10 --> Reset
pin 11 --> MOSI
pin 12 --> MISO
pin 13 --> SCK
5V --> 5V
GND --> GND
Update:
I was able to flash a simple "blink" project from examples using Arduino IDE. Below I put the console output, it is different than usual. Unfortunately, it doesn't solve the problem. After flashing my program the behavior is strange. The LCD display changes its brightness rapidly (below 1Hz pulsation).
If you are using one Leonardo to burn tghe bootloader on another Leonardo, the above is wrong. Pins 11/12/13 on a Leonardo are not the SPI interface; you need the pins on the 6 pin header (same as on the target).
What is "usual"?
If you can flash blink, your bootloader is OK. So I guess you're problem is solved
Thank you for quick response. I will try your advice.
So how to interpret this strange behaviour? I'm certain something is wrong since I flashed the board with te same soft as before and the result is different. I will double check I connected everything as before, but how can I check the board is in the same state as it was after buy?
I'm actually surprised that the IDE allowed you to do that. Was the 170% flash or RAM (dynamic memory)
The one that has the 170% memory usage? How did you flash that code? Using the IDE? Using avrdude directly? In both cases, over USB or over ICSP?
The flash memory is divided in 2 parts
Bootloader.
An upload over ICSP using a programmer will replace the bootloader with whatever is in the hex file.
If you just did the upload over USB, it's highly unlikely that you will manage to corrupt the bootloader if the RAM usage was 170%.
If your flash memory was 170%, it might be possible. I don't know.
Your sketch (see below).
When you compile a sketch for a board with native USB (e.g. the Leonardo), it contains
The sketch that you wrote.
Additional code to handle USB.
Mistakes in your sketch can result in variables used by the code that handles the USB becoming corrupt. The result can be that your board is no longer detected or your board does not react on the software reset that the IDE issues (opening and closing the port with a baudrate of 1200 baud); in both cases you will have a bit of a hard time to upload a sketch.
Below indicates that the bootloader is OK. Now the question is if that was the "faulty" Leonardo or the "good" one? After the software reset by the IDE, it starts polling the serial ports till it finds one with the boot loader. In the 3rd line you can see that it found a port that it can use.
You will not see that line when the Leonardo does not react on the software reset; the lines will be repeated. In that case you can manually reset the the board when you see the lines PORTS {COM3, } / {COM3, } => {}. My Leonardo reacts on a single tap on the reset button to get it in bootloader mode; I've seen people indicating that they require a double tap.
If you "faulty" board is not detected at all (check Windows device manager), there are two things you can check.
Does the onboard LED breath in and out for approximately 8 seconds. In that case your bootloader is more than likely OK.
Does Windows device manager show the Leonardo bootloader? If the LED behaves as expected and device manager does not see it, the first thing to check is that you are not using a charge-only cable or damaged cable and that your cable is properly inserted (use e.g. the cable that works with the "good" Leonardo).
I use Platformio IDE (plugin for vs code). Flashed through a USB port.
For me it look all right
When I push the reset button on the board it changes for a while:
Yes, it does pulsate about 8 seconds.
I'm not sure if the above screen (showing COM5 port in the Device Manager) is sufficient verification, let me know if I need to check it in a different way.
So we can assume that bootloader is not corrupted? If so, what is the root cause of the behavior I mentioned earlier? I run out of ideas. Today, I have tried to flash a simple example code for an I2C Display I used a sketch grabbed from the web:
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
LiquidCrystal_I2C lcd(0x27, 16, 2);
//LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3);
// the setup function runs once when you press reset or power the board
void setup() {
lcd.init();
lcd.backlight();
}
// the loop function runs over and over again forever
void loop() {
lcd.setCursor(3, 0); // set the cursor to column 3, line 0
lcd.print("SunFounder"); // Print a message to the LCD
lcd.setCursor(2, 1); // set the cursor to column 2, line 1
lcd.print("Hello, World!"); // Print a message to the LCD.
}
Flashed successfully, but the display is dimmed and shows nothing, despite the fact that earlier I had used the same sketch to learn how to plug such LCD (yes, I'm a newbie), and then It worked flawlessly.
I flashed the scanner. The serial monitor message says that no I2C devices have been found. Eventually, I checked the wiring a third time, and it turned out it was the problem. I probably did not notice that before since I used the same color of wire for GND and pin 7. FYI -- yes, I feel terrible about that .
Anyway, I want to thank you beautifully for your help and suggestions at least I did not waste my time trying to burn the bootloader
.