It’s fairly unlikely that 2 units were both faulty, but I can offer you replacements or a refund - let me know which you’d prefer!
@PaulZC I am not good in English therefore, I am expressing my problem with the help. I’ll take care more. I didn’t know that it would cause the problem
Thanks Russell. I already received a refund for the 2 boards. I’m good on compensation at this point. I have another fabricator who’s going to check out my work this week, hopefully.
Small update on my end. I had to upload to a new Arduino, made by a fabricator for one of our newly installed interactives, but got the same error. I even tried my personal laptop, to eliminate any blockage from our company’s anti-virus, but I got the same result. We had another exhibits contractor try with his Mac, and the upload happened flawlessly.
My only thought now is that it’s Windows, and not just Windows 11 since that didn’t work either. However, I’ve no idea where to look within the OS, because as far as I know on setup, the Arduino IDE should’ve accounted for communication on the ports. It did when installing it on my personal laptop, in any case.
You can try wiping the drivers and starting from scratch How to Install FTDI Drivers - SparkFun Learn
Reinstalling FTDI drivers was something I tried twice already, it didn’t seem to help. Another exhibits company suggested whether it needs some particular linux function installed, so I’m gonna try a virtual machine with Ubuntu next.
Update is that I used VirtualBox to create an Ubuntu virtual machine, and even that is still giving me the same error message regarding the programmer. At my wit’s end here, truly.
I’m out of ideas as well…reading through the thread it looks like we did a refund earlier
Do you need to make more returns?
I had some friends suggest looking at the baud rate. The LCD serial kit defaults to 9600 bps, and that’s what it shows as in Device Manager. But the output window shows:
Avrdude version 8.0-arduino.1
Copyright see …
System wide configuration file is C:\Users\[user]\AppData\Local\Arduino15\packages\arduino\tools\avrdude\8.0.0-arduino1\etc\avrdude.conf
Using port : COM9
Using programmer : arduino
Setting baud rate : 57600
Error: programmer is not responding
Warning: attempt 1 of 10: not in sync: resp=0x00
But I did a search in the upload code and didn’t see anything setting baud rate. The serial monitor window lists 9600, and I added Serial.begin(9600); to the setup part of the code. The configuration file doesn’t list anything about making the baud rate 57600, but apparently that’s showing up in the output. Would that setting be somewhere else in Arduino IDE?
The 57600 baud rate is set by the Arduino IDE through the boards.txt file. When you select the Arduino Duemilanove or Diecimila board with the ATmega328P processor, the relevant section is
Notice the upload.speed=57600. In the bootloader section (what would be used if you selected Burn Bootloader), the file is atmega/ATmegaBOOT_168_atmega328.hex. Looking at the Github for the Arduino core, you can find the source here - ArduinoCore-avr/bootloaders/atmega at master · arduino/ArduinoCore-avr · GitHub - though the bootloader baud rate is defined in the makefile
So if the ATmegaBOOT_168_atmega328.hex bootloader is actually what is installed on the microcontroller, the baud rate of 57600 should be correct. If I recall correctly, you were able to successfully perform a loopback test, so there might be a way you can check if the bootloader is responding. Using a terminal program, e.g. PuTTY, connect using COM9 and 57600 baud. Then while repeatedly pressing the 1 key, reset the board (may need two people as I recall the board doesn’t have a convenient reset). If the bootloader is communicating, it will respond with ‘AVR ISP’ every time you press 1. You’ll need to be kinda fast as the bootloader times out pretty quick.
Hopefully that helps - best of luck!
Mike
Quick update to my above post - if you try the test I mention to get the bootloader to return ‘AVR ISP’, you need to put a space between each 1. Sorry, I was reviewing the bootloader code to come up with other ideas and realized I had forgotten about needing a space between commands.
Bootloader code is beyond my ken, atm, so I’m looking at other options. It doesn’t make sense that 3 brand new boards all did this. Makes me think the software settings are the issue. I was trying to find if anyone’s had the programmer not responding issue with this specific board.
I understand, and I wasn’t suggesting you needed to modify the bootloader code in any way, just pointing out where the 57600 baud rate comes from and why I think it is correct in this case. My apologies for any confusion there.
In the spirit of throwing out ideas, I thought of something the other day. I have no reason to suspect this is your issue, but thought I’d post it here for anyone that may be reading this and considering picking up one of these kits for themselves.
The kit comes with four ceramic capacitors (two 22pF and two 0.1uF) that, aside from their markings, look identical. The kit I ordered a few months back didn’t have any instructions, just a bag of parts, so if someone relied on the pictures on the product webpage for assembly without paying attention to the PCB, one of the 22pF could be inadvertently used as the coupling cap between DTR and RESET. This would have the effect of shortening the reset pulse to under the 2.5us specified in the data sheet - if avrdude can’t reset the 328, the programmer (i.e. the bootloader) won’t run and therefore not respond. But there’s a likely worse effect as well. If one of the 22pF were used for the reset capacitor, that would mean that one of the 0.1uF would have to be used for the oscillator load capacitor. This would at best shift the oscillator frequency (and possibly prevent proper communication) or at worst stall the oscillator altogether (and certainly prevent proper communication).
Anyway, just wanted to throw that out there since I don’t think it has been mentioned yet. As I said I have no reason to suspect this to be your issue, just documenting it for anyone who might benefit from it. And again, sorry for any bootloader confusion my previous posts may have caused.
Take care!
Mike
…I soldered the chip in backwards. I didn’t see that the chip has a divot on one side, that has to match the divot drawn out on the board. Turns out I had soldered it on the opposite way every time. Way too frustrated at this point in my life.
For anyone still paying attention, is it possible to desolder a chip safely? Or are these boards essentially toast? I’ve taken them apart with the desoldering wick from Grainger, but never a chip. Is there a high possibility of overheating it while doing so?
You’re fine to give it a go…I generally find PTH components easier to desolder than SMD ones. The chances of overheating are low but not 0. Just keep cycling the wick each touch and don’t work on one area/leg too long, keep the heat moving after getting things hot enough for the solder to begin moving