why this error? 12340002

[VK3KYY]

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.

There are 3 layers for how this works. The Application (CPS or firmware loader), the Dynamic Link Libraries provided by STM to interface to the driver and the driver installed by Windows (which is also from STM)

As the Baofeng loader includes the DLL files, then the Baofeng loader probably uses them to interface to the driver.

If I have time I may try setting one of my PC's to Turkish language and see which DLL API call is failing, but it would be very difficult to go much further.

STM provide the source code to their DLL's, so in theory it would be possible to debug inside the DLL to understand why their are causing an 'exception'

But this would take many hours of work, and I have a lot of other things I need to do related to the firmware and CPS.

And it seems that the problem with the Turkish language can be fixed by simply switching the PC language to English when using the firmware loader in the CPS.

Actually, there may be a workaround by the CPS changing the language paramaters under which it runs

e.g.

Code: Select all

System.Globalization.CultureInfo ci = new System.Globalization.CultureInfo("en-US");
System.Threading.Thread.CurrentThread.CurrentCulture = ci;

[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

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.

Can you download and try the version

https://opengd77.com/downloads/CPS/Expe ... -en-US.exe


I set the thread for the loader to "en-US".

However, I also tried setting the thread locale to turkish and the firmware still loaded onto my UV380, so I am not confident that simply changing the thread locale in the application will fix this

[G4EML]

I also tried changing to Turkish from UK English and the loader still worked for me, so there is more to it than simply changing the locale. Something about the initial install must also be involved.

Colin.

[VK3KYY]

I also tried changing to Turkish from UK English and the loader still worked for me, so there is more to it than simply changing the locale. Something about the initial install must also be involved.

Colin.

OK. Thanks.

[SA0BUX]

I also tried changing to Turkish from UK English and the loader still worked for me, so there is more to it than simply changing the locale. Something about the initial install must also be involved.

Colin.

Same here when I just tested changing to Turkish with intl.cpl , but this laptop is installed with US English Windows from the beginning.

Maybe I will test changing system locale later but that needs a reboot.

I will test the other CPS on the Turkish PC soon.

[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.

Can you download and try the version

https://opengd77.com/downloads/CPS/Expe ... -en-US.exe


I set the thread for the loader to "en-US".

However, I also tried setting the thread locale to turkish and the firmware still loaded onto my UV380, so I am not confident that simply changing the thread locale in the application will fix this

I have tested the experimental compile now and it works, but I have to repeat the upload twice.
First time it gives the error code but if I open the bin file once more it uploads the file and successfully load a new flash.

Tried the same procedure with the standard CPS but there it fails everytime.

So I think you are on the right track to fix this.

[F1RMB]

Hi,

Since I was able to reproduce the problem using a Win10 in a VM (set to Turkish only), it was able to tweak Roger's fix to make it working on the first run.


Cheers.
---
Daniel

[VK3KYY]

I have tested the experimental compile now and it works, but I have to repeat the upload twice.
First time it gives the error code but if I open the bin file once more it uploads the file and successfully load a new flash.

Tried the same procedure with the standard CPS but there it fails everytime.

So I think you are on the right track to fix this.

Try this version

https://opengd77.com/downloads/CPS/Late ... .01.01.exe

I made a mistake in my last version so that the change didn't immediatly take effect

[SA0BUX]

I have tested the experimental compile now and it works, but I have to repeat the upload twice.
First time it gives the error code but if I open the bin file once more it uploads the file and successfully load a new flash.

Tried the same procedure with the standard CPS but there it fails everytime.

So I think you are on the right track to fix this.

Try this version

https://opengd77.com/downloads/CPS/Late ... .01.01.exe

I made a mistake in my last version so that the change didn't immediatly take effect

Works without a hitch when flashing.

[VK3KYY]

Thanks

We need some of the people who originally reported the bug to try this version

Anyone else who had a problem , even non Turkish users , should also try it