Closed dbuchwald closed 6 months ago
askn37
commented
7 months ago There are two suggestions for additional circuitry to enable experimentation.
dbuchwald
commented
7 months ago Thank you for your answer, but I must say I'm still unable to replicate the issue. I have actually spent some time trying to understand the circuit and its expected impact on the chip, but I'm still stuck.
What I did was the following:
/Users/dawid/Development/avrdude/build_darwin/src/avrdude -C /Users/dawid/Development/avrdude/build_darwin/src/avrdude.conf -c serialupdi -P /dev/cu.usbserial-0001 -p avr16eb28 -Ueeprom:w:test_files/0xff_512B.hex -Ueeprom:v:test_files/0xff_512B.hex -xrtsdtr=high
avrdude: forcing serial DTR/RTS handshake lines HIGH
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e943f (probably avr16eb28)
avrdude: processing -U eeprom:w:test_files/0xff_512B.hex:i
avrdude: reading input file test_files/0xff_512B.hex for eeprom
with 512 bytes in 1 section within [0, 0x1ff]
using 64 pages and 0 pad bytes
avrdude: writing 512 bytes eeprom ...
Writing | ################################################## | 100% 2.47 s
avrdude: 512 bytes of eeprom written
avrdude: verifying eeprom memory against test_files/0xff_512B.hex
Reading | ################################################## | 100% 0.38 s
avrdude: 512 bytes of eeprom verified
avrdude: processing -U eeprom:v:test_files/0xff_512B.hex:i
avrdude: verifying eeprom memory against test_files/0xff_512B.hex
Reading | ################################################## | 100% 0.38 s
avrdude: 512 bytes of eeprom verified
avrdude: releasing DTR/RTS handshake lines
avrdude done. Thank you.I have also tried connecting scope to the RTS, RESET and UPDI lines, and I don't understand what is supposed to happen here. CH1 (yellow) is directly to RTS, CH2 (purple) is connected to UPDI input:
When connecting CH1 (yellow) to RESET input I get:
Honesly, I don't understand - is that quick low pulse generated on RTS line supposed to trigger RESET on AVR? Even if it does, it's like 300ms before we start sending any meaningful data over UPDI, isn't that enough to boot the chip?
askn37
commented
7 months ago Thank you very much for your time. It is clear that this phenomenon is very strongly dependent on the individual's environment.
My environment: iMac24(M1) + macOS14.2.1 AVRDUDE build: macport + libserialport tarball USB converter: WCH CH340-X + macOS preinstalled driver Reset circuit 1: C1=1uF R1=NF
Device: AVR16EB32/TQFP32 bare metal 5.2V
Test code: Get the user's time delta 'elapsed_millis' from a specific location.
Test results;
Prepare "-c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr16eb32" and press 'enter' or 'space' to continue. Press any other key to skip
avrdude error: programmer does not support extended parameter -x rtsdtr=high, option ignored
avrdude error: programmer does not support extended parameter -x rtsdtr=high, option ignored
avrdude error: programmer does not support extended parameter -x rtsdtr=high, option ignored
avrdude error: key was not accepted
avrdude error: elapsed_millis: 424
✅ eesave fuse bit set, cleared and verified
avrdude error: key was not accepted
avrdude error: elapsed_millis: 394
✅ the_quick_brown_fox_16384B.hex flash -U write/verify
avrdude error: key was not accepted
avrdude error: elapsed_millis: 373
✅ the_quick_brown_fox_512B.hex eeprom -U write/verify
avrdude error: key was not accepted
avrdude error: elapsed_millis: 367
✅ lorem_ipsum_16384B.srec flash -U write/verify
avrdude error: key was not accepted
avrdude error: elapsed_millis: 485
✅ lorem_ipsum_512B.srec eeprom -U write/verify
avrdude error: key was not accepted
avrdude error: elapsed_millis: 460
avrdude warning: verification mismatch
device 0x00 != input 0xff at addr 0x0000 (error)
avrdude error: verification mismatch
❌ 0xff_512B.hex eeprom -U write/verify
➡️ command "/Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr16eb32 -e -Ueeprom:w:test_files/0xff_512B.hex -Ueeprom:v:test_files/0xff_512B.hex" failed
❌ the_quick_brown_fox_16384B.hex:a flash -T write/verify
➡️ command "/Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr16eb32 -T "write flash test_files/the_quick_brown_fox_16384B.hex:a"" failed
❌ the_quick_brown_fox_512B.hex:a eeprom -T write/verify
➡️ command "/Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr16eb32 -T "write eeprom test_files/the_quick_brown_fox_512B.hex:a"" failed
avrdude error: key was not accepted avrdude error: elapsed_millis: 320
❌ lorem_ipsum_16384B.srec flash -T write/verify
➡️ command "/Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr16eb32 -T "write flash test_files/lorem_ipsum_16384B.srec"" failed
❌ lorem_ipsum_512B.srec eeprom -T write/verify
➡️ command "/Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr16eb32 -T "write eeprom test_files/lorem_ipsum_512B.srec"" failed
❌ cola-vending-machine.raw flash -T/-U write/verify
➡️ command "/Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr16eb32 -T 'erase flash; write flash -512 0xc0cac01a 0xcafe "secret Coca .bin recipe"' -U flash:w:test_files/cola-vending-machine.raw -T 'write flash -1024 "Hello World"'" failed
avrdude error: key was not accepted
avrdude error: elapsed_millis: 445
✅ holes_pack_my_box_16384B.hex:a flash -U write
❌ holes_the_five_boxing_wizards_16384B.hex flash -T write
➡️ command "/Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr16eb32 -T "write flash test_files/holes_the_five_boxing_wizards_16384B.hex"" failed
avrdude error: key was not accepted
avrdude error: elapsed_millis: 297
✅ holes_pack_my_box_512B.hex:a eeprom -U write
❌ holes_the_five_boxing_wizards_512B.hex eeprom -T write
➡️ command "/Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr16eb32 -T "write eeprom test_files/holes_the_five_boxing_wizards_512B.hex"" failed
avrdude error: key was not accepted
avrdude error: elapsed_millis: 334
✅ random_data_64B.bin usersig -T/-U write/readIn fact, when measured using user time, it takes about 400ms from DTR/RTS operation to when a key error occurs. From a software perspective, this is enough time for the AVR to recover from the reset.
In the case of the combination of "serialupdi" + "AVR-Ex", this hardware environment setting can be determined to be invalid. Coincidentally, it doesn't seem to be detected by "urclock" or any other system (other than AVR-Ex, ESP32, STM32).
If you look closely, this development board has his four gate drivers for TxD, RxD, DTR, and RTS that drive the LED indicators. The gate resistance seems to be 1M ohm.
I overlooked it! In other words, it's like adding an extra parallel capacitor to each of DTR and RTS. It shouldn't be common. My judgment at this point is that this must be the real cause. I must deeply apologize.
dbuchwald
commented
7 months ago @askn37 please, don't apologize, you did nothing to be sorry about. I still think you are correct that there is some issue there, we are just unable to find good explanation for what happens. And if I can't replicate the issue, then the only way forward is that I try writing different variants of the code and you test them against your setup. It's going to be slow, but it might be the only way.
In the meantime I had some other ideas:
pymcuprog and AVRDUDE abort procedure if KEY_STATUS is not 'accepted' (bit 4), but the entire step is optional, so maybe we should only post warning there and carry on,pymcuprog and AVRDUDE - after uploading the NVMPROG key and sending reset request we check ASI_SYS_STATUS for PROGSTART only once and fail if it's not set correctly, but the datasheet (see below) suggests to repeat the procedure until the condition is met. Maybe that would address the issue you saw in your setup? Can we give it a try?
- Read the Start NVM Programming (PROGSTART) bit from the ASI System Status (UPDI.ASI_SYS_STATUS) register.
- NVM programming can start when the PROGSTART bit is ‘1’. If the PROGSTART bit is ‘0’, return to step 6.
/Users/dawid/Development/avrdude/build_darwin/src/avrdude -C /Users/dawid/Development/avrdude/build_darwin/src/avrdude.conf -c serialupdi -P /dev/cu.usbserial-0001 -p avr16eb28 -T 'config rstpincfg' -Ueeprom:w:test_files/0xff_512B.hex -Ueeprom:v:test_files/0xff_512B.hex -xrtsdtr=high
avrdude: forcing serial DTR/RTS handshake lines HIGH
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e943f (probably avr16eb28)
avrdude: processing -T config rstpincfg
config rstpincfg=reset # 1
avrdude: processing -U eeprom:w:test_files/0xff_512B.hex:i
avrdude: reading input file test_files/0xff_512B.hex for eeprom
with 512 bytes in 1 section within [0, 0x1ff]
using 64 pages and 0 pad bytes
avrdude: writing 512 bytes eeprom ...
Writing | ################################################## | 100% 2.41 s
avrdude: 512 bytes of eeprom written
avrdude: verifying eeprom memory against test_files/0xff_512B.hex
Reading | ################################################## | 100% 0.37 s
avrdude: 512 bytes of eeprom verified
avrdude: processing -U eeprom:v:test_files/0xff_512B.hex:i
avrdude: verifying eeprom memory against test_files/0xff_512B.hex
Reading | ################################################## | 100% 0.37 s
avrdude: 512 bytes of eeprom verified
avrdude: releasing DTR/RTS handshake lines
avrdude done. Thank you.EDIT: I pushed the aforementioned fix candidate to my branch: https://github.com/dbuchwald/avrdude/tree/issue_1609
askn37
commented
7 months ago @dbuchwald
Finally, there is important discrepancy between the datasheet and (again) both pymcuprog and AVRDUDE - after uploading the NVMPROG key and sending reset request we check ASI_SYS_STATUS for PROGSTART only once and fail if it's not set correctly, but the datasheet (see below) suggests to repeat the procedure until the condition is met. Maybe that would address the issue you saw in your setup? Can we give it a try?
Yes, I would like to request that.
I designed my own UPDI programmer from hardware and also wrote the firmware myself. This is because special hardware and software are essential to enable high voltage control. Most of my resources are information available from public datasheets and AT packs. I didn't investigate the source of pymcuprg until recently. I'm not good at speaking in Python. Still, I thought it was strange that pymcuprg had so few polling loops.
dbuchwald
commented
7 months ago @askn37 fix candidate is already available, you just need to pull latest changes to issue_1609 branch from my fork of avrdude.
As for pymcuprog - it's a weird software altogether, but I would take "working" code over my own interpretation of datasheets any day. Problem is that it's not all that "working" after all...
askn37
commented
7 months ago @dbuchwald thank you. I tried.
And run on AVR64EA32, with the problematic serial adapter
Prepare "-c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr64ea32" and press 'enter' or 'space' to continue. Press any other key to skip
avrdude error: programmer does not support extended parameter -x rtsdtr=high, option ignored
avrdude error: programmer does not support extended parameter -x rtsdtr=high, option ignored
avrdude error: programmer does not support extended parameter -x rtsdtr=high, option ignored
✅ eesave fuse bit set, cleared and verified
✅ the_quick_brown_fox_65536B.hex flash -U write/verify
✅ the_quick_brown_fox_512B.hex eeprom -U write/verify
✅ lorem_ipsum_65536B.srec flash -U write/verify
✅ lorem_ipsum_512B.srec eeprom -U write/verify
avrdude warning: verification mismatch
device 0x00 != input 0xff at addr 0x0000 (error)
avrdude error: verification mismatch
❌ 0xff_512B.hex eeprom -U write/verify
➡️ command "/Users/askn/Collaborator/avrdude_issue1609/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr64ea32 -e -Ueeprom:w:test_files/0xff_512B.hex -Ueeprom:v:test_files/0xff_512B.hex" failed
✅ the_quick_brown_fox_65536B.hex:a flash -T write/verify
✅ the_quick_brown_fox_512B.hex:a eeprom -T write/verify
✅ lorem_ipsum_65536B.srec flash -T write/verify
✅ lorem_ipsum_512B.srec eeprom -T write/verify
✅ cola-vending-machine.raw flash -T/-U write/verify
✅ holes_pack_my_box_65536B.hex:a flash -U write
✅ holes_the_five_boxing_wizards_65536B.hex flash -T write
✅ holes_pack_my_box_512B.hex:a eeprom -U write
✅ holes_the_five_boxing_wizards_512B.hex eeprom -T write
✅ random_data_64B.bin usersig -T/-U write/readAt least no key registration failure messages are observed.
dbuchwald
commented
7 months ago @askn37
It seems like the issue is resolved, isn't it?
Just to be 100% sure, can you go back to previous commit and test again to confirm the issue occurs in the previous version? Sorry, I really don't want to waste your time, but I would like to be absolutely sure that the results are reliable.
git checkout db5d6f4c89b5aec4ebb9751dfecfb76210774cfe
rm -rf build_darwin
./build.sh
...
./build_darwin/src/avrdude
Usage: avrdude [options]
Options:
-p <partno> Specify AVR device; -p ? lists all known parts
-p <wildcard>/<flags> Run developer options for matched AVR devices,
e.g., -p ATmega328P/s or /S for part definition
-b <baudrate> Override RS-232 baud rate
-B <bitclock> Specify bit clock period (us)
-C <config-file> Specify location of configuration file
-C +<config-file> Specify additional config file, can be repeated
-N Do not load config file
-c <programmer> Specify programmer; -c ? and -c ?type list all
-c <wildcard>/<flags> Run developer options for matched programmers,
e.g., -c 'ur*'/s for programmer info/definition
-A Disable trailing-0xff removal for file/AVR read
-D Disable auto erase for flash memory; implies -A
-i <delay> ISP Clock Delay [in microseconds]
-P <port> Connection; -P ?s or -P ?sa lists serial ones
-r Reconnect to -P port after "touching" it; wait
400 ms for each -r; needed for some USB boards
-F Override invalid signature or initial checks
-e Perform a chip erase
-O Perform RC oscillator calibration (see AVR053)
-t Run an interactive terminal when it is its turn
-T <terminal cmd line> Run terminal line when it is its turn
-U <memstr>:r|w|v:<filename>[:format]
Carry out memory operation when it is its turn
Multiple -t, -T and -U options can be specified
-n Do not write to the device whilst processing -U
-V Do not automatically verify during -U
-E <exitsp>[,<exitsp>] List programmer exit specifications
-x <extended_param> Pass <extended_param> to programmer, see -xhelp
-v Verbose output; -v -v for more
-q Quell progress output; -q -q for less
-l logfile Use logfile rather than stderr for diagnostics
-? Display this usage
avrdude version 7.2-20240114 (db5d6f4c), https://github.com/avrdudes/avrdudeWhat is important is this part: avrdude version 7.2-20240114 (db5d6f4c)
Then, if it turns out that it fails as it used to, please pull the latest version again (it will contain fix for #1622 as well, just pushed it), invoke avrdude again to confirm latest version (avrdude version 7.2-20240119 (45b53658)).
If the db5d6f4c commit fails and 45b53658 works then we can safely conclude that latest change fixed this strange issue.
askn37
commented
7 months ago @dbuchwald I got it. Follow that step.
run test NVM V3
Prepare "-c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr64ea32" and press 'enter' or 'space' to continue. Press any other key to skip
avrdude error: programmer does not support extended parameter -x rtsdtr=high, option ignored
avrdude error: programmer does not support extended parameter -x rtsdtr=high, option ignored
avrdude error: programmer does not support extended parameter -x rtsdtr=high, option ignored
avrdude error: key was not accepted
✅ eesave fuse bit set, cleared and verified
avrdude error: key was not accepted
✅ the_quick_brown_fox_65536B.hex flash -U write/verify
avrdude error: key was not accepted
✅ the_quick_brown_fox_512B.hex eeprom -U write/verify
avrdude error: key was not accepted
✅ lorem_ipsum_65536B.srec flash -U write/verify
avrdude error: key was not accepted
✅ lorem_ipsum_512B.srec eeprom -U write/verify
avrdude error: key was not accepted
avrdude warning: verification mismatch
device 0x00 != input 0xff at addr 0x0000 (error)
avrdude error: verification mismatch
❌ 0xff_512B.hex eeprom -U write/verify
➡️ command "/Users/askn/Collaborator/avrdude_issue1609/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr64ea32 -e -Ueeprom:w:test_files/0xff_512B.hex -Ueeprom:v:test_files/0xff_512B.hex" failed
❌ the_quick_brown_fox_65536B.hex:a flash -T write/verify
➡️ command "/Users/askn/Collaborator/avrdude_issue1609/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr64ea32 -T "write flash test_files/the_quick_brown_fox_65536B.hex:a"" failed
❌ the_quick_brown_fox_512B.hex:a eeprom -T write/verify
➡️ command "/Users/askn/Collaborator/avrdude_issue1609/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr64ea32 -T "write eeprom test_files/the_quick_brown_fox_512B.hex:a"" failed
avrdude error: key was not accepted
❌ lorem_ipsum_65536B.srec flash -T write/verify
➡️ command "/Users/askn/Collaborator/avrdude_issue1609/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr64ea32 -T "write flash test_files/lorem_ipsum_65536B.srec"" failed
❌ lorem_ipsum_512B.srec eeprom -T write/verify
➡️ command "/Users/askn/Collaborator/avrdude_issue1609/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr64ea32 -T "write eeprom test_files/lorem_ipsum_512B.srec"" failed
❌ cola-vending-machine.raw flash -T/-U write/verify
➡️ command "/Users/askn/Collaborator/avrdude_issue1609/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr64ea32 -T 'erase flash; write flash -512 0xc0cac01a 0xcafe "secret Coca .bin recipe"' -U flash:w:test_files/cola-vending-machine.raw -T 'write flash -1024 "Hello World"'" failed
avrdude error: key was not accepted
✅ holes_pack_my_box_65536B.hex:a flash -U write
❌ holes_the_five_boxing_wizards_65536B.hex flash -T write
➡️ command "/Users/askn/Collaborator/avrdude_issue1609/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr64ea32 -T "write flash test_files/holes_the_five_boxing_wizards_65536B.hex"" failed
avrdude error: key was not accepted
✅ holes_pack_my_box_512B.hex:a eeprom -U write
❌ holes_the_five_boxing_wizards_512B.hex eeprom -T write
➡️ command "/Users/askn/Collaborator/avrdude_issue1609/build_darwin/src/avrdude -qq -c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr64ea32 -T "write eeprom test_files/holes_the_five_boxing_wizards_512B.hex"" failed
avrdude error: key was not accepted
✅ random_data_64B.bin usersig -T/-U write/readrun test NVM V3
Prepare "-c serialupdi -xrtsdtr=high -P /dev/cu.usbserial-230 -p avr64ea32" and press 'enter' or 'space' to continue. Press any other key to skip
avrdude error: programmer does not support extended parameter -x rtsdtr=high, option ignored
avrdude error: programmer does not support extended parameter -x rtsdtr=high, option ignored
avrdude error: programmer does not support extended parameter -x rtsdtr=high, option ignored
✅ eesave fuse bit set, cleared and verified
✅ the_quick_brown_fox_65536B.hex flash -U write/verify
✅ the_quick_brown_fox_512B.hex eeprom -U write/verify
✅ lorem_ipsum_65536B.srec flash -U write/verify
✅ lorem_ipsum_512B.srec eeprom -U write/verify
✅ 0xff_512B.hex eeprom -U write/verify
✅ the_quick_brown_fox_65536B.hex:a flash -T write/verify
✅ the_quick_brown_fox_512B.hex:a eeprom -T write/verify
✅ lorem_ipsum_65536B.srec flash -T write/verify
✅ lorem_ipsum_512B.srec eeprom -T write/verify
✅ cola-vending-machine.raw flash -T/-U write/verify
✅ holes_pack_my_box_65536B.hex:a flash -U write
✅ holes_the_five_boxing_wizards_65536B.hex flash -T write
✅ holes_pack_my_box_512B.hex:a eeprom -U write
✅ holes_the_five_boxing_wizards_512B.hex eeprom -T write
✅ random_data_64B.bin usersig -T/-U write/readThe results seem to be good. I will write the rest in #1622.
askn37
commented
7 months ago As I was checking the whole thing, I noticed that there was some code that I couldn't understand. We operate RTS/DTR with double break. There is no comment as to why it does this.
This is fine in my environment, but if this code was inserted with a strong will, it suggests that there is hardware that requires it.
One interpretation: this part reopens the serial port and changes the baud rate. At this time, the previous state of DTR/RTS may not be carried over depending on the OS. (?)
dbuchwald
commented
7 months ago @askn37
About the RTS/DTR code, I managed to find this part of e-mail from over two years ago, when the RTS/DTR flag support was added to SerialUPDI programmer to accommodate dual function UPDI/Serial adapters where the mode is controlled by state of these lines:
See, the problem (I think) is that there is something off about the POSIX serial code in core AVRDUDE. To make this RTS/DTR thing work I had to do something really strange: each time after changing line parameters (for the UPDI BREAK message) I have to manually pull the line high and then pull it low. Simply pulling it low doesn’t work! It seems like the code that changes connection parameters somehow de-asserts RTS line, but device driver is not aware of this, ignoring next request for pulling the line down.
So yeah, it means your interpretation is correct, at least for some combination of serial adapter/OS/drivers. I remember we did have issues when it was first introduced, and the issues were like "works everywhere but not in FreeBDS" or something like that.
All in all, if you wondered about the code that changes baud rate, there is also some explanation for it, and it's OS related, with the MacOS being the oddball here:
The reason you were seeing these pulses during AVRDUDE session (usually only at the beginning), is that there is somewhat weird code in the serialupdi driver. I took it directly from pymcuprog, and I must say I didn’t like it a lot, but assumed it necessary. See, NVM programming interface works as very simple and limited state machine. Should something go wrong it simply clams up and stops responding to any requests at all. The only way to get it to work again is to force NVM controller reset by sending two consecutive serial break messages around 24ms each. The way it is implemented in pymcuprog (and this is the part I didn’t like) is that connection mode is changed to 300 baud 8E1 and 0x00 value is sent out. 0x00 encoded in 8E1 at 300 baud translates to approx. 24ms low signal and does the job. I copied this functionality hoping to look into it some day and possibly fix it in my implementation. Now, what happens is in AVRDUDE is that the code responsible for changing connection speed actually disconnects serial and connects it again, changing some internal OS driver structures. These disconnect/connect events were causing strange pulses you saw.
When you brought this up, I started looking into it and found proper solution: instead of changing baud rate to 300 and sending some value, I can use standard library function to send standard serial break message. Or, so I thought.
Enter POSIX:
https://linux.die.net/man/3/tcsendbreak
tcsendbreak() transmits a continuous stream of zero-valued bits for a specific duration, if the terminal is using asynchronous serial data transmission. If duration is zero, it transmits zero-valued bits for at least 0.25 seconds, and not more that 0.5 seconds. If duration is not zero, it sends zero-valued bits for some implementation-defined length of time.
Now, what does the “implementation-defined” length of time means for “portable” POSIX library. Absolutely nothing at all. This particular parameter is completely ignored on MacOS, and the actual duration is about 500ms. On Linux on the other hand, this parameter is taken properly into account and represents the duration in milliseconds.
I tested it and it turned out to work on MacOS for the chips I had, but in the end I decided not to use it. See, I can’t guarantee that 500ms (or 250ms, or whatever will be in upcoming MacOS Big Cock) will work with any of the AVR chips to come. On top of that it severely prolongs the duration of the session (by about 2 seconds, which is actually noticeable). I suppose this is why Microchip decided to use the strange 300 baud 8E1 hack for their implementation, and I decided they most probably know their stuff better than I will ever do.
So yeah, go portability. Go standards! Be careful.
Bottom line: it's good that you are asking, because some of these things could have ended up there by accident, but quite frankly, when I go through my old e-mails I realize how many things I forgot about the project. Problems mostly, serious problems that we took a lot of time and effort to investigate and fix.
As reported by @askn37, there is an issue with programming NVM V3+ chips when the boot operation is not fully completed. This results in NVM controller not accepting
NVMProgkey and can cause programming failure, like so:Please note: this bug should be filed as unconfirmed until detailed replication procedure is provided.