Having just built my first uno2iec with a nano clone I found a glitch in the logging code that will cause some cheap Chinese nano clones to constantly hardware reset after sending the 'connect_arduino:2' message.
With five Nano's to test from (4 being the same type) - 4 had the ch341 USB chip and 1 had a genuine FTDI USB chip. The 4 with the ch341 all presented the same reset problem while the 5th FTDI version had no issues. I don't believe the USB chip is the problem but I've written the chip type here as an easy way to identify the clone Nano's. I also disabled the auto-reset on power up from the ch341 USB chip in case that was the culprit.
Diving deeper and debugging the code to find out where the Nano was resetting lead me into the registerFacilities() function inside log.cpp
Commenting out one line at a time narrowed down the offending/resetting code to this one line:
strcat_P(strBuf, (PGM_P)facilities[i].string); /* this line seems to cause the nano3 clone to continuously reset */
My guess is some sort of RAM buffer overflow or address corruption is happening on these cheap nasty clones...
What registerFacilities() does or is need for, I don't know but I've commented out the call to that function and have not had an issue with the operation or performance of uno2iec. Also just commenting out the offending line of code also produces a working uno2iec with no undue effects.
Having just built my first uno2iec with a nano clone I found a glitch in the logging code that will cause some cheap Chinese nano clones to constantly hardware reset after sending the 'connect_arduino:2' message.
With five Nano's to test from (4 being the same type) - 4 had the ch341 USB chip and 1 had a genuine FTDI USB chip. The 4 with the ch341 all presented the same reset problem while the 5th FTDI version had no issues. I don't believe the USB chip is the problem but I've written the chip type here as an easy way to identify the clone Nano's. I also disabled the auto-reset on power up from the ch341 USB chip in case that was the culprit.
Diving deeper and debugging the code to find out where the Nano was resetting lead me into the registerFacilities() function inside log.cpp Commenting out one line at a time narrowed down the offending/resetting code to this one line:
strcat_P(strBuf, (PGM_P)facilities[i].string); /* this line seems to cause the nano3 clone to continuously reset */My guess is some sort of RAM buffer overflow or address corruption is happening on these cheap nasty clones... What registerFacilities() does or is need for, I don't know but I've commented out the call to that function and have not had an issue with the operation or performance of uno2iec. Also just commenting out the offending line of code also produces a working uno2iec with no undue effects.