Troubleshooting custom Arduino Nano board - Page 1
Forum section: electronics / general

author: Jackster
author_rank: Frequent Contributor
timestamp: May 07, 2017, 05:06:35 pm
content: Hi all.So I have this project I have been working on that is so close to being finished but I am hittings a few walls atm.My project is based off an Arduino Nano with FDTI FT232R as programmer.I have used open the open source circuit and make it in Altium's Circuit Maker.I have also printed my boards and have made a couple up.The problem I am facing atm is that I am unable to use the Arduino software to upload sketches to the ATMEGA 328p chip.I bought the chips from RS in the UK so they come blank.I'v use the MiniPro TL866CS to load on the bootloader to the chip and also fuse it.I have tried a couple of the bootloaders that are in the Arduino folder.ATmegaBOOT_168_atmega328.hex & optiboot_atmega328.hexBut when I open the Arduino software and try to upload I get this error;Code:Sketch uses 928 bytes (3%) of program storage space. Maximum is 30720 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 respondingavrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x1davrdude: stk500_recv(): programmer is not respondingavrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x1davrdude: stk500_recv(): programmer is not respondingavrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x1davrdude: stk500_recv(): programmer is not respondingavrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x1davrdude: stk500_recv(): programmer is not respondingavrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x1davrdude: stk500_recv(): programmer is not respondingavrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x1davrdude: stk500_recv(): programmer is not respondingavrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x1davrdude: stk500_recv(): programmer is not respondingavrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x1davrdude: stk500_recv(): programmer is not respondingavrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x1davrdude: stk500_recv(): programmer is not respondingavrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x1dProblem uploading to board. See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.I have tried a few things from trying the other bootloaders to reseating the 328p multiple times (not easy as I am using the 32pin QFP).At this point I am not sure what my next move is.Any ideas?ThanksJack,

author: igendel
author_rank: Frequent Contributor
timestamp: May 07, 2017, 05:33:41 pm
content: Assuming the bootloader is ok, and from your description it should be, This sort of problem usually appears when the connection between the USB-to-UART and the MCU is bad: the Reset line, swapped RX/TX, unintended contact with Vcc/Ground somewhere etc.

author: Jackster
author_rank: Frequent Contributor
timestamp: May 10, 2017, 04:26:21 pm
content: Oh bollocks I see what I have done.Original Nano schematicMineSomewhere I un-flipped my TX and RX so that the FTDI is sending to the MCU's TX.This only happened with my 2nd board. The first one does not have this mistake.

author: cowana
author_rank: Frequent Contributor
timestamp: May 10, 2017, 04:42:44 pm
content: Quote from: Jackster on May 10, 2017, 04:26:21 pmSuch a standard error! I'd be surprised if there's any digital electronics designer who hasn't accidentally made that mistake at some point (be it during prototyping or on PCB) - it's why including series components that can be removed from TX/RX lines is usually a good idea to avoid having to cut PCB tracks!

author: Jackster
author_rank: Frequent Contributor
timestamp: May 10, 2017, 04:55:19 pm
content: Quote from: cowana on May 10, 2017, 04:42:44 pmLuckily I have a resistor network between the FTDI and the MCU. Though I still need to test it.Not got a fine enough soldering iron and wire though to do this.Or a steady hand :p

author: igendel
author_rank: Frequent Contributor
timestamp: May 11, 2017, 04:05:42 pm
content: Quote from: cowana on May 10, 2017, 04:42:44 pmIndeed. Been there too.

author: retrolefty
author_rank: Super Contributor
timestamp: May 11, 2017, 04:58:18 pm
content: Quote from: igendel on May 11, 2017, 04:05:42 pmMe too.The problem with simple uart serial data connections is that the terms Transmit (Tx) and Receive (Rx) does not define if the signal is a input or output wired between the two devices without looking at the datasheet for both devices as there is no standard to define direction like MOSI & MISO used in SPI communications. It also traces back to the original RS-232 connections where you had to know if a device was defined as the DTE end or the DCE end before one could properly wire up connections.I probably did not define the problem too well, but any of you that worked starting with true RS-232 from the late 60s onward can relate I'm thinking. I spent too many hours getting different manufactures serial ports working together to not miss that dance. And the problem still exists to this day even on TTL serial links.

author: anovickis
author_rank: Contributor
timestamp: July 17, 2017, 11:26:42 pm
content: Don't worry it happens - but you figured it out that's what is important.I have designs with hierarchical schematics and many diff pairs and I get something wrong - sometimes simple things.