-
OE1MWW
- Posts: 106
- Joined: Sat Oct 17, 2020 2:20 pm
- Location: JN88EG
-
Contact:
Post
by OE1MWW » Sat Jul 29, 2023 7:05 am
VK3KYY wrote: ↑Sat Jul 29, 2023 6:48 am
Thanks.
Did you test before you installed that antivirus
If I get time I may try adding Turkish as a language to my PC, which is installed as US English
Roger, you don't need to add the Turkish language. Just open a command window, execute 'intl.cpl'
and select the Turkish settings on top and click on the bottom right to set it.
On my workbench Windows 7 machine - if I set to Turkish, I see the error '12340014 ...' for firmware update/load.
If I revert to german (Austria) all is good.
Seems that STM does not like some of the date/time/currency settings in Windows by using that language.
-
VK3KYY
- Posts: 7605
- Joined: Sat Nov 16, 2019 3:25 am
- Location: Melbourne, Australia
Post
by VK3KYY » Sat Jul 29, 2023 7:10 am
OE1MWW wrote: ↑Sat Jul 29, 2023 7:05 am
Seems that STM does not like some of the date/time/currency settings in Windows by using that language.
This could be true, but again I don't think we can do anything about this.
It seems like its a bug in the STM DFU interface DLLs
Probably Turkish developer who program the STM32 may not notice this bug, becuase the bootloader in the radio requires an extra DFU command to be sent to the radio.
Possibly normal STM DFU clients don't need this extra command.
But this is a requirement of the bootloader and its not possible to change the bootloader
-
SA0BUX
- Posts: 605
- Joined: Tue Jul 05, 2022 8:50 am
- Location: JO99ah, Stockholm, Sweden
-
Contact:
Post
by SA0BUX » Sat Jul 29, 2023 7:19 am
OE1MWW wrote: ↑Sat Jul 29, 2023 7:05 am
VK3KYY wrote: ↑Sat Jul 29, 2023 6:48 am
Thanks.
Did you test before you installed that antivirus
If I get time I may try adding Turkish as a language to my PC, which is installed as US English
Roger, you don't need to add the Turkish language. Just open a command window, execute 'intl.cpl'
and select the Turkish settings on top and click on the bottom right to set it.
On my workbench Windows 7 machine - if I set to Turkish, I see the error '12340014 ...' for firmware update/load.
If I revert to german (Austria) all is good.
Seems that STM does not like some of the date/time/currency settings in Windows by using that language.
Good, seems that you have narrowed the cause then.
I will try that too on another Windows machine.
-
SA0BUX
- Posts: 605
- Joined: Tue Jul 05, 2022 8:50 am
- Location: JO99ah, Stockholm, Sweden
-
Contact:
Post
by SA0BUX » Sat Jul 29, 2023 3:28 pm
I uninstalled the eset antivirus package but that made no difference and as we know now it's related to language settings.
Then I used intl.cpl and only changed to "US English" in the Turkish Windows installation and then you could flash the radio.
Next step for me is to test the Baofeng software.
(I'm pretty sure that it will work)
-
VK3KYY
- Posts: 7605
- Joined: Sat Nov 16, 2019 3:25 am
- Location: Melbourne, Australia
Post
by VK3KYY » Sat Jul 29, 2023 8:52 pm
SA0BUX wrote: ↑Sat Jul 29, 2023 3:28 pm
I uninstalled the eset antivirus package but that made no difference and as we know now it's related to language settings.
Then I used intl.cpl and only changed to "US English" in the Turkish Windows installation and then you could flash the radio.
Next step for me is to test the Baofeng software.
(I'm pretty sure that it will work)
Ok. Thanks
Btw. Can you compare the STM DFU dll s in the Baofeng firmware loader, with the ones in the OpenGD77 CPS. Perhaps they use modified dll s
-
SA0BUX
- Posts: 605
- Joined: Tue Jul 05, 2022 8:50 am
- Location: JO99ah, Stockholm, Sweden
-
Contact:
Post
by SA0BUX » Sun Jul 30, 2023 12:52 pm
VK3KYY wrote: ↑Sat Jul 29, 2023 8:52 pm
SA0BUX wrote: ↑Sat Jul 29, 2023 3:28 pm
I uninstalled the eset antivirus package but that made no difference and as we know now it's related to language settings.
Then I used intl.cpl and only changed to "US English" in the Turkish Windows installation and then you could flash the radio.
Next step for me is to test the Baofeng software.
(I'm pretty sure that it will work)
Ok. Thanks
Btw. Can you compare the STM DFU dll s in the Baofeng firmware loader, with the ones in the OpenGD77 CPS. Perhaps they use modified dll s
More tests:
1. flashed to factory software with Baofeng flasher , works without any glitch with turkish language settings.
2. The DFU system driver that I use is version 3.0.9 and Baofeng DLLs is version 3.0.1 , I replaced the user DLLs in OpenGD77 with the ones from the Baofeng package , but OpenGD77 flash failed.
3. I have some USB captures that I will look into and I will post a link to the PCAP files.
-
VK3KYY
- Posts: 7605
- Joined: Sat Nov 16, 2019 3:25 am
- Location: Melbourne, Australia
Post
by VK3KYY » Sun Jul 30, 2023 9:25 pm
Ok thanks
-
SA0BUX
- Posts: 605
- Joined: Tue Jul 05, 2022 8:50 am
- Location: JO99ah, Stockholm, Sweden
-
Contact:
Post
by SA0BUX » Sun Jul 30, 2023 9:52 pm
VK3KYY wrote: ↑Sun Jul 30, 2023 9:25 pm
Ok thanks
I put them here , but I don't think it will give any hints, the setup for transfer of the flash file stop very early and it seems that it never go out
on the USB interface.
Have never looked on USB communication before but it seems that te device ID's varies even if I used the port for all three captures.
Three PCAP files , one for Baofeng flash that worked and two for OpenGD77 flash, one working and one failed.
https://www.sa0bux.se/Ham/opengd77/
-
VK3KYY
- Posts: 7605
- Joined: Sat Nov 16, 2019 3:25 am
- Location: Melbourne, Australia
Post
by VK3KYY » Sun Jul 30, 2023 11:32 pm
OK. Looking at the packet capture probably won't help much, becuase its the communication between the Loader application and the DLL's that will be different.
I don't know a way to monitor what calls with what parameters are made to a dll
Fake DLLs would need to be written which write the command and parameters to a debug file, and then call the reall DLL, but this is very complex
Possibly one of the expensive hacking tools can look at the internals of an application as it runs, but all I have is Ghidra and AFIK it does not have that level of functionality
Possibly the Baofeng loader could be dissassembled by Ghidra and the DLL calls analysed, but I've never used Ghidra for a PC application, I only used it for firmware analysis
-
SA0BUX
- Posts: 605
- Joined: Tue Jul 05, 2022 8:50 am
- Location: JO99ah, Stockholm, Sweden
-
Contact:
Post
by SA0BUX » Mon Jul 31, 2023 4:31 am
VK3KYY wrote: ↑Sun Jul 30, 2023 11:32 pm
OK. Looking at the packet capture probably won't help much, becuase its the communication between the Loader application and the DLL's that will be different.
I don't know a way to monitor what calls with what parameters are made to a dll
Fake DLLs would need to be written which write the command and parameters to a debug file, and then call the reall DLL, but this is very complex
Possibly one of the expensive hacking tools can look at the internals of an application as it runs, but all I have is Ghidra and AFIK it does not have that level of functionality
Possibly the Baofeng loader could be dissassembled by Ghidra and the DLL calls analysed, but I've never used Ghidra for a PC application, I only used it for firmware analysis
Neither I have any knowledge about windows (driver) debugging, I did some debugging inside Solaris years ago.
But It's positive that we now know when this error occur and how to workaround it.
I never had any thought that such locale settings could affect this.