2023-07-31 02:55 AM - last edited on 2023-09-08 09:07 AM by Amel NASRI
Using the STM DFU DLL's to load firmware onto some 3rd party custom hardware, we have to call SelectCurrentConfiguaration becuase the bootloader in the hardware requires this before it allows the STM32F4xx ROM to be written to
Normally this works OK. However users in Turkey have reported Error 1234002 when this call is made , and they are unable to install new firmware.
This problem only seems to affect Windows computers which were installed with the Turkish locale.
Setting the Turkish locale on a English or even German version of Windows, does not cause the problem.
But on PC's with Turkish as the initial / default locale, adding the english locale and switching to that locale to install firmware seems to fix the problem.
Is this a know problem with the DFU DLL's ??
Solved! Go to Solution.
2023-08-08 03:07 AM
Just in case anyone else has this problem.
You need to set the application locale / cultural setting to English / USA . Probably any English cultural configuation would be OK, but US English definitely works
I've no idea why the STM DFU dll gives and error when calling set config when the language is set to Turkish and I don't have time to debug into the dll
2023-08-08 03:07 AM
Just in case anyone else has this problem.
You need to set the application locale / cultural setting to English / USA . Probably any English cultural configuation would be OK, but US English definitely works
I've no idea why the STM DFU dll gives and error when calling set config when the language is set to Turkish and I don't have time to debug into the dll
2023-08-08 05:06 AM - edited 2023-08-08 05:06 AM
The DFU DLLs were part of the package STSW-STM32080, which is now no longer recommended for new designs. The DLL has an error offset called STDFU_ERROR_OFFSET = 0x12340000 and the difference 2 denotes the error STDFU_BADPARAMETER.
Instead of this package, the STM32CubeProg is recommended, where either its CLI or alternatively its CubeProgrammer_API.dll can perhaps replace the DFU DLL in your application.
Hope that helps?
Regards
/Peter
2023-08-08 03:23 PM
Thanks.
Does the CubeProgrammer_API.dll have the same API as the old STDFU.dll and STTubeDevice30.dll
I also don't see any information files related to distribution of the DLL's in the installation files.
Unlike the old version which had STM_License_SLA0044.txt which allows distribution
I doubt it would be economic, for us to rewrite the loader part of our application, as the work-around by setting the locale / cultural settings of the loader thread has fixed the problem.
2023-08-08 04:00 PM - edited 2023-08-08 04:03 PM
Dear @roger239955_stm1 ,
First , thank you very much for giving the smart Workaround to change the Windows locale to English to the original Turkish locale and so fixing the upgrade firmware of your product . As said by @Peter BENSCH we put this famous DFU software utility as NRND - Not recommended for a new design and it is time to get retired even it is very known and some of its features still not yet covered. I wrote this code from scratch in 2002 and all of the DLLs and driver , At that time 32-Bits Flash MCUs and ARM based core do not exist at ST and I was using Microsoft visual Studio 6, I maintained it several times for more recent Microsoft Studio , may be 2015 toolset and upgraded the driver to support Windows 10 and 11 signature , We have as well provided all sources code inside ( GUI , DLLs and command line versions) so our customers can develop and customize , distribue at their own as is . Very pleased to see it still being used after more than 20 years :) and most importantly working in 2023. Thank you again !
Ciao
STOne-32
2023-08-08 04:13 PM
One other thing to note.
After installing the STM32Cube programmer onto my PC, ourfirmware loader feature no longer worked.
The STM32CubeProgrammer installed new DFU drivers which are incompatible with the old STM DFUSe application and DLLs
Luckily I was able to uninstall and delete the new drivers, using the Windows device manager and fortuntunately Windows seems to have reverted back to the drivers it had installed before
I can see however that this could potentialy be a problem for many people, if ST supplies the drivers that are compatible with the CubeProgrammer to Microsoft as the default drivers for devices enumerating with the STM DFU Device VID/PID
USB\VID_0483&PID_DF11\00000000010C
Because this will cause all existing applications that use the old DFUSe dll's to no longer function.