Autobaud does not work on one ATmega328P board under Windows #5
Comments
|
Run log: |
|
BTW, the autobaud FW seems to work pretty well for the ATmega2560, tested with some random baud rate. Some do not work (300000, 600000, 800000, 900000; 120000, 160000, 170000, 190000, 210000, 310000, 350000). The other baud rates (100000, 200000, 400000, 600000, 700000, 1000000; 115200, 125000, 144000, 150000, 250000, 327680, 330000; 110000, 130000, 140000, 150000, 180000) work well. For lower baud rate it works even better -- 8k, 9k, 10k, 20k, 30k, 40k, 50k, 60k, 70k, 80k, 90k, 100k all work fine. For even lower baud rate, it may have some issues. I can not get anything below 7700 to work. |
Could you try on your board
I have been testing autobaud with FTDI FT232L (don't know whether the board has pullups/pulldowns) and with CH330N (the latter does not need external pullups/pulldowns - the chip does everything right). Both USB-TTL chips work well.
Thanks. Yes, your tests gave the expected results b/c the poor little Atmel USARTs can only do certain baud rates: See my comment in the source code Lines 530 to 580 in 77bec7c Also see the legend for
|
stefanrueger
changed the title
|
@MCUdude - do you have similar experiences? Which USB-TTL chips have you used? |
|
@stefanrueger I've only tried it on this custom DIP-40 board, and it worked all the way from 9600 and up to 2M. This board uses a CH340C USB to serial chip. Never experienced any issues |
|
OK, let's see what @mcuee's tests bring about. If it's pullups/pulldowns then this could be done by software at a cost of 2 bytes each, though my favourite build, the 510 byte |
|
I've tested the autobaud functionality using a bare-bone ATtiny2313 breakout board without any pull-ups or series resistors on the RX and TX lines. I can confirm that autobaud works perfectly using a CH340G USB to serial adapter, a CP2104 USB to serial adapter from Adafruit and an FT232RL based one from Sparkfun. |
|
Brilliant list of USB-TTL tests. Adding my CH330N, we have already 4 chips under our belt. |
|
I have no issues with the CH340G on my Arduino Mega Clone (ATmega2560, 5V, 16MHz). The Arduino Nano Clone which has issues (ATmega328P, 5V, 16MHz) is also using the same CH340G chipset. I will try to test the pull-up/pull-down test later as I am not able to test now. |
|
I can reproduce the issue on another Arduini Nano clone with the same CH340G design but using ATmega168P (5V, 16MHz). So the root cause should be the same. I will try to play with the pull-up/pull-down next week. |
I tested the Arduino Uno Clone using ATmega328P and ATmega16U2 (USB to Serial FW, using USB CDC-ACM class), it can work with even more baud rates than the CH340G. It works well with the above baud rate (300000, 600000, 800000, 900000; 120000, 160000, 170000, 190000, 210000, 310000, 350000). As expected, it does not work with anything <=7700 bps (7800bps works). Official Arduino Uno and Arduino Mega 2560 use ATmega16U2 USB to Serial FW. So urboot autobaud FW should work for many users of such boards. Official Arduino Nano uses FT232RL Most of the Uno and Nano clones use CH340 serials. Note: I am not exactly sure if the ATmega16U2 really talks to the ATmega328P using the baudrate specified though. But at least I can not get other baud rate to work when I use the 115200bps urboot firmware. Edit: I think it does based on the ATmega16U2 FW source codes from Arduino. |
|
BTW, for the two Nano clones, picoboot does not work either. I tested another Uno clone with ATmega328P and CH340G, the test results are the same as the Mega2560 clone with CH340G. This time I pushed it up to 3,000,000 bps (12MHz clock for the CH340G) and the autobaud urboot FW works fine. So there are some design differences on these Nano clones compared to the Uno clones (both use CH340G) which make autobaud not working. |
|
I look at the design of the Nano clones and the design may be quite similar to this one. The TX/RX LED driving circuitry may be the problem. --> but my clones have 1k Ohm and not 330 ohm for the LED driving.
Just a comparison, official Arduino Nano has two FT232RL CBUS pins driving the TX/RX LEDs. |
|
Official Arduino Uno Rev3 schematics: two GPIO pins of the ATmega16U2 (USB to Serial chip) are driving the TX/RX LEDs. Typical Arduino Uno clone CH340G schematics: the TX/R LEDs driver circuitry is actually similar to my two Nano clones. Note: TX LED driving is not so correct, R8 (1k ohm) should be moved to the right of the TX LED. Typical Arduino Uno clone FT232RL schematics: using CBUS pins to drive TX/RX LEDs, similar to official Arduino Nano design. |
|
I've alto tested autobaud on a CH330N with the following schematic. It works perfectly fine. The only difference is that all resistors are 1k, except for R6 which is 10k. It's an older design, so I don't remember why I didn't use 10k for R6. Also, the power flags are either 5V or 3.3V, but for some reason, the text above the power symbols are gone
|
|
Interestingly I have another ATmega328P Nano clone (Type C, CH340G, 5V,16MHz) which works well with the autobaud urboot FW (up to 2,490,000bps). I should be able to compare the differences of the different Nano clones next week. |
|
@MCUdude It should be using the following sequence. But the clone design makes a mistake for either the RX or TX LED driving. |
|
Further debugging shows an interesting result. I use another CH340 USB to TTL converter (COM13) to connect to the Nano 168P clone -- without the DTR RC reset add-on -- so I have to use manual reset (by pressing the button after the command). But now it works. Then I find out I do not need the external USB to TTL converter either. Rather I can use manually reset and it will work with the on-board CH340G (COM10). This points out some subtle difference between the autobaud FW and the normal FW (no need the manual reset). It could be the reset times out too fast before the baud rate negotiation. |
I am thinking that #7 can help in this situation but I am not so sure if it is in scope for urboot or not. I can see that optiboot_x and optiboot_dx has the 8s delay option for chips without proper auto reset. |
|
I am also testing with a ATmega32A breakout board (5V, 8MHz crystal, CH340G) without the proper DTR RC reset circuitry. It does have a reset button. I can get the 115,200 bps and 1,000,000bps urboot FW working well by pressing the reset button but not the urboot autobaud FW. Then I tested another ATmega8A breakout board (5V, 16MHz crystal) with an external CH340G USB to TTL converter, I am able to use the reset buttone to get autobaud urboot FW to work. |
Baud rate detection is fast. The following sequence is needed, tough:
For manual reset on a board without reset-circuit compile with a WDTO=8S timeout. Upload as follows
For automated reset it could be that the board takes a loooong time to get out of reset, by which time avrdude had already sent the GET_SYNC; investigate the Are you in a position to compile the bootloaders? Try uncommenting the line Line 2232 in 016e957 This creates a software pullup for rx. Compile by either or (if you don't get urboot-gcc to work) Must be on Linux, I am afraid. |
|
I should be able to build any command line application with proper build instruction under Linux/macOS/Windows. :) I will give it a try to build custom urboot FW. Going back to the initial issues, I think autobaud FW is really working well. It is the RESET circuitry which can be the problem. The pull-up/pulll-down on the TX/RX lines does not seem to be the issue here. |
|
@mcuee Impressive array of Cross OS experience. Also would be interested which tips you have to better describe how to build the .hex files. For the time being, here is a hex file with software rx pullup ( See if that does the trick. |
Tested and it does not work as expected -- reset is the problem and not rx/tx pin pull-up/pull-down. I still need to manually press the reset button after the avrdude command. |
|
First hurdle to build the hex file is with the toolchain. |
|
But no problem for me -- I can use the gcc-avr and avr-libc provded by Ubuntu 20.04 to build the hex file. |
|
The result hex file works perfectly. I do not need to manually press the button any more. Strange thing is that it seems to work with any baudrate >=400bps, even rediculously high numbers above the crystal frequency (16MHz). Maybe it is not really true. Probaly Linux just caps the max baud rate it uses. |
|
It also works fine with Windows -- down to 7800 bps and up to 3,000,000bps. |
@stefanrueger How should I invoke the Makefile if I want to use the system provded toolchain (urboot-gcc -toolchain=system`)? |
The Makefile selects a suitable toolchain for the bootloader, but if you want to force a particular version it is Here a few truly random examples how to invoke make Here all make-commands.zip that I used for the pre-compiled bootloaders. Note they are generated by |
Thanks, I just pushed symbolic links, too. |
So timing? Well, I don't get this. The bootloaders were compiled with Are you sure you set the fuses correct? And deleted flash before burning the bootloader? Note, you cannot put a program and a vector bootloader onto the chip at the same time. The vector bootloader must be burned onto an erased chip first. Then you can upload with the vector bootloader (remember |
Cannot imagine. A 16 MHz AVR can only tolerate baud rates in the following intervals ( I think what is happening is that when Linux cannot generate the requested baud rate it uses a nearby standard one. The baud rates that the USB-TTL parts can generate Linux-side are much more fine grained than AVR USART baud rates, but still there is a limit in the driver software. |
|
@MCUdude and @mcuee: I have now implemented a further safety feature for urboot bootloaders: Whenever a vector bootloader is being compiled and there are enough bytes left, this protection is automatically built in. It is visible as a capital I think this is now the last addition I do for urboot after sorting out autobaud and security. Unless there are bugs you see in the next two weeks, I'll release v7.7 of urboot, the first public release! |
That is what I believe as well. |
If you look at my runlog, I use usbasp to burn the FW, so an erase will happen. So Windows is the issue here. It does not work with the stock urboot FW, no matter which Windows runlog: you can see the 8s urboot FW works but stock urboot FW does not work. |
I wonder whether excluding Windows from reducing the drain timeout is to blame here: https://github.com/avrdudes/avrdude/blob/7f4474f0497099f9ad048948a53383b4cd729327/src/urclock.c#L2046-L2048 Other than that, it could be peculiarities on the rx line when opening the serial port. An oscilloscope might show what happens with the rx line in Windows and what in Linuz. |
|
@stefanrueger |
|
Re-open to continue the discussion. |
mcuee
changed the title
|
I tried the following and it does not help. --> Sorry wrong one. Ignore this one. |
|
This works for me. |
You are absolutely right, 80ms works for Windows as well. So the following simple fix should work. I've tested 150ms and 200ms as well -- they work as well but 250ms failed for the Nano Clone. |
|
This change is also good for my Uno clone (ATmega16U2 USB to Serial FW). It is just that very high baud rate does not work well for sketch upload (only works up to 1,300,000bps) during the verification stage. That is probably the limitation of ATmega16U2 USB to Serial FW. I checked the default 250ms version and it has the same results.
|
|
Since this is avrdude |
So, I am guessing that a 250 ms drain timeout setting in windows can translate to around 1000 ms wait and borderline a timeout for boards that come out of reset slower than others. I think (speculate!) that's because in windows the drain timeout is applied between characters as well as a final wait for characters after the last one was read; in Linux it's only the latter as far as I know. So, with 80 ms for Windows, all is OK? autobaud? fixed baud? different boards? BTW, I would be surprised if the LGT8F328P worked with the autobaud detection: The reason is that the loop that measures the baud rate must be 5 clock cycles to work, but according to this document the number of clock cycles is different for all three instructions in the loop at Lines 2323 to 2325 in 0adff89 |
If it's a 16 MHz board this cannot be. Max is F_CPU/8, ie 2 MHz baud rate. So really important to establish what baud rate is actually used. Ralph recommends studying the kernel source to figure out what the actual generated baud rate is: avrdudes/avrdude#1171 (comment) |
Yes I believe Linux only selects the nearby baud rate. Anyway, this is not a real isse -- we can dig out the kernel source code later. |
Yes 80ms for Windows is good for my boards tested -- Uno ATmgea16U2 clone, Uno CH340 Clone, Nano CH340 Clone {all three using ATmega328P at 16MHz) and Mega2560 CH340 clone. The Uno ATmgea16U2 clone, Uno CH340 Clone and Mega2560 CH340 clone work well with the default 250ms drain timeout value. Only the Nano Clone does not work. But if you are really concerned about this parameter, you may want to get a new extension parameter like
I do not have the programmer setting up for the LGT8F328P so I can not burn the bootloader . I was using the factory bootloader ( |
I think the real test is to flash a hex file. The Uno clone with ATmega16U2 USB to Serial FW is using kernel CDC-ACM driver. It only works to 1,000,000bps. |
This is not valid for CH340. It claims to work to baud rate above the crystal frequency, which can not be true. Kernel drivver source code is here. |
|
The max baud rate for the CH340 under my Ubuntu 20.04 is 4,000,000 bps. Same for PL2303. Same results for the CDC-ACM ATmega16U2. CP2102 has less number and also lower baud rate. I am not so sure if it is avrdude |
|
A good info about USB to TTL converter is here. It only caters for UPDI parts though. But practically speaking anything above 500,000bps may not help much (avrdude speed is similar using 1,000,000 bps and 500,000 bps) |
Oops, I find another issue now. If I use the Optiboot bootloader (optiboot_atmega328.hex from Arduino), the Nano Clone does not work well with 80ms, rather I need to add So the urboot autobaud FW works with 80ms but not 250ms. Optiboot FW works with 250ms but not 80ms. It seems to me 150ms may be a good compromise for Windows. Sorry for the late findings. |
Interestingly I have a Arduino Nano clone with CH340 and Atmega328P (5V, 16MHz). It works well with 115200bps and even 1000000bps urboot hex file (tested with the variant (tested with ee_led+b5_fr_ce_ur_vbl) but not working with the autobaud firmware (no matter which baud rate I try). Kind of strange.
The autobaud FW works fine with my Uno Clone (ATmega328P, 5V, 16MHz) and Mega2560 Clone (ATmega2560, 5V, 16MHz).
Maybe this is not a real issue but rather board specific.
The text was updated successfully, but these errors were encountered: