cancel
Showing results for 
Search instead for 
Did you mean: 

CubeProgrammer_API connectDfuBootloader CUBEPROGRAMMER_ERROR_NOT_SUPPORTED

C-Coder
Associate III

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; }
View more

 

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

1 ACCEPTED SOLUTION

Accepted Solutions
C-Coder
Associate III

@Maryem 

 

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.

View solution in original post

3 REPLIES 3
C-Coder
Associate III

Additional note: I have tried v2.18 and v2.19. Only x64 as no x86 libs/dlls are being installed.

 

C-Coder

Maryem
ST Employee

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.


In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
C-Coder
Associate III

@Maryem 

 

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.