Skip to main content
Tesla DeLorean
Guru
October 1, 2019
Question

H7 QUADSPI weirdness

Seen this on two board designs, about two year different in age and many steppings of STM32H7

The H743I-EVAL and H745I-DISCO have 1Gb (128MB) of Micron QSPI flash, one as a dual die single chip, the other as two SOP16

Using the BSP code I can access the parts, both via the Read and Memory Mapped methods.

If it do a bytewise read of the entire array in memory mapped mode the first pass returns the wrong CRC32, and the second one hangs during the next read of a byte at 0x90000000. Stopping execution, it keeps falling in the Systick_Handler, and never reads any memory

If I do half the array, or 128MB - 32 bytes, I get the correct CRC, and can do it multiple times.

...
	status = BSP_QSPI_EnableMemoryMappedMode();
	if (status == QSPI_ERROR)
		puts("QSPI Error");
	else
		puts("QSPI Ok");
	
	printf("%u\n", FlashSize);
	printf("CRC:%08X\n", CRC32(0xFFFFFFFF, FlashSize, (void *)0x90000000)); // Returns wrong sum
	printf("CRC:%08X\n", CRC32(0xFFFFFFFF, FlashSize, (void *)0x90000000)); // Hangs
	printf("CRC:%08X\n", CRC32(0xFFFFFFFF, FlashSize, (void *)0x90000000));
	printf("CRC:%08X\n", CRC32(0xFFFFFFFF, FlashSize, (void *)0x90000000));
	printf("CRC:%08X\n", CRC32(0xFFFFFFFF, FlashSize, (void *)0x90000000));
...
 
//******************************************************************************
 
uint32_t CRC32(uint32_t Crc, uint32_t Size, uint8_t *Buffer)
{
 while(Size--)
 {
 static const uint32_t CrcTable[] = {
 0x00000000,0x1DB71064,0x3B6E20C8,0x26D930AC,0x76DC4190,0x6B6B51F4,0x4DB26158,0x5005713C,
 0xEDB88320,0xF00F9344,0xD6D6A3E8,0xCB61B38C,0x9B64C2B0,0x86D3D2D4,0xA00AE278,0xBDBDF21C };
 
 Crc = Crc ^ (uint32_t)*Buffer++;
 
 Crc = (Crc >> 4) ^ CrcTable[Crc & 0x0F];
 Crc = (Crc >> 4) ^ CrcTable[Crc & 0x0F];
 }
 
 return(Crc);
}
 
//****************************************************************************

It is as if the QUADSPI state machine malfunctions in getting the end bytes, or sends something breaking the Micron parts.

134217696 <-- 32 bytes less

CRC:E741A92C <-- Works

CRC:E741A92C

CRC:E741A92C

CRC:E741A92C

CRC:E741A92C

Infinite loop...

134217697 <--- 31 bytes less

CRC:1F3DC2C7 <- First completes correctly, but then locks

134217728 <-- Whole array

CRC:C3C26772 <- First completes incorrectly, and next pass locks

READ ID (QUAD)

MT25QL 512 (DUAL BANK) / MT25TL01G

UID-0 : 44 00 2E EF 92 00 13 FA FF 26 00 DE A8 FE ED 6C

UID-1 : 44 00 2E EF 92 00 09 12 00 11 00 45 F5 FE 0A B6

 Size 134217728

This topic has been closed for replies.

10 replies

Andreas Bolsch
Lead III
October 1, 2019

That's a well known problem. Don't ever touch the last few bytes (with regard to FSIZE) in memory mapped mode. Or, increase FSIZE field beyond the actual capacity. I'm not quite sure about the reason, but probably the prefetch (which is nowhere specified precisely) interferes with the address decoder in some nasty way. No problem on F4 and F7, though.

Tesla DeLorean
Guru
October 1, 2019

After I had posted, I did expand the size from 128MB to 256MB on QSPI configuration side, which did seem to make it happy, but this is pretty sloppy. Impacts Rev Z thru Rev V, not mentioned in Errata.

Prefetch 32-bytes, empirically. Widening the MPU window has no impact.

@STOne-32​ 

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
Andreas Bolsch
Lead III
October 1, 2019

Yes, no indication in errata sheet ... Except there is a similar problem with OctoSPI in L4+, and there it's mentioned in the corresponding errata sheet.

Amel NASRI
ST Technical Moderator
October 4, 2019

Hello @Community member​ ,

I confirm that there is a limitation to read the last byte of QuadSPI when in memory mapped mode.

This will be described in the STM32H7 errata sheet.

There are still some possible workarounds:

  • double the FSIZE then manage the memory real boundaries by software (I think you tested it already)
  • for CRC check, you can use the indirect mode

Sorry for the inconvenience it creates for you and thanks for bringing it to our attention.

-Amel

To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.
Tesla DeLorean
Guru
October 4, 2019

The oddness extends out to 32-bytes, not sure how that comports with your understanding of the IP or implementation details.

I was using the CRC here as a means to exercise the memory array, I have a version that does the block/command level read. Basically for performance and integrity checking as I'm coding some external loaders.

It is an effective Design-For-Test technique as you don't need to do the byte-for-byte comparison, or hold the whole pattern in memory.

Yes, pushing out FSIZE addresses this. Do you have any data on a full 256MB (2Gbit) implementation? I don't have memory devices that cover that amount of space currently, and I suspect the memories being used might object if the range of their internal addressing was exceeded. I'll perhaps experiment.

@Andreas Bolsch​ I'm assuming you and others have encountered this previously, can you cite and threads/discussion or github commentary?

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
Andreas Bolsch
Lead III
October 5, 2019

That's first mentioned here: http://openocd.zylin.com/#/c/4321/1//COMMIT_MSG as of Jan. 2018.

The "That's a well known problem" might have been slightly exaggerated: It took me several days and numerous and rather frustrating experiments to become convinced it's really a silicon bug and not a software bug ...

Tesla DeLorean
Guru
September 21, 2021

Back referencing this so I can find the threads again later

https://community.st.com/s/question/0D53W000015ZrGUSA0/stm32h7-crashes-when-reading-the-last-bytes-from-a-memorymapped-qspi

2 Years on, @Amel NASRI​ @Andreas Bolsch​ 

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