Serial drain timeout and -c urclock
#1193
Assignees
Labels
bug
Something isn't working
Comments
|
But I need to confirm under whether Linux or macOS is okay with 80ms or not. My initial testing results under Linux shows that both 80ms and 150ms timeout do not work. Strange. I need to double check. |
mcuee
changed the title
-c urclock-c urclock
|
I would really like to know what's behind this! Windows and Linux do not use the same draining function (well both are called I can set all to 150 ms, but it;'s better to understand why Windows needs these high values and why Windows cannot cope with a 500 ms WDT timeout. Any takers for an analysis what's needed for the handshake? We need to consider this both for fixed-baudrate bootloaders and for autobaud. |
My tests under Linux are that almost any timeout works as long as it is, say, some 100 ms less than the WDT timeout. This variable is not critical at all, but because it delays the sync, I like to set it small. No difference fixed-baudrate/autobaud. |
With that I mean; provide a timing profile for the handshake process using, eg, my timing branch for this. Under Linux there is the same timing profile for urboot v7.7 autobaud, urboot v7.6 fixed-baudrate and optiboot v8.3: |
|
Testing under Windows. Timing for urboot fix-baud FW: Timing for urboot autobaud FW: Timing for Optiboot FW (Arduino default). |
|
Further timing test for Optiboot using an Arduino Uno Clone (using ATmega16U2 USB to Serial) |
|
Looks like |
|
Another board (Nano Clone with CH340) under Windows. |
|
For the Nano Clone, no issue with STK500v1 urboot autobaud FW or fix-baud FW. |
|
New tests using the Arduino Uno clone (ATmega16U2 USB to Serial chip). As mentioned in the first post, the following patch seems to work fine. But it is kind of strange why it works. Therefore I apply the same patch for the timing debug branch. Here are the timing comparison of two working solution.
|
No issues with Linux, with either 80ms or 150ms. I may have a wrong fuse setting yesterday. |
|
@mcuee Thanks for careful and systematic timing profiles. Looks like the problems you are facing are almost exclusively with optiboot. Turns out I can reproduce this under Linux. My initial tests were with optiboot v8.3, but I overlooked the culprit here is actually optiboot v4.4. Luckily, they shipped the source with Arduino, so I could read what optiboot v4.4 does for handshake: turns out it
These two together mean that any two-byte sync sequence sent in the first 300 ms get their first byte thundered over in the USART. Can be solved with a looooooooong initial delay. But who wants to wait for 250 ms drain + 250 ms initial delay (as in Updated the timing branch for you, so you can examine and test with different boards, OS and bootloaders. My tests were: I am currently using decidedly short timeouts (rcv=40 ms, drain=10 ms). I hope they work with Windows! Results for Optiboot v4.4 (shipped with Arduino) Results for optiboot v8.3 Results for urboot v7.7 autobaud Results for urboot v7.7 fixed baudrate Only rarely did an -xdelay value not work out. Almost all work, and certainly those around 0, so no need to specify them at all. I might remove that option. |
|
Great. Now it works without |
|
Second test with Arduino Nano clone (CH340) |
|
Same Arduini Nano clone, using @MCUdude's MiniCore, Optiboot version 8.0. No issues with BigBoot (Optiboot version 8.3) either. Also tested the ATmega2560 with MegaCore optiboot bootloader. |
|
But there is a regression with picoboot. No Earlier version works fine. Please check if there is a work-around or not. If no easy workaround, we can favour optiboot 4.4 as it is distributed by Arduino and used by many users. I am fine with that Same results using another picoboot FW. |
|
Tested the LGT8F328P bootloader as well (57600bps). I found out the bootloader used is this one. There is one retry but it is still okay. |
|
@mcuee I have an LGT8F328P board I bought a few years ago just for curiosity. However, I was never able to use anything else than the pre-flashed Which "ISP programmer" (Or is it ISP?) are you using for the LGT8? |
|
You can make an LGT ISP programmer using the Arduino Nano. Before today I have only tried the factory bootloader and not the ISP programmer. But I just tried the LGT ISP programmer using the ATmega328P Nano Clone based LGTISP programmer and it seems to work fine (using the hex file LGTISP.hex). It is using SWD protocol. |
|
You can also use the following version. I have not tried it. |
|
Arduino lgt8fx seems to work as well for the bootloader burning, even though there will be error messages about fuse. The bootloader seems to work fine. |
Thanks for finding this! I think I know why. Will check, but it may be too difficult to cater for all b/l so they start up quickly. |
Could be added to hash table. 4096 bytes is a large bootloader. You had another one at 2048 bytes? |
|
BTW, @MCUdude the |
|
Needs careful checking whether the |
@stefanrueger The bootloader is actually not big at all, but it somehow starts at 0x7400. |
|
I have pushed new code to the timing test branch. Now picoboot should work, but must add Also added experimental code that should work for |
Yes picoboot now works with
Hmm, do you have the urboot autobaud bootloader hex file for the LGT8F328P? The Nano Clone with LGT9F328P uses internal RC oscillator (default 32MHz). |
|
Urboot with autobaud on an LGT8F328P would be interesting, especially when running at 32 MHz. In theory, upload speed could be really, really fast, as long as the USB to serial chip can keep up. The CH340* chip is for instance significantly slower than a CP2102N when uploading at higher speeds (115200 baud+). It would be interesting to see if Urboot EEPROM support works. IIRC, the LGT8F328P uses an emulated EEPROM, where it actually uses the flash memory as EEPROM. |
The existing bootloader and LGTISP do not seem to work with EEPROM. So EEPROM support will be a nice new feature. |
Do you have some data for comparison of different USB to TTL chipset? For example, CH340, FT232RL, CP2102, PL2303 and the Arduino ATMega16U2 (for official Arduino Uno and Mega2560) are popular. |
Same results under Windows. This time I tried to push to the limit. I am okay with the |
Well, urboot bootloaders certainly have no idea about parts with emulated EEPROM. I suspect, but do not know
I would just try to burn the ATmega328p autobaud bootloader for LED at B5, or, if the board does not have an LED this one. These should, in theory, work for all F_CPU [edit: but need the timing test branch for -c urclock`] No EEPROM support. The |
|
@mcuee Thanks for all the testing on this. The problem with backward compatibility is that all the different bootloaders do different things under the STK500v1 protocol. It was impossible to get everything working without extra info by the user (and this is what Do you want to see a PR for the final changes or is it OK if I just push this timing test branch onto git main after cleaning the timing profile printouts? The PR makes sense if you want to (and can) test again. |
Which makes it 3076 bytes long. It ends at 0x7800. I suspect the last 2k are reserved for, eg, "EEPROM"? I have just added the hashes for this bootloader. |
Yes I agree. I have no issues with requiring |
@stefanrueger |
|
@stefanrueger Sorry I have to flash the hex file and it works. I think LGTISP FW may have some issues. Actually I can not get it working under my Linux machine. |
@stefanrueger BTW, shifting the bootloader hex to 0x7400 does not help either. Run log: |
You cannot just shift the bootloader! The jump to the application is an rjmp forward over the end of the flash wrapping around to 0 and then further to the right vector to get to the application. Shifting the hex needs the |
I understand that. I was just trying my luck... Further discussions of LGT8F328P urboot support is here. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From here:
Testing results with the default Arduino
optinoot_atmega328p.hexon a typical Arduino Clone (using ATmega16U2 as USB to Serial chip) and I can see the current default timeout value of 80ms is not good for Windows.I need the following patch to get it working. This is the same for the Nano clone (ATmega328P, 16MHz).
Testing results:
The text was updated successfully, but these errors were encountered: