Issue in buffer to write before programming external flash

[Nickjmas]

Hi everyone,

I've a strange problem when I write to an external flash memory (S29GL512T) throught a STM32F767 MCU and a custom external loader loaded in the STM32CubeProgrammer.

After debugging the external loader several times, I've found that the contents of the buffer that CubeProgrammer gives me for the write operation has partially invalid data. I have done this test in 2 contexts:

• Using FMC to programm external flash. In this context I have invalid data before programming the external flash. 
• Without using FMC. This context is only for check the content of buffer without FMC interfere and the content matches.

So I don't understand why, when you use FMC to program the external flash, the contents of the given buffer are manipulated.

This follows shows the original data I want program at address 0x60060000 and the log generated during the programm procedure.

 

# Sector erase 0
Init...<LF>
S29GL512T11 found!<LF>
Read mode<LF>
Sector erase at 0x0<LF>
Sector erase done!<LF>
 
# Sector erase 1, 2, 3
Init...<LF>
S29GL512T11 found!<LF>
Read mode<LF>
Sector erase at 0x20000<LF>
Sector erase done!<LF>
Sector erase at 0x40000<LF>
Sector erase done!<LF>
Sector erase at 0x60000<LF>
Sector erase done!<LF>
 
# Programm 16 bytes at 0x60000000
Init...<LF>
S29GL512T11 found!<LF>
Programming at 0x60000000<LF>
Programming size:16<LF>
Pointer Buffer 0x20004f00<LF>
 
# Programm 16 bytes at 0x60000000
# I think in this scenario the whole of data to program is loaded in RAM and splitted in 2 consecutive buffers (one with 149044 bytes and the other 149040 bytes). Then I can check a knowed position of this buffer if it matches with a original data (In this case, I use the 0x60060000 addres beacuse never matches with betwen buffer and the original content).
Init...<LF>
S29GL512T11 found!<LF>
Programming at 0x60020000<LF>
Programming size:149044<LF>
Pointer Buffer 0x20004f00<LF>
# Check the content of buffer where represents the content of 0x60060000. Has an invalid data 0x997dccd9b != 0x00000000.
0x20044f00: 0x997dcd9b<LF>
Programming at 0x60044634<LF>
Programming size:149040<LF>
Pointer Buffer 0x20029534<LF>
# Check again the content of buffer where represents the content of 0x60060000. Has an invalid data 0x997dccd9b != 0x00000000.
0x20044f00: 0x997dcd9b<LF>

[Tesla DeLorean]

+256KB is beyond the scope of the passed buffer

[Nickjmas]

Hello,

I've just tryed with the old STM32Utility, loading the same external loader and with this context I haven't any problem to write the desired data. In this case, the write procedure at 0x60020000 is made once time giving the whole of data.

Init...<LF>
S29GL512T11 found!<LF>
 
Read mode<LF>
Sector erase at 0x20000<LF>
Sector erase done!<LF>
Sector erase at 0x40000<LF>
Sector erase done!<LF>
Sector erase at 0x60000<LF>
Sector erase done!<LF>
 
Init...<LF>
S29GL512T11 found!<LF>
Programming at 0x60020000<LF>
Programming size:298084<LF>
Pointer Buffer 0x20004ee4<LF>
# The content matches between buffer and orignial data
0x20044ee4: 0x0<LF>
0x60060000: 0x0<LF>

[Nickjmas]

Hi Tesla DeLoren,

I'm not sure about this, to start write at 0x60020000 the buffer points to 0x200004f00 and have a size of 149044 bytes, and the next block data to write the buffer pointer starts at 0x20029534 (0x200004f00 + 149044 bytes) which seems 2 buffer are consecutive and has all data loaded. See the next log based to see the context of every Write call.

# First write at 0x60020000
Programming at 0x60020000<LF>
Programming size:149044<LF>
Pointer Buffer 0x20004f00<LF>
# Second write at 0x60044634
Programming at 0x60044634<LF>
Programming size:149040<LF>
Pointer Buffer 0x20029534<LF>

Best regards

[Tesla DeLorean]

CM7

Make sure the cache isn't enabled

Don't read the value in the first pass if it is outside the scope of the buffer passed

[Nickjmas]

Hi Tesla DeLorean,

Is disabled both instruction and data cache. Also I have an MPU region dedicated for external nor flash.

static void MPU_Config(void) {
	MPU_Region_InitTypeDef MPU_InitStruct;
 
	/* Disable the MPU */
	HAL_MPU_Disable();
 
	MPU_InitStruct.Enable = MPU_REGION_ENABLE;
	MPU_InitStruct.BaseAddress = 0x60000000;
	MPU_InitStruct.Size = MPU_REGION_SIZE_16MB;
	MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
	MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
	MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
	MPU_InitStruct.IsShareable = MPU_ACCESS_SHAREABLE;
	MPU_InitStruct.Number = MPU_REGION_NUMBER0;
	MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
	MPU_InitStruct.SubRegionDisable = 0x00;
	MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
 
	HAL_MPU_ConfigRegion(&MPU_InitStruct);
 
	/* Enable the MPU */
	HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);
}
 
int Init(void) {
	/* MCU Configuration--------------------------------------------------------*/
	/* MPU config */
	SCB_DisableICache();
	SCB_DisableDCache();
 
	MPU_Config();
 
	/* ... */
 
	return 0;
}

Regards

[Tesla DeLorean]

Whilst I'm not a big fan of the robustness/QA on STM32 Cube Programmer, I have not seen it fail in the manner described, and I've had it writing/verifying 64 and 128 MB test patterns.

How it sub-divides the RAM depends on available size, and that consumed by the external loader, and its stack, etc.Looks a little shy of 20 KB

The block alignment might depend on StorageInfo settings.

This is most current version of the tools? On Windows?

ST-LINK directly connected, and not via hub or dock?

[Nickjmas]

Hi Tesla DeLorean,

I've tested on Windows 10 with the last version v2.11.0 of the tool. Also I've tested with v2.10.0 and 2.6.0. 

The StLink is directly connected to laptop.

I've attached a log file and I've see something suspicious (although I don't understand the meaning of some of the lines):

I understand the following lines is when the cubeprogrammer load data in to the buffer for then call de Write funciton. Every time does the load shows something like this except the last one, whitch differs the RAM address memory where loads. Is it normal?

# First pass, two lines shows the same RAM address

...

16:51:44:595 : Loader write range...

16:51:44:596 : w ap 0 @0x20002BE0 0x00000010 bytes Data 0xFFFFFFFF

16:51:44:596 : W B1 in RAM @0x20002BE0 size 0x00000010 : 0000ms

...

# Second pass, also two lines shows the same RAM address

...

16:51:44:697 : Loader write range...

16:51:45:738 : w ap 0 @0x20002BE0 0x00024634 bytes Data 0x01010101

16:51:45:738 : W B1 in RAM @0x20002BE0 size 0x00024634 : 1041ms

...

# Last one pass, two lines shows diferents RAM address

...

16:51:45:803 : w ap 0 @0x20027214 0x00024630 bytes Data 0x00000000

16:51:45:803 : W B2 in RAM @0x200414E0 size 0x00024630: 0043ms

...

[Tesla DeLorean]

They do try to operate a ping-pong buffer, allowing a background fill of the next section in RAM whilst you perform the write.

[Nickjmas]

It seems look like as you say.

I keep thinking that there's a cache or MPU problem because only happens when I use the FMC peripheral. I was trying with a differents configuration of both MPU and Cache but never achive program the desired data.

It's very strange, this same external loader was used in a old version of this board which had mounted a discontinued memory from the same manufacturer (S29GL128N) without any problem about the content of the buffer to write.

Do you suggest me do some test?

Best regards