Go Down

Topic: FT231XS + ATmega328P-AU Programming Issues (Read 573 times) previous topic - next topic

Papkee

Hi all!

Working on a one-off custom board here and hitting a wall with programming via the Arduino IDE.

I have what I believe to be the proper circuit to use the FT231X with an Atmega328P-AU, seen below (these are excerpts from a larger schematic):

USB connection:


FT231 connections:


Mega328 connections:


I'm using the minicore board profiles & bootloader from MCUdude and I've pretty much narrowed it down to some sort of communication issue between the FT231X and the Mega328. I can burn both the bootloader and the sketches I'm trying to run with no issues via an ISP header, and I can communicate just fine with the FT231X using FT_PROG as well. Continuity is also fine on the traces between the FT231 and the MCU.

When I try and upload a sketch via USB, the software takes a few minutes saying "Uploading" before eventually timing out with stk500 "programmer is not responding" errors. Watching the TX, RX, and RESET lines on my scope set to decode UART, I see RESET drop LOW and a couple of packets on the TX line from the 231X (mostly 0xFF and 0xEF so possibly just false positives), but not much activity other than that.

Anyone else succesfully used a 231X to program chips? I'm not sure where to go from here troubleshooting wise so any advice is appreciated.

Budvar10

Probably this is not concerning the problem you are asking about, but why C5 should be directly in DTR line, not between DTR and GND. The purpose is to limit the reset pulse length. Also, in Arduino design there is a diode parallel with R10 to cut off the "undershots" on edge of the reset pulse. See the Arduino UNO R3 schematics.

Post the log from uploading. Mostly 0xFF and 0xEF does not sound optimistic. Are you sure there is no shortage somewhere on Tx and Rx? It is good to connect serial between chips via 1k resistors. Anyhow, I'm recommending to try slower serial speed, like 57600 baud. What will happed?
Arduino clone with ATmega1284P   http://forum.arduino.cc/index.php?topic=277260.0

Papkee

Probably this is not concerning the problem you are asking about, but why C5 should be directly in DTR line, not between DTR and GND. The purpose is to limit the reset pulse length. Also, in Arduino design there is a diode parallel with R10 to cut off the "undershots" on edge of the reset pulse. See the Arduino UNO R3 schematics.
That's a mistake on my part  - I wrongly remembered where the capacitor was placed and didn't double check. Still, I wouldn't think that's the issue but who knows.

Post the log from uploading. Mostly 0xFF and 0xEF does not sound optimistic. Are you sure there is no shortage somewhere on Tx and Rx? It is good to connect serial between chips via 1k resistors. Anyhow, I'm recommending to try slower serial speed, like 57600 baud. What will happed?
If you're talking about the log in the Arduino IDE, here it is. Not much to show:

Code: [Select]
Sketch uses 864 bytes (2%) of program storage space. Maximum is 32256 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x9f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x9f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x9f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x9f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x9f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x9f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x9f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x9f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x9f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x9f
Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.


More Data

So I hooked up my scope to the TX, RX, and RESET lines in order to capture some traces for people here to look at. It seems as if the arduino isn't responding properly. For reference, the colors are as follows: FT231 TX (yellow), FT231 RX (pink), RESET (blue).

RESET being pulled low when programming starts. Also noticing that the RX line is being pulled down to ~2.25V which is interesting. Not sure why that would be but that's definitely suspicious. Could be why the programming is failing.



The first (and only) byte I was able to capture from the FT231 - 0xE0 - this is a 500ms sweep. Something tells me more should be going on here and it's not.


So I suspect that the RX line (TX from the ATmega) being pulled down to ~2.25V could be the issue here. Still, I'm not sure why that's happening in the first place.

Anybody with suggestions, I'm all ears.

kprims



Quote
I wrongly remembered where the capacitor was placed and didn't double check. Still, I wouldn't think that's the issue but who knows.
I think it is the issue.

The DTR lead through the cap should just be a pulse so the bootloader can run.

Papkee

Yeah - I just came to that realization through looking at my scope traces and now I get it.

Makes total sense now that I think about it. My brain just told me "decoupling cap" when I saw the RESET line with a cap on it and I left it at that.

Lesson learned - don't design hardware at 3AM.

Thanks everyone! Time for some bodge wires.

Go Up