2025-05-07 2:01 PM
I'm trying to test writing my own DFU client and I have the simplest of code to start with, see below:
#include <CubeProgrammer_API.h>
int main()
{
dfuDeviceInfo* dfuList = nullptr;
// Enumerate the available DFU devices
int iCount = ::getDfuDeviceList(&dfuList, 0xDF11, 0x0483);
if (iCount != 1)
{
return 0xFFFFFFFF;
}
int iResult;
//#define TRY_VERSION_2
#if defined(TRY_VERSION_2)
dfuConnectParameters params;
params.usb_index = dfuList[0].usbIndex;
params.rdu = 0;
params.tzenreg = 0;
if ((iResult = ::connectDfuBootloader2(/*m_pDFUDeviceUSBIndex*/params)) != 0)
#else
if ((iResult = connectDfuBootloader(dfuList[0].usbIndex)) != 0)
#endif /* TRY_VERSION_2 */
{
::deleteInterfaceList();
return 0xFFFFFFFF;
}
::disconnect();
::deleteInterfaceList();
return 0;
}
connectDfuBootloader and connectDfuBootloader2 always return:
/** Operation not supported or unimplemented on this interface */
CUBEPROGRAMMER_ERROR_NOT_SUPPORTED = -5,
I'm building in VS2022, x64 on Win11. The getDfuDeviceList call succeeds. When using CubeProgrammer itself, I can connect to the device as well as download an ELF file (see this thread here - https://community.st.com/t5/stm32cubeprogrammer-mcus/stm32h7-jump-to-bootloader-not-working/td-p/799726)
Why would the API be failing?
Thanks,
C-Coder
Solved! Go to Solution.
2025-05-13 7:06 AM
Unfortunately, adding these two lines did not change the behavior at all. But, it did spur me enough to run ProcessMonitor to see if maybe a path was wrong. By running ProcessMonitor on the STM32CubePrgAPI example, I was able to determine the correct location of the Data_Base, ExternalLoader, and FlashLoader folders relative to my own test application. Your suggestion of adding those lines would have ended up necessary, the folders being placed one directory too low is what ended up being my issue (so it was a combination of your suggestion and my finding).
Thank you.
2025-05-08 5:47 AM
Additional note: I have tried v2.18 and v2.19. Only x64 as no x86 libs/dlls are being installed.
C-Coder
2025-05-13 1:26 AM
Hello @C-Coder
Apologies for the delayed response.
Could you please add the following lines at the beginning of your code? This is necessary to retrieve the device's database, which might be causing the issue:
const char* loaderPath = "./.";
setLoadersPath(loaderPath);
Additionally, I recommend following the API structure as demonstrated in the provided examples. This typically involves organizing your code into separate .h
and .cpp
files, and making calls in the main
function rather than placing all logic directly within it.
Maryem.
2025-05-13 7:06 AM
Unfortunately, adding these two lines did not change the behavior at all. But, it did spur me enough to run ProcessMonitor to see if maybe a path was wrong. By running ProcessMonitor on the STM32CubePrgAPI example, I was able to determine the correct location of the Data_Base, ExternalLoader, and FlashLoader folders relative to my own test application. Your suggestion of adding those lines would have ended up necessary, the folders being placed one directory too low is what ended up being my issue (so it was a combination of your suggestion and my finding).
Thank you.