Showing results for 
Search instead for 
Did you mean: 

Corrupted data to write with external loader for NOR Flash S29GL128S and STM32F767

Associate III

Hello everybody,

I come back with a similar issue I've wrote in Issue in buffer to write before programming external flash but with a different memory, now is a NOR flash S29GL128S.

I can read and write any address of external memory properly. Also I can do sector erase and full chip erase. A corruption data to write happens when it tries a program block of 342324 bytes in the external memory. I guess CubeProgrammer splits the block in 2 blocks because Write function is called 2 times, one with 171164 bytes and another with 171160 bytes. In the second time when Write function is called is when I catch a corruption data.






int Write(uint32_t Address, uint32_t Size, uint16_t* Buffer) {
	uint32_t i_write = 0;
	uint32_t word = 0;
	uint16_t data;

	PRINT_HEX_EX("Programming at ", Address);
	PRINT_DEC_EX("Programming size:", Size);

	for (i_write = 0; i_write < Size; i_write += 2) {
		data = Buffer[word];
		// Here is where checks data of some address where threre's corruption
		if (Address == 0x6004EE80) {
		} else if (Address == 0x6004EEA0) {

		HAL_NOR_Program(&hnor1, (uint32_t *) Address, &data);
		if ((HAL_NOR_GetStatus(&hnor1, Address, NOR_DEV_TIMEOUT))
			PRINT_TEXT("Progamming Error!");
			return 0;
		Address += 2;

	PRINT_TEXT("Progamming done!");

	return 1;







The following image is a log generated by the external loader. The lines "0x3401<LF>" and "0xb510<LF>" is the data I was checking to see if there's corruption or not. The correct lines should be "0x0<LF>" 


Removing HAL_NOR_Program from the Write function, there's no corruption data. Also using an old memory compatible with this actual there's no corruption.

Another strange thing is if I use the external loader with the old tool StLink Utility also there's no corruption. The only thing I can see is there is only one call of Write function instead of 2 times in CubeProgrammer. The following image is the log generated by external loader when StLink Utility is used


I don't know where is the problem, if there's wrong in my external loader or there's still some bug in the CubeProgrammer?






@Nawres GHARBI @Aziz BRIGUI 

Does look like an issue sectioning / splitting a file.

Not sure ST-LINK Utilities are going to get reworked, but historically they have processed files slightly differently. STM32 Cube Programmer tends to look at available SRAM, left after loader, and then split it so it can ping-pong between two buffers. This allows for a side loading via SWD/JTAG whilst the loader writes the earlier buffer.

Perhaps needs to be more diagnostics as to buffer sums on the PC side, and on the LOADER side, to allow sanity checking.

Your sanity check method seems reasonable.

Can you try with a linear binary rather than the sparse method (4 byte, then 128 KB offset) you're employing?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Hi Tesla DeLorean

I've made a linear binary starting from 0x60020000 and 342324 bytes to program.



 At the first impression, seems it programs what is expected because both address 0x6004EE80 and 0x6004EEA0 tries program 0x0, which the correct value. 




But if I do a comparison between memory and file there's a lot of regions with a wrong data. The first wrong occurrence was in the address 0x6004C580 but it changed every time I tried to program. Anyway always was when Write function was called in the second time.



There's attached the log generated from CubeProgrammer with verbose 3 to help a more deep diagnostic.

If this is an ST-LINK/V2 make sure not to use a Hub or Docking Station 

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

I use an ST-Link v3 connected in a Docking Station. I've tried connected directly in the laptop but I've got the same result.

Do you suggest to try with an St-link v2? I would order one to test it.

No I wouldn't get a V2, just seen odd issues with them thru hub.

The V3 will want a quality USB 2.0 cable rated to 480 Mbps.

Patterns in the failure would be more indicative of a write page type issue. I would test / validate code throughly in an app

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..