-
I built the ATMega328PB circuit below (1.png).
It runs at 3.3v from 1.5v battery using booster and 8MHz from external resonator CSTCE8M00G52A-R0.
Using USBTinyISP I set fuses: Low-FF (for 8MHz), High-D8 (Boot Reset Vector Enabled), Ext-FD.
Using VisualStudio and vMicro plug-in I compiled a program for UNO. vMicro created a HEX file of my program WITH a bootloader which I uploaded over ISP and it runs well (blink the LED).
My final goal is to make a customized 8MHz bootloader but as intermediate step
I am trying to get a sign of life over serial using FT231X FTDI.
I cut the 5v jumper on the FT231X and connected the 3.3v jumper instead.
Then connected (without battery):
ATmega328 FT321X
VCC VCC
GND GND
GND CTS
RST DTR (over 0.1uF)
RxD TX
TxD RX
Since the default UNO bootloader UBRR register is set for 16MHz, I initialize it manually and try to push data over serial.Code: [Select]#define myubbr (8000000/16/9600-1)
void setup()
{
pinMode(6, OUTPUT);
// Init serial
UBRR0H = (unsigned char)(myubbr >> 8);
UBRR0L = (unsigned char)myubbr;
UCSR0A = 0;//Disable U2X mode
UCSR0B = (1 << TXEN0);//Enable transmitter
UCSR0C = (3 << UCSZ00);//N81
}
void loop()
{
digitalWrite(6, HIGH);
delay(100);
digitalWrite(6, LOW);
delay(100);
char * str = "Hello World";
while (*str) {
while (!(UCSR0A & (1 << UDRE0)));
UDR0 = *str++; //send the data
}
}
On the PC I run: avrdude -v -p m328p -c arduino -PCOM8 -b 9600 (see COM PORT settings in 2.png below)
Avrdude recognizes the correct com port but gives:
avrdude: stk500_getsync(): not in sync: resp=0x00
The RX and TX LEDs on the FT231X never blink.
I don't even know if the problem is HW or SW. What am I doing wrong. What else can I try?
-
If your not getting anything on rx and tx, then its likely not sending anything.
As an idiot check. Disconnect your arduino. Connect rx to tx, and send it some data and see what you get back -
If your not getting anything on rx and tx, then its likely not sending anything.
The idiot check worked fine. But this only tells me the FT231X is good. It tells me nothing about my card.
As an idiot check. Disconnect your arduino. Connect rx to tx, and send it some data and see what you get back -
Well now we have ruled out the ftdi as a likely culprit. The default arduino bootloader is what emulates the stk500, have you burned a bootloader to the device using the tinyisp?,
-
Yes I burned a bootloader using tinyISP
-
Even with no bootloader, RX LED should blink when you run avrdude.
-
Why should it blink anyway?
In any case it doesn't. -
RX (or TX, depending on your setup) must blink because avrdude opened the serial port and started sending data to the FTDI board, FTDI chip receives the data and sends it to the output port (RX pin on ATmega328 chip). If there is no bootloader, the ATmega328 chip will not reply and you will not see the TX light blinking. A successful firmware programming on an Arduino board blinks both RX and TX LEDS. If there is a problem with the bootloader, RX LED blinks but there is no reply from the microcontroller.
-
If the idiot check worked fine, you should see RX and TX LEDs blinking everytime you send a character to the FTDI chip and it replies back. Maybe you set echo on the terminal emulation software but there is no actual hardware loopback.If your not getting anything on rx and tx, then its likely not sending anything.
The idiot check worked fine. But this only tells me the FT231X is good. It tells me nothing about my card.
As an idiot check. Disconnect your arduino. Connect rx to tx, and send it some data and see what you get back -
Hi Software Dude, with no bootloader or the wrong oscillator settings or even with no chip at all Avrdude will send an initial very short data packet to try to establish comms and the FT231X will give a very short pulse on the txled pin which is easy to miss. If there is no comms to the chip you are trying to program then you get the not in sync: resp=0x00 message.
I've had the same problem in the past when trying to use an 8MHz crystal, I think the baud rate must have been wrong so I just got the not in sync: resp=0x00 message. I gave up messing with fuse bits and trying different bootloaders and fixed everything by using a 16MHz resonator.
Another issue might be that the chip isn't getting a reset in which case the bootlaoder won't be running and you get the not in sync message. I've successfully used an FTDI MM232R as a programmer but had to use the RTS# pin for reset because the DTR# pin is not available on the MM232R, also had to use FT_Prog to configure the FT232R so that txled# and rxled# were on CBUS3 and CBUS4.
It might be worth checking your FT231X with FT_Prog just to check VID and PID but I'm not sure that that really matters.
Good luck with the ATmega328PB always nice to have the extra peripherals. -
When connected to the board, using Arduino IDE Serial Monitor, if I send a long string I can see the TX led blink but nothing on the RX.
I guess AVRDude sends a handshake message and expects a reply which never comes.
If I continuously send serial data from the board, even if I am in the wrong baud rate I would expect RX to blink and get garbage on the Arduino serial monitor but I get nothing.
DTR to RST has nothing to do with that because my program IS running (blinking LED).
BTW FT_PROG does not support FT231X but in any case, my FT231 seems to be OK. -
Have you tried switching the RX and TX signals?
-
Thanks everyone, its working.
It was ultimately a combination of switching between TX and RX and using half the baud rate of the bootloader on the PC.
So first I loaded: setup { Serial.begin(9600); } loop { Serial.write("Hello"); }. hfuse=D9, opened Arduino Serial Monitor with baud rate 4800 and finally got printouts.
Then I checked 115200 baud with 57600 on monitor in both TX and RX using read/write loop.
Then I burned an UNO bootloader (default baud rate 115200) and set uno.upload.speed=57600 in boards.txt, set hfuse=D8 to run bootloader and now I can upload programs over serial.
-
Could someone explain how/why this works? I assume the actual baud rates must be the same at both ends.
-
The baud rate is created by dividing the on board clock frequency by some formula. To simplify lets say it is: 9600 = 16,000,000 / 1,666.
The bootloader of each board has CLK pre-configured for its CLK, e.g. UNO has a 16MHz clk.
So if I use the pre-configured UNO bootloader but I have 8MHz clk so my baud rate will be half the one on UNO: 4800 = 8,000,000 / 1,666.
So I have to set the PC baud rate to 4800 and voila. -
Then I checked 115200 baud with 57600 on monitor in both TX and RX using read/write loop.
Checked 115200 where? A loopback is baud independent, so it does not matter what you set on the monitor. -
The baud rate is created by dividing the on board clock frequency by some formula. To simplify lets say it is: 9600 = 16,000,000 / 1,666.
I think if you are running @ 8MHz, then you should divide by 833 on the clock frequency formula. If you set the PC baud rate to 4800, then the AVR is also running the USART @ 4800 baud, not 9600.
The bootloader of each board has CLK pre-configured for its CLK, e.g. UNO has a 16MHz clk.
So if I use the pre-configured UNO bootloader but I have 8MHz clk so my baud rate will be half the one on UNO: 4800 = 8,000,000 / 1,666.
So I have to set the PC baud rate to 4800 and voila. -
TK
I looped through the device, not in UART loopback, by which I verified that both TX and RX work at a high baud rate.
Regarding your other comment, I didn't want to touch the bootloader (BL) because creating a custom BL is complicated. So I used the UNO BL with my 8MHz board, which halved the baud rate. -
Quote
It runs at 3.3v from 1.5v battery using booster and 8MHz from external resonator CSTCE8M00G52A-R0.
:
Since the default UNO bootloader UBRR register is set for 16MHz, I initialize it manually and try to push data over serial.Code: [Select]#define myubbr (8000000/16/9600-1)
void setup()
{
pinMode(6, OUTPUT);
// Init serial
UBRR0H = (unsigned char)(myubbr >> 8);
UBRR0L = (unsigned char)myubbr;
UCSR0A = 0;//Disable U2X mode
UCSR0B = (1 << TXEN0);//Enable transmitter
UCSR0C = (3 << UCSZ00);//N81
setup() is MUCH too late to adjust the UBRR values that the bootloader uses!
Basically, if you're using a bootloader that has been compiled for 16MHz (and therefore has appropriate UBRR constants built-in), and you only run your chip at 8MHz, the USART bitrate will be half of what you expect.
You can either recompile (or find) a bootloader that has been set up for 8MHz, or just halve the bitrates you're using. 115200bps at 8MHz is pretty "iffy", so I actually recommend the "run at 57600 instead" method.
There are some alternate Arduino cores ("MiniCore", I think) that include more clocking options, and more bootloader versions, than the normal Arduino distribution.