Current anytone-branch writes garbled user DB to radio (config is ok again!)

[allesand]

Just tested with my 868 with firmware 2.40: read the config from the radio and wrote it back without making any changes, 868 starts with "Program Error / Please Initialize The Radio! / Confirm" - then I am presented with the "Calibrate Date" screen as expected. What can I provide to debug that? Must have been introduced in the last weeks, the branch used to work.

No unexpected debug output: Debug in lib/usbdevice.cc@247: Check if serial port ttyACM3 still exisist and has VID:PID 28e9:18a. Debug in lib/usbdevice.cc@247: Check if serial port ttyACM3 still exisist and has VID:PID 28e9:18a. Debug in lib/radio.cc@56: Try to detect radio at Serial interface 'ttyACM3'. Debug in lib/usbserial.cc@90: Try to open Serial interface 'ttyACM3'. Debug in lib/usbserial.cc@124: Opened serial port ttyACM3 with 115200baud. Debug in lib/anytone_interface.cc@307: Anytone: In program-mode now. Debug in lib/anytone_interface.cc@336: Found radio 'D868UVE', version 'V102'. Debug in lib/anytone_interface.cc@356: Anytone: Left program-mode. Debug in lib/usbserial.cc@155: Serial port will close now. Debug in src/application.cc@736: Write complete.

Will test with my 878 when I have a working second radio again, hold on.. :-)

[allesand]

If of any help: when writing the user db with the current anytone-branch to the 868 - which is working without problems! - there is the following output incl. three "FATAL":

Debug in lib/radio.cc@56: Try to detect radio at Serial interface 'ttyACM3'. Debug in lib/usbserial.cc@90: Try to open Serial interface 'ttyACM3'. Debug in lib/usbserial.cc@124: Opened serial port ttyACM3 with 115200baud. Debug in lib/anytone_interface.cc@307: Anytone: In program-mode now. Debug in lib/anytone_interface.cc@336: Found radio 'D868UVE', version 'V102'. Debug in src/application.cc@680: Sort call-signs closest to ID=1234567. FATAL in lib/dfufile.cc@665: Cannot resolve offset 4fd86a0h. FATAL in lib/dfufile.cc@665: Cannot resolve offset 54986a0h. FATAL in lib/dfufile.cc@665: Cannot resolve offset 5bd86a0h. Debug in src/application.cc@708: Start call-sign DB write... Debug in lib/anytone_interface.cc@356: Anytone: Left program-mode. Debug in lib/usbserial.cc@155: Serial port will close now. Debug in src/application.cc@736: Write complete.

Will try later with the 878, no recent CPS backup..

[allesand]

This actually should be in https://github.com/hmatuschek/qdmr/issues/298 should it? Is there a way to join the two issues or close here and add there? Sorry about that..

[hmatuschek]

A separate issue is ok. The other one is purely for the extension module. Not bugs introduced with it. This one, however, will be hard to find. It would help to find the commit, that broke the 868.

[allesand]

I can confirm that my 878 running 3.01 shows the same result - reading the current config and writing it back gives the above error, so it is not a problem with the 868, as it affects both of my radios. I will try some older branch versions and report back if I found what breaks my config.

Here is the chronological record:

Ok, https://github.com/hmatuschek/qdmr/commit/f84a8ad75cb0f5c62836bacf8aaf8593b9a7c405 - Mar 11, 2023 loads the config to the radio just fine

Next https://github.com/hmatuschek/qdmr/commit/b87b3c860fd87268cda46dc7cc57e99aa1a8c7c0 - Mar 13, 2023 Works - writes config to 878 all ok

Next one to test is https://github.com/hmatuschek/qdmr/commit/32ed33dad3a569d7262da13ec71978ab30a49b9b - Mar 14, 2023 qdmr crashes on writing the config

Next https://github.com/hmatuschek/qdmr/commit/6a0ce99344bc6610e01e9639509210aa7fdf2072 - Mar 15, 2023 That is not working, qdmr does not crash, but writes invalid config data

So the last working version is from end of Mar 13 - I will try to zoom in on the commits between Mar 15 and Mar 13, but that is what I could determine for now.

[allesand]

https://github.com/hmatuschek/qdmr/commit/b87b3c860fd87268cda46dc7cc57e99aa1a8c7c0 - Mar 13, 2023- Works - writes config to 878 all ok

https://github.com/hmatuschek/qdmr/commit/32ed33dad3a569d7262da13ec71978ab30a49b9b - Mar 14, 2023 - qdmr crashes on writing the config

https://github.com/hmatuschek/qdmr/commit/f8478cac22f9c857c1753849dfb016702409cb0d - Mar 15, 2023 - does not build

https://github.com/hmatuschek/qdmr/commit/b1f0c054074c9e284d62e87efe890adce4d89a23 - Mar 15, 2023 - crashes on write

https://github.com/hmatuschek/qdmr/commit/6a0ce99344bc6610e01e9639509210aa7fdf2072 - Mar 15, 2023 - qdmr does not crash, but writes invalid config data

[hmatuschek]

Ok, thanks. This helps a lot.

[allesand]

Results for every commit in the mentioned time frame (for those with changes in the code):

https://github.com/hmatuschek/qdmr/commit/b87b3c860fd87268cda46dc7cc57e99aa1a8c7c0 - Mar 13, 2023 - works - writes config to 878 all ok

https://github.com/hmatuschek/qdmr/commit/b8d5a072c3ab5e9d87101e799b41685e25ab4bba - Mar 14, 2023 - works - writes config to 878 all ok

https://github.com/hmatuschek/qdmr/commit/32ed33dad3a569d7262da13ec71978ab30a49b9b - Mar 14, 2023 - crashes on write

https://github.com/hmatuschek/qdmr/commit/f8478cac22f9c857c1753849dfb016702409cb0d - Mar 15, 2023 - does not build

https://github.com/hmatuschek/qdmr/commit/b1f0c054074c9e284d62e87efe890adce4d89a23 - Mar 15, 2023 - crashes on write

https://github.com/hmatuschek/qdmr/commit/0c8cf8b5dcbe92d69826b8655a890af2af20d425 - Mar 15, 2023 - crashes on write

https://github.com/hmatuschek/qdmr/commit/fac9819f6b72a38d013cf351a6f7f6657e3c1f8f - Mar 15, 2023 - writes invalid config

https://github.com/hmatuschek/qdmr/commit/6a0ce99344bc6610e01e9639509210aa7fdf2072 - Mar 15, 2023 - writes invalid config

[allesand]

Ok, thanks. This helps a lot.

Sure,you are welcome. "Zoomed in" above, hope that helps to find out which change causes the invalid config. Both the 868 and the 878 are affected, running 2.40 and 3.01

[allesand]

Side note: as of

https://github.com/hmatuschek/qdmr/commit/c50d36144b3e6f712cb939a19f38fed0060121d6

the user DB write worked very fine, but I just wrote the user DB with the current version of the anytone-branch and got "garbled" output in the user field - empty fields or just a letter or two. I will double-check again in the next days, with above versions everything looks good again.

[hmatuschek]

Fixed in the anytone-settings-extension branch (where else). Turns out, the AnyTone devices do not like empty zones.

[allesand]

Yes! Current anytone-settings-extension is writing a valid config again, thanks! But: the user DB is still broken, as noted in https://github.com/hmatuschek/qdmr/issues/328#issuecomment-1519516146

Changes between https://github.com/hmatuschek/qdmr/commit/c50d36144b3e6f712cb939a19f38fed0060121d6 and now broke the user DB write - after the 16->15 city which is working fine with https://github.com/hmatuschek/qdmr/commit/c50d36144b3e6f712cb939a19f38fed0060121d6 there must have been changes that broke it again, all garbled output right now.

[hmatuschek]

Ok, this was an offset issue in the index of the DB. Should be fixed now. However, I cannot test it right now.

[allesand]

Fixed. Since both issues mentioned in this thread are closed now, issue resolved.