Not anymore. you can upload the bootloader without problems.
In my earlier tests the flash chip did get upset during ISP-ing and it recovered fine after power cycling off and on again. But I do recommend to temporary connect a 10K pullup resistor to the SDA pad to prevent the flash chip from getting upset by the ISP data. If bad luck would strike a one time only bit in a certain register may get set with unwanted consequences)
(There’s no pullup on the mod chip cause the attiny normally takes care of that when it’s programmed with firmware)
if the Modchip has been programmed already but contains faulty firmware the reset pad of the mod chip must be disconnected. otherwise the mod chip may try to flash the faulty bootloader right after ISPing with the UNO has completed.
The mod chip has a press reset for 2 seconds update feature (If that part was successfully flashed)
when ISP-ing the bootloader reset will be held low during the process. The Cathy bootloader flashes fast but if the ISP process takes longer than 2 seconds. the modchip 2 seconds update feature may kick in.
Thinking more about it may be better to ISP the modchip firmware (need to think about it more tomorrow, need sleep).
I think I know why I’m getting the error code about the programmer not responding. I think it’s because I’m using a clone Uno r3 and I read on some other Arduino forums that some clone R3s don’t have the bootloader installed on the Atmel chip and you need a real R3 to flash the bootloader. So I’m probably gonna buy a USBasp
Would this one work? if not which one would/
@Bateske since you’ve also wired up VCC to 5V it’s also important to say:
Keep Arduboy power switch in the Off position !!!
If the modchip was programmed successfully there is no reason to upload the bootloader using an ISP. it would be much more convenient to use the FX activator to update the bootloader.
However in case the modchip was programmed unsuccesfully (verification failed) and one flashed the Arduboy’s bootloader anyway (no longer possible now) then things get a bit more complicated. If I have understood it correctly, this is the case with @TheBossinator
We have an attiny with unexpected behaviour because of unsuccessful programming trying to update Arduboy’s bootloader and using the SPI bus.
We have Arduboy powering up with unexpected behaviour and possibly using the SPI bus for OLED display and / or flash chip if the Cathy3K bootloader was (partly) flashed.
We have the FX flash chip on the SPI bus.
We have the ISP programmer (Arduino Uno) using the SPI bus.
When connecting the ISP programmer to Arduboy and trying to program Arduboy, Arduboy will be hold in reset and will not send data to OLED and flash so that’s not a problem. But the attiny is still there trying to program Arduboy too and the flashchip is possibly listening in for receiving commands also (because of a floating chip select) so the ISP programmer won’t be able function properly.
We need to make sure that the attiny doesn’t try to program Arduboy and that the flash chip doesn’t listen in.
This can be done by putting both the attiny and Arduboy in reset, put them in program mode and issue a chip erase. (Both the Attiny and Arduboy will be erased) Once erased they won’t interfere with each other and the bootloader can be uploaded.
To make sure the flash chip doesn’t listen in. The flash chip select can be connected to one of the Unos GPIO pins cofigured as INPUT_PULLUP so it’s pulled high and the flash chip is disabled.
I’ll have a look at the Arduino as ISP sketch to add this.
here's how you should connect the Uno to Arduboy with mod chip (2 extra wires for SCL and SDA):
The moment you connect your Uno to USB or connect it to a power supply.
You keep Arduboy turned off for as long as your Uno is connected to USB or is connected to a power supply
The timing doesn’t have to be precise. When you have connected your Uno to USB or a power supply wait a few seconds or say out loud ‘Arduboy is awesome’ and press reset. wait another second and
burn the bootloader.