why this error? 12340002

[OE1MWW]

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]

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]

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]

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]

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]

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]

Ok thanks

[SA0BUX]

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]

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]

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.