1

I have an handful of fake arduino nanos. The work fine, but as an experiment, I tried to program them with a usb serial adapter (a real FTDI one). It doesn't work, but also, strangely, it seems to stop the bootloader from working properly too, or just puts the arduino in a mode where the /dev/ttyUSB* device doesn't appear, and only reappears when I burn the bootloader again

When I try to upload the sketch using the usb serial adapter, I get this:

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
Failed uploading: uploading error: exit status 1

Then, when I try to upload a sketch over usb again, /dev/ttyUSB* no longer appears when I plug in the usb cable to the normal usb jack.

However, when I can still put the sketch on using an in-circuit-programmer, and when I use the in-circuit-programmer to burn the bootloader again, /dev/ttyUSB* appears again, and I can upload sketches over usb again.

Is that possible? What could I be doing wrong

Here is how I connected the usb to serial adapter to the fake arduino:

adapter connected to fake arduino

(checkout https://i.stack.imgur.com/nh3d6.jpg for a bigger picture)

So basically I have connected between the arduino (left column) and the usb to serial adapter right column:

TX - RX
RX - TX
VIN - VCC
GND - GND
RST - 0.1uF capacitor - DTR

I have tried it with and without the reset pin.

The usb to serial adapter is set to 5V.

another clue:

If I leave the adapter and arduino connected as in the picture, but plug the usb cable into the arduino instead of the adapter, so the adapter is powered by the arduino - it still gets the error that I have shown, and stops working completely until I reburn the bootloader.

Does anybody have any idea why this could be happening?

UPDATE:

After it was pointed out, I started using the 5v pin instead of the VCC pin on the fake arduino, but the same thing keeps happening:

  • burn the boot loader
  • normal usb upload works
  • try to upload with the serial adapter
  • doesn't work
  • normal usb upload no longer works until I burn the bootloader again
Improve this question
6
  • thanks. I connected two adapters together to make sure they both worked, and sent messages both ways. I should have mentioned at
    – Alex028502
    Apr 5 at 20:10
  • 1
    Vin is for 7 to 12 V input. feed 5 V over the 5 V pin. the DTR may not work so try a manual reset while avrdude attempts to upload
    – Juraj ♦
    Apr 6 at 4:59
  • 3
    You appear to have connected the 5v output of the FTDI adapter to the Vin pin of the Nano. You should instead use the 5v pin of the Nano to avoid the path through the internal voltage regulator. You are also aware that if you use the ICSP pins to download a sketch to the Nano, that overwrites the boot loader ?
    – 6v6gt
    Apr 7 at 8:18
  • Yes I have changed power to the 5v pin since @Juraj pointed it out, and gotten the same result. Yeah, I burned the bootloader using the ICSP pins each time. That's the only way I could fix normal upload. Once I fix the bootloader, I can upload sketches until I try to upload with the serial adapter, and then the bootloader seems to stop working.
    – Alex028502
    Apr 9 at 12:33
  • I have ordered a real arduino nano, so I'll try with that as soon as it gets here - to try to zero in on the issue
    – Alex028502
    Apr 11 at 16:47

2 Answers 2

Reset to default
1

OK this was a combination of at least two things:

Main problem:

connecting the fake arduino's RST pin to the FTDI's DTR pin via a 0.1uF capacitor seems to stop it from uploading, when when you manually reset. Also when I remove it it doesn't seem to fix itself right away if you can believe it.

Red Herring

This was not the direct cause of this issue, but is probably a big problem for a lot of other fake arduinos out there:

When I went back to the built-in USB, brltty's udev rules were claiming the CH341 as described here https://askubuntu.com/questions/1403705/dev-ttyusb0-not-present-in-ubuntu-22-04

So if you just have the simpler problem of a fake arduino not appearing, this might solve the problem for you:

sudo apt-get remove brltty

or if you need brltty you can just go into the udev rules that come with it and comment out this one:

# Device: 1A86:7523
# Baum [NLS eReader Zoomax (20 cells)]
ENV{PRODUCT}=="1a86/7523/*", ENV{BRLTTY_BRAILLE_DRIVER}="bm", GOTO="brltty_usb_run"

(as long as that isn't the screen reader you use - then you might just have to buy a real arduino, or make some better udev rules that recognise your screenreader from the port it's plugged into)

The reason this confused me is that when I tried to plug in to the standard usb port after failing to use the programmer, the above udev rules kicked me out. But then I think when I burned a new bootloader, because you still have to power the board from usb while the pololu is connected, I managed to have it connected without the above udev rule kicking it - and then when I tried the external FTDI again, and then plugged back in the internal CH341, the brltty udev rule claimed it, and it seemed like trying to upload over FTDI is what broke it.

Improve this answer
3
  • wouldn't you have the same problem uploading with the on-board FTDI? how is this related to the use of external FTDI on RX.TX pin?
    – Juraj ♦
    Nov 11 at 13:35
  • yeah - that's a good point. I haven't quite figured it out. I think either this was the only problem, and I totally misinterpreted it - or there was another problem, but having this problem at the same time made it really hard to figure out.
    – Alex028502
    Nov 11 at 16:06
  • I have updated the answer @Juraj. The direct cause was trying to automatically reset - which you also suggested I stop, and the CH431 udev issue just distracted me from getting to the bottom of that, since I couldn't verify that the arduino was working at all.
    – Alex028502
    Nov 14 at 13:50
-1

It appears the boot loader does not support serial programming. You would need to change that first. Is the baud rate the same?

Improve this answer
1
  • 1
    it works over USB and the USB chip connects to the same RX/TX as the header pins RX/TX
    – Juraj ♦
    Apr 10 at 6:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.