CURRENT: upload_protocol = arduino
BeforeUpload(["upload"], [".pio/build/pro16MHzatmega328/firmware.hex"])
Auto-detected: /dev/cu.usbserial-210
avrdude -v -p atmega328p -C /Users/tcurdt/.platformio/packages/tool-avrdude/avrdude.conf -c arduino -b 57600 -D -P /dev/cu.usbserial-210 -U flash:w:.pio/build/pro16MHzatmega328/firmware.hex:i
avrdude: Version 6.3-20190619
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/Users/tcurdt/.platformio/packages/tool-avrdude/avrdude.conf"
User configuration file is "/Users/tcurdt/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/cu.usbserial-210
Using Programmer : arduino
Overriding Baud Rate : 57600
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
avrdude done. Thank you.
Not all my FTDIs have a DTR. But I can switch to one that does.
I guess if the FTDI does not have a DTR I’d need the workaround with the capacitor?
As for the bootloader - no idea. Ideally I would like to learn to flash that, too.
Just not sure how with the Pro Mini. How would one connect a usbtinyISP?
No if you have a regular Pro Mini then that already has the needed cap + resistor.
Connect a FTDI programmer that exposes DTR like that. The board is actually made so that you can just connect an FTDI which has male header pins solders onto it into the Pro Mini (even without soldered headers).
CURRENT: upload_protocol = arduino
BeforeUpload(["upload"], [".pio/build/pro16MHzatmega328/firmware.hex"])
Auto-detected: /dev/cu.usbserial-00000000
avrdude -v -p atmega328p -C /Users/tcurdt/.platformio/packages/tool-avrdude/avrdude.conf -c arduino -b 57600 -D -P /dev/cu.usbserial-00000000 -U flash:w:.pio/build/pro16MHzatmega328/firmware.hex:i
avrdude: Version 6.3-20190619
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/Users/tcurdt/.platformio/packages/tool-avrdude/avrdude.conf"
User configuration file is "/Users/tcurdt/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/cu.usbserial-00000000
Using Programmer : arduino
Overriding Baud Rate : 57600
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
avrdude done. Thank you.
*** [upload] Error 1
This looks good. CTS in an input on the FTDI’s side, so it just receives GND there but shouldn’t try to drive it.
Does the power LED on the bottom right corner of the board light up when you press then FTDI into it as shown? Maybe a bad connection? Or, a missing bootloader, or worst case a blown chip.
Usually with Pro Mini the bootloader is preflashed to save the user the trouble… You can use PlatformIO or the Arduino IDE or the commandline to flash the bootloader. However, burning the bootloader must be done via the SPI connections with an ISP-capable programmer (USBASP, TinyISP) or an Arduino (Uno) with the ArduinoAsAISP sketch. This is detailed in Pro-Mini-Klone: Bootloader flashen | Hausautomation mit Arduino.
Then as the docs say, , you can then e.g. open a CLI and execute pio run -t bootloader (or additionally with -v to see more output). This will push the bootloader as defined in the board to the board.
Ah if you’ve uploaded another program to the chip after burning the bootloader, that erased the bootloader again. Uploading with a programmer takes over the whole programming space.
Can you try to burn the bootlaoder and directly after that switch to FTDI based programming? Or is that what you’re already doing.
I’ve uploaded the bootloader via ISP and unless I was mistaken the blink program was already running afterwards. My assumption: It just wrote the bootloader and the blink was already in the program space.
I then switched to a FTDI upload and tried that.
After flashing a couple of the boards I have
2 boards where ISP flashing and then FTDI flashing works
2 boards where ISP flashing worked, but then FTDI flashing still fails
…and I am surprised why there is a difference between the boards that should be from the same batch.
Yeah - I just totally didn’t expect the crystal to be different.
They were all bought in the same batch. Never trust.
So “Am” means 16MhZ?
Just switching to pro8MHzatmega328 didn’t allow for a FTDI upload - but after reflashing the bootloader with the correct board all seems to be working OK now.