CubeProgrammer API: Write Memory Error via STLink V3 SET & I2C; no error via USB

[NeoPete]

0

I have a device with an MCU in DFU-mode, and I want to flash new firmware to it. To do that I have the software we have developed at my company to interact with the device, mainly a Wpf-application written in C# and Xaml, which in turn uses the KSociety SharpCubeProgrammer library to make calls to the STM32 CubeProgrammer_API.

If I use the STLink V3 SET hardware over I2C I get a CubeprogrammerErrorWriteMem error (return value -10), i.e. a memory write error, but using the same firmware file but instead directly over USB, i.e. not using the STLink, I get no error and the firmware is updated. In either way the calling code is almost identical, and I have checked that the data and address is the same when calling the API over both I2C and USB. The method called from the API is in either way WriteMemoryAndVerify(...).

I found some information saying that it's the STM32_Programmer_CLI.exe that does the actual reflashing. If that's the case I have a vague idea that I must use the parameter --skiperase which will not erase flash blocks before rewriting them, or when my code grows into the next block. But because the SharpCubeProgrammer wrapper for the STM32 CubeProgrammer_Api I use doesn't include an option for setting that parameter I guess I'll have to do a PInvoke in my code to call the method in the STM32 CubeProgrammer_Api directly. 

Any help or just pointing me in the right direction would be highly appreciated. Thanks!

[Aziz BRIGUI]

Hello @NeoPete

I suggest first trying to download a binary via USB and I2C using only STM32CubeProgrammer CLI (To take the WPF and API parts out of the equation). This is to know if the download issue you're having is tool related. You can refer to the user manual for more details on command syntax.

PS: Please keep in mind that the use case you are performing is not officially supported by the tool.

Aziz

[NeoPete]

Hello Aziz,

Thanks for your reply.

I forgot to mention that I have run the described use case with the STM32CubeProgrammer application in Windows 11 too, and I get kind of the same error, i.e. using the same hardware setup with the STLink and our STM32L5 mcu I connect to it in STM32CubeProgrammer over I2C and everything is "green". I then download the hex-file for the firmware update and click on 'Start Programming' in the STM32CubeProgrammer app. When starting it has 6 segments to flash, and it's when it comes to the 6th, i.e. the last, segment, which is the biggest one, it stops and signals an exception. 

When setting the logging in STM32CubeProgrammer to Verbose level 3 I get the following output when it fails:

Also, when stepping through the C# code in the application we have developed I can see that the error message comes from the ST Api (or of course the SharpCubeProgrammer, but since this is just a wrapper I assume it comes from the ST C-api). 

[Aziz BRIGUI]

Hello @NeoPete

Thanks for your patience on this topic.

After further investigation, we managed to reproduce using STM32CubeProgrammer only. => Turns out this is either a bug in bootloader or STM32CubeProgrammer.

Issue is under investigation by STM32CubeProgrammer development team (Internal tracking number : 206729).

We will get back to you as soon as the issue is fixed.

Aziz

[Robmar]

I'd also like to use WriteMemory, but I can't find any more documentation than the header below, so I don't know what the supported memory format's are.  My hex file has memory changes, main code from teh default 8000000hex onward, but there are other sections that look like data storage at different addresses, so how does a pure binary file handle that, or do I have to read the hex file, split it into sections, and use multiple writeMemory calls with different addresses, which would be a little complicated.

/**
* \brief This routine allows to write memory data on the user interface with the configration already initialized.
* \param address : The address to start writing from.
* \param data : Pointer to the data buffer.
* \param size : It indicates the size for write data.
* \return 0 if the writing operation correctly finished, otherwise an error occurred.
* \warning Unlike ST-LINK interface, the Bootloader interface can access only to some specific memory regions.
*/
int writeMemory(unsigned int address, char* data, unsigned int size);

[Mipoter]

Hello everyone,

I would like to report below my experience with the ST programming APIs, and in particular with the WriteMemory function.

In the past I needed to use the WriteMemory function as the only alternative to the DownloadFile function, to write the entire firmware.

I believe the WriteMemory function was designed to write small amounts of data and in the past, I've had difficulty using this function to download the entire firmware to the microcontroller. Obviously, the firmware must be in .bin format only if we want to use the WriteMemory function.

In some cases, changing the size of the byte array by adding a few bytes so that the total size was divisible by 8 bytes solved the problem.

This seems to be related to what was reported by @NeoPete 

The KSociety SharpCubeProgrammer library is just a wrapper but it is amazing and very useful to use in C# applications.

Looking at the library sources and in particular the WriteMemoryAndVerify function, we can see that the buffer is modified to make it divisible by 8 bytes before calling the WriteMemory function.

So we can say that the WriteMemoryAndVerify function of the SharpCubeProgrammer library is not a call to a function of the official ST API, and in this case it still generates an error during writing or verification.

This post won't solve the problem, but I hope it provides some useful information for the investigation.