[solved!]: schematic and board check please

Projects General Guidance
1

ok I'm stumped
it's a simple enough board
FTDI chip and ATmega328p

the FTDI seems to work. I tried shorting TX and RX, open the monitor, whatever I type in gets echoed

the ATmega bit is more of a problem
I've installed optiBoot, LED 13 flashes 3 times so I guess that's ok

but I can't upload sketches

again, if I short D0 and D1, whatever I type in the monitor gets echoed
so it looks like everything up to D0, D1 is ok

I'm using a 16 MHz resonator instead of 8MHz

I have another board with identical MCU design, just laid out differently, it works

I tried bypassing the FTDI part (in fact didn't install the chip)
used a SparkFun FTDI Basic
it talks to the "previous" design, but not this one

I'm tearing what's left of my hair out

would be most obliged for someone to point out my stupid mistake:

thanks!

schematic:

board:

edit to change title to solved :slight_smile:

2

Just off hand, what are you doing with CTS?

3

Ignoring it!
It's what I usually do

4

I've always tied it LOW on a FTDI cable.
I'll try to compare your board to the schematic.

5

What are you measuring for the supply voltage on the Mega?

6

A shortcut on the pcb ?

7

I've looked at everything and I can't see a problem. What about fuse settings, have you selected the external clock for example?

Have you looked to see if the oscillator is oscillating?

Rob

8

LarryD:
I've always tied it LOW on a FTDI cable.
I'll try to compare your board to the schematic.

you had me going there for a second
tied CTS low, but no change
I also tried a couple of "proper" FTDI boards with CTS open - they work fine
I guess it defaults low, and you have to drive it high
I also wired up just the FTDI part and it talks nicely to other boards, so I think FTDI is in the clear (for now)
but thanks for looking :slight_smile:

LarryD:
What are you measuring for the supply voltage on the Mega?

a gnat's over 3.3 volts - just as I expected

Caltoa:
A shortcut on the pcb ?

nice try, but no :frowning:
I buzzed it through every connection
clean as a whistle :slight_smile:

Graynomad:
I've looked at everything and I can't see a problem. What about fuse settings, have you selected the external clock for example?

Have you looked to see if the oscillator is oscillating?

Rob

Rob,
I put a scope on the oscillator and its ackling nicely
also I can install optiBoot, and pin 13 flashes 3 times as it should
so I'm guessing fuses and clock are ok

could be a faulty mega, but I can't believe I have 4 like that!

9

am I right in assuming that the chip must be fairly intact if I can install the bootloader and pin 13 flashes on startup?

10

I'd say that's a fair assumption, not to say something may not be broken still.

Maybe you have to write some code to test and load it with ISP.

Rob

11

mmcp42:
I've installed optiBoot, LED 13 flashes 3 times so I guess that's ok

Within one second?

12

If you can, upload a simple sketch that outputs a continuous stream of ASCII characters. Are you able to receive that on a PC?

13

mmcp42:
I've installed optiBoot, LED 13 flashes 3 times so I guess that's ok

When you attempt an upload?

14

As I understand the problem, the only evidence presented so far for chip/board failure is the failure to communicate with it via the FTDI chip and UART, which assumes that the UART baud rate is correct. In turn, baud rate calculations assume a CPU clock rate. What have you done to verify that the CPU clock rate is exactly (or close enough to) what you are assuming it is?

A quick and dirty test of the CPU clock rate would be to use the ICSP to burn a blink program, blinking the LED at exactly 1 Hz.

15

ok, I re-read all the suggestions...... and found the fault

some idiot (cough) installed the bootloader for an ATmega328 (28 pin DIP) instead of 328p (32 pin SMD)
I have fired the individual in question, installed the correct bootloader (thanks again to Saint Nick Gammon)
and I have 4 out of five boards working AOK

the 5th board, the FTDI side is fine, but I can't even read the fuse bits
so looks like I may have set the "don't allow programming by SPI" bit
without a high voltage programmer - that one will have to stay in the isolation ward for a bit

so thanks to all for
a) listening
b) offering advice
c) leading me (kicking and screaming) to a result

I love this forum :slight_smile:

16

mmcp42:
so looks like I may have set the "don't allow programming by SPI" bit

It is possible you are not getting a reasonable clock signal from the resonator (e.g. soldering problem). Try injecting a signal on XTAL1 (be sure to use a series resistor; ~1K is probably a good choice).

17

ATmega328 (28 pin DIP) instead of 328p (32 pin SMD)

Don't see why that would matter - the die is the same no matter what.
If the wrong board type was selected, Uno vs Nano, you'd just lose the A6/A7 funtionality. I don't think the bootloader is involved in that, is it?

18

CrossRoads:

ATmega328 (28 pin DIP) instead of 328p (32 pin SMD)

Don't see why that would matter - the die is the same no matter what.
If the wrong board type was selected, Uno vs Nano, you'd just lose the A6/A7 funtionality. I don't think the bootloader is involved in that, is it?

I'm guessing the pin vs. chip numbers are different
but it seemed to make a difference
and it's working now so I'm happy

actually more in-depth answer, the programming also changed the clock divide from 8 to 1, so maybe that was the real fix

anyhoo - I'm up and running now :slight_smile:

19

I dunno, you just can't get good help these days.

changed the clock divide from 8 to 1

That's why I asked about the fuses before.

Rob

20

Graynomad:
I dunno, you just can't get good help these days.

changed the clock divide from 8 to 1

That's why I asked about the fuses before.

Rob

yup
it was your post that eventually sunk in!