FT232R Atmega328P

For days now I’m trying to write an Atmega328P with a FT232R.
I was on the wrong way for a long time, because the error message was always, I should install libusb.
I did that with MacPorts and also with Homebrew.
But I just can’t get any further. Strangely enough, it has also worked once, but then no longer.
Defective USB cable or board can be excluded.

By the many test is already much again commented out…
Bildschirmfoto 2022-05-19 um 19.34.23

Can someone please show me the Platform.ini for this configuration?

What’s your wireup between your FT232R and the ISP header of the ATMega328P?

What’s the last error message?

Is simply put together, nothing can be wrong :wink:

Currently I get once again:
“avrdude: error: no libftdi or libusb support. Install libftdi1/libusb-1.0 or libftdi/libusb and run configure/make again.”

But when I tested different configurations in the ini, there were different ones. Always different, depending on what is in my ini.

Bildschirmfoto 2022-05-19 um 20.19.19

As far as I know and read in the avrdude configuration files, the “FT232R” method is for uploading via the ISP header of the chip, where you connect the FT232’s lines as follows

Basically through clever tricks, the UART adapter can talk SPI directly to the chip and doesn’t need to go through a bootloader.

What you’re showing here is the plain old regular serial upload which requires a UART bootloader (optiboot) to be burned into the target chip a-priori. This is usually done before the device is sold. That goes over UART (TX, RX), power iss upplied via GND + VCC and DTR is a reset signal.

No special configuration is needed to upload to that, that is already the default protocol (which is -c arduino by the way). (Remove all upload_* options from the platformio.ini).

When you said

That was in that exact above connection scheme?

Yes was in that exact above connection scheme.

Have adjusted the Platformio.ini:
Bildschirmfoto 2022-05-20 um 15.30.24

Bildschirmfoto 2022-05-20 um 15.31.47

Since I once used the STK500_v2 via terminal, it doesn’t work with the FT232R anymore and now the wrong programmer shows up here again.

There a couple options with that:

  • you’ve somehow overwritten the optiboot bootloader on the target board, therefore flashing via UART is no longer possible until the bootloader is reflashed (which can be e.g. done with the Arduino IDE → Tools → Select programmer & Burn Bootloader). However that overwrite of the bootloader must have happened with an ISP programmer, so not possible if you connected it exactly like that…
  • one or more connection is loose
  • bootloader is there, but uses a different baud rate (not ever heard of that happening on that board)

So actually I would suggest that you reflash the bootloader. See e.g. Arduino Pro Mini Sketch upload funktioniert nicht, Fehler „avrdude: stk500_getsync() attempt x of 10: not in sync: resp=0xfe“ – Thing King – Technik & DIY. This is also a very good test if the target board is alive at all.

^ Above blog post uses another Arduino Nano flashed with the “Arduino as ISP” so that that can be used as the ISP programmer, which is then connected to the ISP (aka SPI pins) of the target board. Technically you could also use your FT232R as a ISP programmer, but by using the pin mapping I posted above (so e.g., RXD goes to MISO which is pin 12 on the target board, et cetera), but that requires then that you custom invoke avrdude with changed flags on the commandline for the FT232R programmer. So for simplicity, better follow a known way.

Great, now it works :slight_smile: Thank you!!
I have now used a new FT232R and a new target board and now it suddenly works. so far I had always used only a new target board and the old FT232R.

At the now not working target board I wanted to set the fuses with a STK500_v2. Something must have gone wrong…

I can also set the fuses in the Platformio.ini, right?

Well yes but, if the programmer cannot connect to the board, you also can’t burn any fuses. (Docs).

Depending on what fuses you set you might have done something wrong in clock prescalar settings… Which fuse bytes did you set exactly? You might set upload_speed to e.g. half or double the intended 57600 baud and get it working by chance.

I wanted to set these fuses according to the instructions:
-Ulfuse:w:0xFF:m -Uhfuse:w:0xD2:m -Uefuse:w:0xFF:m

How would I have to enter this in Platformio.ini so that something doesn’t go wrong again?