Failing to program via UART (and maybe also to transfer the bootloader)

[ezcGman]

Hey there,

it's me again... I finished building the board and everything looks fine, but I struggle a bit to get it flashed via UART. And now I'm not even sure if I did everything right for the fuses and bootlader.

I'm using this for reference: https://github.com/jsanpe/c2c-64/wiki/Programming-the-C2C-64

First, I don't have an Arduino DUE, but I googled a bit and it seems that you can also use an ESP8266 or ESP32 (which I work with A LOT) to achieve the same. So I successfully flashed the ArduinoISP sketch (it just compiles naturally, I just needed to change some pins) to a random ESP8266 (Actually a NodeMCU) I had using ArduinoIDE. Then (because you're using/referencing a platformio.ini file) I opened my VS.Code which I also use a lot to flash ESPs using platformio, so I'm pretty familiar with that.

That's how it's wired (c2c is powered using my bench PSU, set to 5v 2A):

I opened the "fuses_1R3" task, changed the upload_port to "COM4" (as I'm on Windows) and I could successfully run the "Set Fuses" and "Burn Bootloader" platform tasks (which is I guess what you're referencing in your guide). Both worked successfully, see the output at the end of this post.

I then took my FTDI dongle (which uses a FT232BL chip (https://www.aliexpress.com/item/32967622307.html)) and tried to flash the software via UART, but I always get the same error: avrdude warning: attempt x of 10: not in sync: resp=0x00

Yes, sadly my dongle doesn't have an easy way to wire RST, but it has the pin exposed, so I'm touching it manually. But no matter how often I try, I always get the same error. I also tried simply bridging RST of the c2c to GND manually but it never works. No matter how often I try and when... It never works. I even tried reversing TX/RX, just in case: Still nothing.

Then I thought, after reading your guide 100th time: "Did I actually flash the bootloader?", as I just used the platform task "Burn bootlader". I then got my ESP wired again, validated I can still execute "Set Fuses" and then just hit "Upload" (still under the "fuses_1R3" task), but it first failed with not finding the "SSD1306Ascii" library, because it's missing in the "fuses_1R3" task. Added it and hit "Upload" again. It compiled but then getting the same error as I got via UART: avrdude warning: attempt x of 10: not in sync: resp=0x00

I'm a bit lost what I'm doing wrong... Do you maybe have an idea what's happening? I don't think my board is broken, right? Otherwise I wouldn't be able to execute the platform tasks "Set Fuses" and "Burn Bootloader" successfully, right? :/

Which USB FTDI dongle are you using? I might just get a different one; not really trusting this one here with the weird RST pin...

Thanks so much again and greetings,

Andy!

P.S.: Some outputs: Set Fuses:

Executing task: C:\Users\andy\.platformio\penv\Scripts\platformio.exe run --target fuses --environment fuses_1R3 

Warning! Ignore unknown configuration option `build_unflags` in section [platformio]
Warning! Ignore unknown configuration option `build_flags` in section [platformio]
Warning! Ignore unknown configuration option `monitor_port` in section [platformio]
Warning! Ignore unknown configuration option `monitor_speed` in section [platformio]
Processing fuses_1R3 (platform: atmelavr; framework: arduino; board: ATmega328PB)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelavr/ATmega328PB.html
PLATFORM: Atmel AVR (5.0.0) > ATmega328PB
HARDWARE: ATMEGA328PB 8MHz, 2KB RAM, 32KB Flash
PACKAGES:
 - framework-arduino-avr-minicore @ 3.0.0
 - tool-avrdude @ 1.70200.0 (7.2.0)
 - toolchain-atmelavr @ 1.70300.191015 (7.3.0)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 10 compatible libraries
Scanning dependencies...
Dependency Graph
|-- Wire @ 1.1
|-- mcurses @ 0.1
|-- SSD1306Ascii @ 1.3.5
Building in release mode

TARGET CONFIGURATION:
---------------------
Target = atmega328pb
Clock speed = 8000000L
Oscillator = internal
BOD level = 2.7v
Save EEPROM = yes
Bootloader type = urboot
UART port = uart0
Clock output = no
CFD enable = no
---------------------

Selected fuses: [lfuse = 0xe2, hfuse = 0xd7, efuse = 0xf5]
Setting fuses
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9516 (probably m328pb)
avrdude: erasing chip

avrdude: processing -U lock:w:0xff:m
avrdude: reading input file 0xff for lock
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte lock ...
avrdude: 1 byte of lock written
avrdude: verifying lock memory against 0xff
avrdude: 1 byte of lock verified

avrdude: processing -U hfuse:w:0xd7:m
avrdude: reading input file 0xd7 for hfuse
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte hfuse ...
avrdude: 1 byte of hfuse written
avrdude: verifying hfuse memory against 0xd7
avrdude: 1 byte of hfuse verified

avrdude: processing -U lfuse:w:0xe2:m
avrdude: reading input file 0xe2 for lfuse
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte lfuse ...
avrdude: 1 byte of lfuse written
avrdude: verifying lfuse memory against 0xe2
avrdude: 1 byte of lfuse verified

avrdude: processing -U efuse:w:0xf5:m
avrdude: reading input file 0xf5 for efuse
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte efuse ...
avrdude: 1 byte of efuse written
avrdude: verifying efuse memory against 0xf5
avrdude: 1 byte of efuse verified

avrdude done.  Thank you.

================================================================================================================================== [SUCCESS] Took 3.49 seconds ==================================================================================================================================

Environment    Status    Duration
-------------  --------  ------------
fuses_1R3      SUCCESS   00:00:03.486
================================================================================================================================== 1 succeeded in 00:00:03.486 ================================================================================================================================== 

Burn Bootloader:

Executing task: C:\Users\andy\.platformio\penv\Scripts\platformio.exe run --target bootloader --environment fuses_1R3 

Warning! Ignore unknown configuration option `build_unflags` in section [platformio]
Warning! Ignore unknown configuration option `build_flags` in section [platformio]
Warning! Ignore unknown configuration option `monitor_port` in section [platformio]
Warning! Ignore unknown configuration option `monitor_speed` in section [platformio]
Processing fuses_1R3 (platform: atmelavr; framework: arduino; board: ATmega328PB)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelavr/ATmega328PB.html
PLATFORM: Atmel AVR (5.0.0) > ATmega328PB
HARDWARE: ATMEGA328PB 8MHz, 2KB RAM, 32KB Flash
PACKAGES: 
 - framework-arduino-avr-minicore @ 3.0.0 
 - tool-avrdude @ 1.70200.0 (7.2.0) 
 - toolchain-atmelavr @ 1.70300.191015 (7.3.0)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 10 compatible libraries
Scanning dependencies...
Dependency Graph
|-- Wire @ 1.1
|-- mcurses @ 0.1
|-- SSD1306Ascii @ 1.3.5
Building in release mode
Using bootloader image:
C:\Users\andy\.platformio\packages\framework-arduino-avr-minicore\bootloaders\urboot\atmega328pb\watchdog_1_s\autobaud\uart0_rxd0_txd1\led+b5\urboot_atmega328pb_pr_ee_ce.hex

TARGET CONFIGURATION:
---------------------
Target = atmega328pb
Clock speed = 8000000L
Oscillator = internal
BOD level = 2.7v
Save EEPROM = yes
Bootloader type = urboot
UART port = uart0
Clock output = no
CFD enable = no
---------------------

Selected fuses: [lfuse = 0xe2, hfuse = 0xd7, efuse = 0xf5]
Setting fuses
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9516 (probably m328pb)
avrdude: erasing chip

avrdude: processing -U lock:w:0xff:m
avrdude: reading input file 0xff for lock
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte lock ...
avrdude: 1 byte of lock written
avrdude: verifying lock memory against 0xff
avrdude: 1 byte of lock verified

avrdude: processing -U hfuse:w:0xd7:m
avrdude: reading input file 0xd7 for hfuse
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte hfuse ...
avrdude: 1 byte of hfuse written
avrdude: verifying hfuse memory against 0xd7
avrdude: 1 byte of hfuse verified

avrdude: processing -U lfuse:w:0xe2:m
avrdude: reading input file 0xe2 for lfuse
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte lfuse ...
avrdude: 1 byte of lfuse written
avrdude: verifying lfuse memory against 0xe2
avrdude: 1 byte of lfuse verified

avrdude: processing -U efuse:w:0xf5:m
avrdude: reading input file 0xf5 for efuse
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte efuse ...
avrdude: 1 byte of efuse written
avrdude: verifying efuse memory against 0xf5
avrdude: 1 byte of efuse verified

avrdude done.  Thank you.

Uploading bootloader
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9516 (probably m328pb)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip

avrdude: processing -U flash:w:C:\Users\andy\.platformio\packages\framework-arduino-avr-minicore\bootloaders\urboot\atmega328pb\watchdog_1_s\autobaud\uart0_rxd0_txd1\led+b5\urboot_atmega328pb_pr_ee_ce.hex:i
avrdude: reading input file C:\Users\andy\.platformio\packages\framework-arduino-avr-minicore\bootloaders\urboot\atmega328pb\watchdog_1_s\autobaud\uart0_rxd0_txd1\led+b5\urboot_atmega328pb_pr_ee_ce.hex for flash
         with 368 bytes in 2 sections within [0x7e80, 0x7fff]
         using 3 pages and 16 pad bytes
avrdude: writing 368 bytes flash ...
Writing | ################################################## | 100% 0.08s
avrdude: 368 bytes of flash written
avrdude: verifying flash memory against C:\Users\andy\.platformio\packages\framework-arduino-avr-minicore\bootloaders\urboot\atmega328pb\watchdog_1_s\autobaud\uart0_rxd0_txd1\led+b5\urboot_atmega328pb_pr_ee_ce.hex
Reading | ################################################## | 100% 0.00s
avrdude: 368 bytes of flash verified

avrdude: processing -U lock:w:0xFF:m
avrdude: reading input file 0xFF for lock
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte lock ...
avrdude: 1 byte of lock written
avrdude: verifying lock memory against 0xFF
avrdude: 1 byte of lock verified

avrdude done.  Thank you.

================================================================================================================================== [SUCCESS] Took 5.88 seconds ==================================================================================================================================

Environment    Status    Duration
-------------  --------  ------------
fuses_1R3      SUCCESS   00:00:05.881
================================================================================================================================== 1 succeeded in 00:00:05.881 ================================================================================================================================== 

[jsanpe]

Hi,

congrats for having make it this far! Not an easy task, I understand you may be impatient now but it's better to just take your time in the programming phase as well.

Before anything, just in case you haven't, take some measurement of voltages at the output of the 3 regulators to make sure everything is in check. The big one should output 3.3v, the two mini ones on the back side 1.8v. Reduce your PSU amp to 0.5A, 2A will blow your fuse (or more) if there's a short now or in the future.

Burning the bootloader requires just executing the "burn bootloader" task in the fuses_1R3 environment. No need to "upload" or "set fuses". Looking at the output of the command it seems like your ESP flasher did the work just fine. Not sure what running the "upload" task of the fuses environment does to be honest. Perhaps it's uploading the actual firmware instead of the bootloader. This may not work well in practice, as the firmware is not loaded in the right address to be executed at startup most likely. I would repeat the burn bootloader process following this instructions: go to environment fuses_1R3 and run only the "burn bootloader" task.

The output of avrdude suggests that the bootloader is not entering in flashing mode. This could be related to the RTS signal not being timed well, the bootloader is very picky in this regard. The RTS needs to be followed by the stream of data to flash, if not timed correctly the whole process won't work. Hence, it's recommended to have a supported programmer, otherwise flashing is a matter of luck more than anything. I'm using this one.

Other things to check:

• These qfn packages are devilish, sometimes pads are not properly soldered. Try measuring resistance from tx,rx and rst to gnd using the pin header. It should be in the MOhm range.
• The programming circuitry mainly involves C3 and R2. Check these two are correctly soldered.
• I notice you have populated the SW1 switch. This one is a reset. You can use this to manually send the reset pulse instead of the RST pin. Remember, it needs to be timed really well with respect to avrdude. Experiment with it, try pressing sw1 just before or just after running avrdude.

Keep me posted with any further results!

Good luck,

Jose

[ezcGman]

Hey Jose,

thanks for your quick answer, appreciated!! And thanks for the compliment! I did some tricky boards in the past, but that one was certainly one of the most challenging, especially with 0402 components. The rest was tricky, but did that before :) Impossible basically without a microscope, imho! Or unnecessarily complicated!

Yeah, I of course did some extensive poking with the multimeter before connecting / checking for bridges, inspected under microscope and so on an are 99% certain there are none. First thing after powering on was checking the LDOs (both the AMS1117 and the TLV700 on the back) and they spit out what they should. So all good here.

I'm not concerned about blowing the fuse, as it's a PTC / resettable fuse. It will blow, reset and be fine again :) Hold current is 750mA and tripping current is at 1.5A. But still good advice, I lowered the PSU to 1A for now.

• Measured RX & TX against GND: 4.2 / 4.3MOhm. So looks fine
• R2 measured 4.6kOhms (really touching the solder blobs, not the resistor, so making sure it's properly soldered. So also fine...
• Goooood point! I totally forgot about the buttons. That sadly also didn't help, but the error at least a little bit changed from 0x00 to: avrdude stk500_getsync() warning: attempt 10 of 10: not in sync: resp=0xa0...

I now switched to the console, running avrdude directly / outside VS.Code. That's my command and output:

C:\Users\andy\.platformio\packages\tool-avrdude>avrdude -v -p atmega328pb -C C:\Users\andy\.platformio\packages\tool-avrdude\avrdude.conf -c arduino -b 38400 -D -P COM5 -U flash:w:C:\Users\andy\Documents\Sources\c2c-64\.pio\build\Board_1R3\firmware.hex:i

avrdude: Version 7.2-arduino.1
         Copyright the AVRDUDE authors;
         see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

         System wide configuration file is C:\Users\andy\.platformio\packages\tool-avrdude\avrdude.conf

         Using Port                    : COM5
         Using Programmer              : arduino
         Overriding Baud Rate          : 38400
avrdude stk500_getsync() warning: attempt 1 of 10: not in sync: resp=0xa0
avrdude stk500_getsync() warning: attempt 2 of 10: not in sync: resp=0xa0
avrdude stk500_getsync() warning: attempt 3 of 10: not in sync: resp=0xa0
avrdude stk500_getsync() warning: attempt 4 of 10: not in sync: resp=0xa0
avrdude stk500_getsync() warning: attempt 5 of 10: not in sync: resp=0xa0
avrdude stk500_getsync() warning: attempt 6 of 10: not in sync: resp=0xa0
avrdude stk500_getsync() warning: attempt 7 of 10: not in sync: resp=0xa0
avrdude stk500_getsync() warning: attempt 8 of 10: not in sync: resp=0xa0
avrdude stk500_getsync() warning: attempt 9 of 10: not in sync: resp=0xa0
avrdude stk500_getsync() warning: attempt 10 of 10: not in sync: resp=0xa0
avrdude main() error: unable to open programmer arduino on port COM5

avrdude done.  Thank you.

C:\Users\andy\.platformio\packages\tool-avrdude>

I'm wondering: Is the baudrate and also the upload protocol of "arduino" correct? If I see that right, it's basically a re-config of "stk500"?

If you can spot an issue with that, I might just get another FTDI tool. I read a bit and generally it seems the FT232RL (that is used on your flasher) generally gets "better feedback" than the FT232BL I have on mine.

Thanks again for double checking and greetings,

Andy!

[jsanpe]

I reflashed my C2C to capture the exact avrdude command and the logs. You'll find the output below.

To answer your questions, both baudrate and protocol are fine. Keep testing it out, I would recommend resetting the board using sw1 at the same time you press Enter on the command line using the avrdude arguments in your previous post. Try several times, vary your timing slightly, you should get a successful programming at some point. If you don't there may be something else going on. If you have a scope try captuing the reset line to the MCU using C3 pads.

If you are unable to flash using the UART I think it should also be possible to flash the firmware using the ICSP header, but I would need to investigate it a bit more. Never used that option before.

avrdude -v -p atmega328pb -C /home/jsan/.platformio/packages/tool-avrdude/avrdude.conf -c arduino -b 38400 -D -P /dev/ttyUSB0 -U flash:w:.pio/build/Board_1R3/firmware.hex:i

avrdude: Version 7.2-arduino.1
         Copyright the AVRDUDE authors;
         see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

         System wide configuration file is /home/jsan/.platformio/packages/tool-avrdude/avrdude.conf
         User configuration file is /home/jsan/.avrduderc
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyUSB0
         Using Programmer              : arduino
         Overriding Baud Rate          : 38400
         AVR Part                      : ATmega328PB
         Chip Erase delay              : 10500 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                 65    20     4    0 no       1024    4      0  3600  3600 0x00 0x00
           flash                  65    10   128    0 yes     32768  128    256  4500  4500 0x00 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
           efuse                   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          1    1      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino for bootloader using STK500 v1 protocol
         Hardware Version: 3
         Firmware Version: 8.0
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9516 (probably m328pb)

avrdude: processing -U flash:w:.pio/build/Board_1R3/firmware.hex:i
avrdude: reading input file .pio/build/Board_1R3/firmware.hex for flash
         with 18630 bytes in 1 section within [0, 0x48c5]
         using 146 pages and 58 pad bytes
avrdude: writing 18630 bytes flash ...
Writing | ################################################## | 100% 9.40s
avrdude: 18630 bytes of flash written
avrdude: verifying flash memory against .pio/build/Board_1R3/firmware.hex
Reading | ################################################## | 100% 9.31s
avrdude: 18630 bytes of flash verified

avrdude done.  Thank you.

============================================== [SUCCESS] Took 21.41 seconds ==============================================```

[ezcGman]

I just read the AliExpress page of my adapter and I'm not entirely sure if the RTS or CTS pin do something useful anyways: It all ready like it's a signal coming FROM the MCU to the PC... Just for the sake of it, I also tried touching the c2c's RTS pin to the CTS pin on the flasher, but still nothing :/

I sadly don't have a scope. I just order another flasher that properly exposes the RTS pin and see how it goes :(

Thanks for all the help so far!

[jsanpe]

Let's see if you have better luck with the new FTDI dongle. It's a good investment, lot's of potential future uses. I'm still positive is relatively doable to get this done by hand, i.e. manually resetting the mcu with the right timing. In any case, I'll check how to flash directly though the ICSP header, it's probably not too difficult to achieve but not as practical as the UART solution (especially during development).

[ezcGman]

Yeah I tried it MANY times by now and zero luck. I tried a lot of timings, also inbetween the retries... Nothing :/

[jsanpe]

A couple of quick things to try:

• reduce all instances of 38400 in platform .ini with 9600. You will need to rewrite the bootloader using the Burn Bootloader command. This will reduce the UART speed used by the flashing procedure, which depending on the status of the internal oscillator of your 328PB may help.
• In your platform.ini file replace board_hardware.uart = uart0 with board_hardware.uart = no_bootloader. Then use "Upload" in the Fuses_1R3 environment. I think this should upload the firmware directly using your ESP as interface and place it in the right flash location for the MCU to boot it directly. I haven't tested this myself, but it's my conclusion after looking at the documentation here: https://github.com/MCUdude/MiniCore/blob/master/PlatformIO.md

[ezcGman]

First, thanks on digging out the instructions on how to program using the ICSP header and tips on how to get it working via UART from your previous post! I gonna test that later today with my current FTDI flasher, but I also have the exact one coming that you're using. Let's see how it goes.

But another thing I just realized while sitting in a boring call and staring on the PCB:

• The programming circuitry mainly involves C3 and R2. Check these two are correctly soldered.

I discovered that C3 and R2 are not connected to RX/TX/The UART circuit, but instead to the SCK pin. RX and TX go straight to the MCU. Just wanted to double check if that was an oversight in the PCB design, or you just misremembered (no blame intended!! I just saw that by accident :D)

Thx again!

[ezcGman]

The flasher you use just arrived and it sadly also doesn't work :( Same error as above (0xa0). I tried reversing TX/RX, I tried using RTS and CTS: Both don't work :(

I'm clueless what it can be... I also multimetered the pin header pins and the pads on the atmega: they have continuity, so... I have no clue :D

I've just reflowed the RX/TX pins, just to be sure: No effect... They also look just fine... Nothing SPECTACULAR, but... (Ignore the "water blobs": That's just IPA I just sprayed on to clear off some left over flux...

I'll try lowering the baud rate and see if that will help...

[jsanpe]

Hi! Sorry to hear the new flasher is not working :( I was starting to think that the programmer wasn't the issue after the many tests you've been making.

Answering your question about C3 and R2, this is the reset circuit that is triggered by the RTS pin. Once the reset happens, the bootloader enters into action and gives you 1 or 2 seconds to start sending the data through uart. If this reset circuit does not work, then the bootloader never listens for a new firmware. In summary, C3 needs to be connected to the RTS pin on one side and to the reset pin of the MCU on the other. TX and RX are connected directly to the MCU. That's ok.

I've been checking out the MiniCore project and it seems that there has been a change in the bootloader used. I wonder if this could be the issue. This can be tested quite quickly, change the line: upload_protocol = arduino in env Board_1R3 to upload_protocol = urclock Or you can force the use of the previous bootloader (optiboot) by setting board_hardware.uart = optiboot on the Board_1R3 env

Another quick check to verify if the bootloader is running is to place a led with a current limiter resistor on the RST pin (right above the TX pin). The bootloader should either blink it or completely switch it on on boot.

Hope this helps, and sorry for all the trouble. If this does not work, then I would recommend to flash through the ICSP header.

[jsanpe]

Hi again,

I've been doing some more reading and after inspecting the firts log you sent me I've found this message:

Building in release mode
Using bootloader image:
C:\Users\andy\.platformio\packages\framework-arduino-avr-minicore\bootloaders\urboot\atmega328pb\watchdog_1_s\autobaud\uart0_rxd0_txd1\led+b5\urboot_atmega328pb_pr_ee_ce.hex

which means you have flashed urboot bootloader (makes sense, it's the new default). Again, this is new for MiniCore (which is the backbone of C2C) and was introduced in version 3.0.0 in Oct 2023. So I was not aware of this change. I think this is what's behind the issues you are facing. Replace the upload_protocol as I told you in the past message, that should fix the issue straight away.

There's more info about the new bootloader here and this is the avrdude command they recommend using: avrdude -c urclock -p m328p -b 115200 -P /dev/ttyUSB0 -U flash:w:mysketch.hex:i which in your case it should translate to something like C:\Users\andy\.platformio\packages\tool-avrdude>avrdude -v -p atmega328pb -C C:\Users\andy\.platformio\packages\tool-avrdude\avrdude.conf -c urclock -b 38400 -D -P COM5 -U flash:w:\Users\andy\Documents\Sources\c2c-64\.pio\build\Board_1R3\firmware.hex:i

Again, I think this should solve the issues you are facing. I really hope this time it works.

[ezcGman]

HOLY MOTHER OF GOD, IT WORKED!! :D YOU ARE A GENIUS!!! \o/ Even with my old flasher \o/ THANKS SO MUCH!!!!

So the only changes I now ended up going to the current version of platformio.ini in your repo is:

• Under [env:Board_1R3] setting this upload_protocol = urclock
• And for me / under Windows under [env:fuses_1R3] setting -PCOM4

And confirming my packages and versions for people to come:

PACKAGES: 
 - framework-arduino-avr-minicore @ 3.0.0 
 - tool-avrdude @ 1.70200.0 (7.2.0) 
 - toolchain-atmelavr @ 1.70300.191015 (7.3.0)

Can't wait to test the board now!!

[jsanpe]

Nice! Thanks for having the patience mate, and sorry for all the trouble. This change of bootloader in MiniCore was something I wasn't aware of. And it comes with some breaking changes :( It seems to be a much better/modern bootloader, so the change is for good. But you were the first one to face it.

I will update the platform.ini file in the project with the new upload protocol, which apparently is backwards compatible with arduino.

Enjoy your new C2C!

[ezcGman]

Absolutely no issue, this is a DIY board, these things can and may happen! I even had fun, hunting it and ofc fun building the board :) Thanks to you for the extensive support here!!

I'll try to give it a test this week, packed week this is! I'll follow up with a tiny post/instructions how I used an ESP to flash the bootloader, instead of an Arduino Due. Think this is prettx useful, as everybody probably has an ESP8266/ESP32 somewhere. And if not: It's not even 5€ :)

Later,

Andy!

[jsanpe]

Thanks Andy, if you can write those instructions I can add them to the wiki along with the DUE so people have more options. Let me know if that's ok!

Jose

[ezcGman]

Absolutely, feel free to add them!

---

Use an ESP8266 / ESP32 as ISP (In-circuit Serial Programmer)

Arduino provides a sketch that you can load (basically) onto every device that runs the the Arduino framework, so not only an Arduino DUE, but also the famous Espressif MCUs. You just need to change a few pins, depending on the board you use. You can use whatever "version" of the ESP out there you want (the famous NodeMCUs or D1 Minis, or any other ESP you have with an USB-To-Serial interface connected to it):

1. Download, install and open Arduino IDE
2. Open Arduino IDE and navigate to File -> Examples -> ArduinoISP
3. First: The sketch uses the default SPI pins for the board you compile it for, so we don't even need to touch those. But we need to select different pins for the LEDs it's trying to access on the Arduino boards. Those pins are not accessible on an ESP, so the sketch will crash. It doesn't really matter what you change them to, as long as it's an accessible GPIO. But let's do that together: So go and find the macros "LED_HB", "LED_ERR" & "LED_PMODE". Let's change them to 16, 5 & 4. And to have the wiring a bit more convenient (at least on the NodeMCUs), let's change the "RESET" macro/pin to 15.
4. Now, get your ESP, connect it via USB and flash the sketch to it (remember to select the correct board under Tools -> Board!). It should just flash nicely!
5. Disconnect your ESP from USB again, and hook up the c2c to it (c2c -> ESP):
   • RST goes to GPIO 15 (or D8)
   • MOSI goes to GPIO 13 (or D7)
   • MISO goes to GPIO 12 (or D6)
   • SCK goes to GPIO 14 (or D5)
   • GND goes to any GND pin (important, don't forget!)
6. Re-connect the ESP via USB, power up the c2c (it's advised to NOT do that through the ESP. You can, but the ESP is not designed for that. Rather use an external PSU for the c2c).
7. Open the c2c repo in VS.Code and make sure you have platformio installed inside VS.Code. Open the "platformio.ini" file and find the [env:fuses_1R3]. Change the USB port there (The -P option), if necessary (e.g., if you're on Windows change it to whatever COM-Port the ESP is connected to, e.g. "COM4" (all caps letters!).
8. Open platformio from the left hand menu. Find the "fuses_1R3" task and run the "Set Fuses" and "Burn Bootloader" under "Platform".

You're done :)

Note: You can even use other Arduino based MCUs, you just need to set the correct pins. More info here (the article only covers Arduino board, but not the ESP; hence I wrote it down here): https://docs.arduino.cc/built-in-examples/arduino-isp/ArduinoISP/

---

Feel free to edit / remove whatever u think is unnecessary; I wrote it all down :) I didn't add the change for the bootloader / upload_protocol, as I thought you might want to change that in the repo directly.

Greetings!

[jsanpe]

Neat, thanks so much! I'll add this to the wiki and ensure proper credit is given.

I have already updated the platform.ini file in the repo. It should work fine for both optiboot and urboot now.

[jsanpe]

Wiki updated! https://github.com/jsanpe/c2c-64/wiki/Programming-the-C2C-64

[ezcGman]

Thanks!! Also for the credits!!

Just saw there is a double "the" in the text: "... that runs the the Arduino ..." :)

[ezcGman]

It works!! \o/ Thanks for this fantastic project!!

[jsanpe]

Congrats! N64 looks fantastic through composite, and that leaves you s-video for older systems. For instance, SNES looks awesome through s-video. One C2C, two consoles!

Remember to get a case asap, too many parts to short on that board :D

[ezcGman]

I actually have another N64 RGB modded, so I play N64 using RGB-SCART through the OSSC. Same for SNES, as my PAL SNES still has RGB out natively ;)

In the end, all consoles (and I have quite a few...) work through either RGB-SCART, Component or HDMI already. So I currently don't REALLY NEED the c2c, but I wanted it, as I have no way of connecting composite or S-Video sources to my display. Now I have, if I ever need. The only really need was that N64 which I didn't mod but wasn't sure if it works. And here we go: It does ;)

[khari05]

I was having a similar issue with programming over UART. I never actually solved it, but I got it working using ICSP. Wiring the ICSP header on my generic ft232r programmer from MicroCenter, and setting the upload protocol to the custom avrdude config I had to add to be able to use it properly, got it flashed properly: