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

[Nickjmas]

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;

#if DEBUG
	PRINT_HEX_EX("Programming at ", Address);
	PRINT_DEC_EX("Programming size:", Size);
#endif

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

		HAL_NOR_Program(&hnor1, (uint32_t *) Address, &data);
		if ((HAL_NOR_GetStatus(&hnor1, Address, NOR_DEV_TIMEOUT))
				!= HAL_NOR_STATUS_SUCCESS) {
			HAL_NOR_ReturnToReadMode(&hnor1);
#if DEBUG
			PRINT_TEXT("Progamming Error!");
#endif
			return 0;
		}
		Address += 2;
		word++;
	}

#if DEBUG
	PRINT_TEXT("Progamming done!");
#endif

	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?

[Tesla DeLorean]

@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?

[Nickjmas]

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.

[Tesla DeLorean]

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

[Nickjmas]

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.

[Tesla DeLorean]

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