CubeProgrammer API examples not working

[Robmar]

I've just compiled the USB_Example.cpp example and its reporting an initialization error on running (The application could not initialize correctly (0xc000007b)), I have VS 2022 fully updated, I did not migrate the project to the latest toolset to avoid problems.

Any ideas STM team?

 

D:\Program Files (x86)\STMicroelectronics\STM32Cube\STM32CubeProgrammer\api\project\Visual Studio\x64\STM32CubePrgAPI\/../../../../lib/STM32CubePrgAPI.exe (process 25224) exited with code -1073741701 (0xc000007b).
To automatically close the console when debugging stops, enable Tools->Options->Debugging->Automatically close the console when debugging stops.
Press any key to close this window . . .

[Maryem]

Hello @Robmar,

 

The error code you've encountered typically indicates a problem related to the system's architecture compatibility. Projects in Visual Studio targeting x86 (32-bit) should use 32-bit libraries, while x64 (64-bit) projects should use 64-bit libraries. Mixing these can result in errors.
To resolve this, on a system that supports x64, you should use the x64 version of the STM32CubeProgrammer API from the STM32CubeProgramer_win64 directory. Alternatively, if your project is intended for x86, use the corresponding version from the STM32CubeProgramer_win86 directory.
In my tests, using an x86 version of the project from the STM32CubeProgramer_win64 directory on an x64 system caused the same issue. Switching to the x64 version of the project resolved the error. To ensure we're on the same page, could you please check this point ?

 

Maryem.

[Robmar]

Thanks, I just loaded the default .sln project though, and changed nothing.

[Robmar]

Is there a way to get it to remove any ROP protection?

 

Will try "-ob rdp=0x0 BOR_LEV=1"

[Robmar]

Okay so reading the API file notes, I made this change to clear RDP:-

	/* Target connect, choose the adequate USB port by indicating its index that is already mentioned in USB DFU List above */
	//int usbConnectFlag = connectDfuBootloader(dfuList[0].usbIndex);

	// Robmar mod
	dfuConnectParameters params;
	params.usb_index = dfuList[0].usbIndex;
	params.rdu = 1; // 1 == request removal of RDP
	params.tzenreg = 0;
	int usbConnectFlag = connectDfuBootloader2(params);
	if (usbConnectFlag != 0) 

USB speed : Full Speed (12MBit/s)
Manuf. ID : STMicroelectronics
Product ID : DFU in FS Mode
SN : 200364500000
DFU protocol: 1.1
Board : --
Device ID : 0x0450
Warning: Device is under Read Out Protection or Target is held under reset
Device Read Unprotect requested

--- Device Connected ---

So it seems to work now, thanks for your help.

Is there any documentation for the functions that shows all the parameters?

The .chm in the API Docs does not have the info on the params for functions

[Maryem]

The CubeProgrammer_API.h file contains all the necessary details, including function declarations and data structures. Feel free to review it, and I hope it helps!

 

Maryem.

[Robmar]

Hi, are there any examples of programming via the CubeProgrammer from memory?

I've seen in the header there is a writeMemory function:-

int writeMemory(unsigned int address, char* data, unsigned int size);

I've loaded a .hex file into memory, can I use that function to program the MCU, or do I have to use a binary file?  The hex file seems to have address that jump around quite a lot, how's that handled if its a binary file?

I ask because I can't find any documentation more than the basic header.

Thanks

[Robmar]

I had to search for that file on the web as it wasn't in the STM Repository or Program File section.

But it doesn't have all the parameters, look at this one for example, dfuConnectParameters  isn't detailed anywhere in that file.  Is there another source of information?

/**
* \brief This routine allows to start connection to device through USB DFU interface.
* \param dfuConnectParameters : Indicates the dfu connection parameters
* \return 0 if the connection successfully established, otherwise an error occurred.
* \note It's recommanded to use this routine to disable readout protection when connecting a MCU based device.
*/
int connectDfuBootloader2(dfuConnectParameters dfuParameters);

[C-Coder]

@Robmar if you install CubeProgrammer, on a 64 bit machine, the file should be located in:

 

C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\api\include

 

and you should see:

/**
 * \struct dfuConnectParameters
 * \brief Specify the USB DFU connect parameters.
 */
typedef struct dfuConnectParameters
{
 char *usb_index;
 char rdu; /**< request a read unprotect: value in {0,1}.*/
 char tzenreg; /**< request a TZEN regression: value in {0,1}.*/
}dfuConnectParameters;

 

as well as:

 

/**
 * \brief This routine allows to start connection to device through USB DFU interface.
 * \param dfuConnectParameters : Indicates the dfu connection parameters
 * \return 0 if the connection successfully established, otherwise an error occurred.
 * \note It's recommanded to use this routine to disable readout protection when connecting a MCU based device.
 */
int connectDfuBootloader2(dfuConnectParameters dfuParameters);

 

C-Coder

[Robmar]

I downloaded CubeProgrammer from STM's page, and it installed the x86 and 64-bit files on my 64-bit laptop in the x86 Program Files directory which I also thought odd.

And yes, sure I see the same structure, whoopee!  But there are no details on what values do what, which is pretty useless, no?

 

[C-Coder]

Robmar,

 

Simple searching quickly finds what you're looking for. Regarding the rdu, checkout what RDP is here:

 

https://www.st.com/resource/en/product_training/STM32F7_Security_Memories_Protections.pdf

 

It's reasonable to assume that the same principles are carried across all of the STM32 products that contain RDP. For the tzenreg parameter, see this:

 

https://community.st.com/t5/stm32-mcus-products/what-does-tzen-really-do/td-p/716196

 

C-Coder

[Robmar]

Okay, got it, the Data_Base folder has to be one up from the dll folder with the example .exe, with ExternalLoader and FlashLoader folder in the same director as the exe.

Some documentation from STM would mean we wouldn't have to dig through everything to know the required structure, just a thought!