I have a custom Arduino board with a ATMEGA328P (with boot-loader). I use an FTDI cable to upload sketches via the serial port. But for some reason my FTDI serial programming cables do not autoreset the ATMEGA.
I have two FTDI cables:
Cable 2: Pololu USB AVR Programmer v2.1
--> This is a ISP/FTDI cable. I use the FTDI serial port. The pololu config software allows me to chose to bring out RTS or DTR as reset line.
Cable 1 never autoresets the ATMEGA for me. And Cable 2 does work, but only if I configure to use DTR.
I saw several articles here that say that AVRDUDE toggles both, RTS and DTR, for reset. But if that is the case, then why does it not work for me? How do I verify in the programming code somewhere that both are toggled?
Or can someone confirm that RTS and DTR are toggled (really both?) for autoreset?
@Budvar10
Good advice on the flags. Do you know which flag gets set when clicking on upload with the Arduino IDE?
@BJHenry
You are asking if there might be an issue with my custom board. Well, I made it myself using a series 0.1uF cap from the RTS (or DTR) line to the reset pin (Pin 1) of the Atmega. On pin 1 there is also a 10k pull-up resistor. As far as I know that is pretty much what the Arduino Uno does as well.
@westfw
Thanks for the source code reference, even with line number. That is very helpful. Indeed you confirmed that both is toggled.
But now I more confused why it does not work with RTS. I'll need to verify with the oscilloscope. I'll post here the conclusion if I do find something.
sweigand:
Do you know which flag gets set when clicking on upload with the Arduino IDE?
Do this:
File > Preferences
Check the box next to "Show verbose output during: > upload".
Click the "OK" button.
Sketch > Upload.
Wait for the upload to finish (or fail).
Examine the contents of the black console window at the bottom of the Arduino IDE window. There you will find the avrdude command used to upload the sketch.
Budvar10:
Arduino IDE it has defined in programmers.txt .protocol.
programmers.txt is only used when you are doing a Upload Using Programmer, Burn Bootloader, or if the hardware package author has configured it so that Upload acts as Upload Using Programmer. For regular uploads, the protocol is defined by the upload.protocol property in boards.txt.
pert:
programmers.txt is only used when you are doing a Upload Using Programmer, Burn Bootloader, or if the hardware package author has configured it so that Upload acts as Upload Using Programmer. For regular uploads, the protocol is defined by the upload.protocol property in boards.txt.
Thanks for pointing out the difference between Upload using the Programmer vs Serial Port via Bootloader. That is important to mention. In my case I am uploading via the serial port using a boot-loaded ATMEGA.
By the the way, the Arduino verbose log does confirm the correct AVRDUDE command:
C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -carduino -PCOM3 -b115200 -D -Uflash:w:C:\Users....
I.e. it does have the "-carduino" parameter.
With all your help I finally found the issue. Do to a very unlucky scenario my cable 1 (Sparkfun FTDI) was broken and my cable 2 (pololu programmer v2.1) does not toogle the RTS line correctly either.
After getting a replacement of cable 1 (exact same type) the RTS line works now. The cable 2 (pololu) might be a driver/firmware issue as it acts very strangely when you try to manually program it.
So, thanks again. Problem solved. I still think this thread is a good reference when debugging. I can finally confirm by hardware that RTS and DTR are both toggled.
For the benefit of the community, please let me add my final analysis:
Cable 1: FTDI Cable 5V - DEV-09718 - SparkFun Electronics
--> Turns out that my cable or Chip inside was broken (RTS was always pegged at 5V). After getting a replacement of this cable (exact same type) the RTS line as reset works fine now.
Cable 2: Pololu USB AVR Programmer v2.1
--> Using RTS line as reset does not work. The Pololu support team has been very helpful here.
The problem here is that the Microsoft Windows driver usbser.sys is buggy. RTS will not change output voltage until DTR asserts also afterwards. Obviously asserting RTS and DTR at the exact same time does not work either; because otherwise it would work with AVRDude. Thus, its apparently an issue with usbser.sys.
So why does the FTDI (cable1) not have the same isse? FTDI uses its own low-level driver that does not use Microsoft's usbser.sys, thus is not affected.
Now finally, all root causes are found.
Thanks to all again.