STM32U5 with MX25R6435F is madness ?

[Bertha]

Hi,

This is driving me crazy, let me explain.

Setup : NucleoU575 with MX25R6435F in QSPI with wire jumper cables.

Here's a code adapted from an ST example for the stm32l496g_discovery.

The modifications were minor, and we simplified it to the maximum, just:

1. Set a row of strings.
2. Erase the sector.
3. Write the row to this sector.
4. Read back the memory.

If I keep the initial row:

uint8_t aTxBuffer[] = "QSPI communication based on DMA QSPI communication based on DMA QSPI communication based on DMA QSPI communication based on DMA QSPI communication based on DMA QSPI communication based on DMA";

This works as expected, even when I play with it by changing random letters, and the test is consistent and can be repeated several times with no errors.

The madness starts here: if I replace it (and that's the only modification) with another row string like this one:

uint8_t aTxBuffer[] = "This is a test let's try it";

Now, the readbacks are incomplete and inconsistent (stop randomly before), even though the second row is smaller.

By the way, I checked the status, config, and secured registers, and everything is fine there.

Any suggestions or ideas?

Thanks

[Bertha]

Here's an update:

So I tried a new chip (in case the previous one was somehow damaged), but the results are the same. Therefore, it's not due to the chip.

My initial suspicion was that the erase phase was incorrect. I replaced it with an "erase_chip()" function, but it took a long time and the results remained the same.

To investigate the erase phase further, I added a read operation just after to check if I get 0xFF values. Here's the first surprise: that's not the case (See attached image A). I can only read about 12 values, and they're all equal to 136? Even more surprising is that the write and next read kind of work on those addresses marked as 136 (See attached image B), which is weird...

A:

 B:
This suggests an error in the erase phase, but then came the funny part:

I tried the working row again, using the same process. After the erase, the read operation gave me similar results (See attached image C), but after writing and reading back, I have all the data (See attached image D, trust me, all the rows are complete and correct). This makes no sense to me, as it indicates that the erase is working correctly.

C:

 D:
I am running out of ideas here.

Any suggestions, maybe?

[Pavel A.]

Your prototype, STM32L496G has QSPI. But STM32U5 has OctoSPI. Check your code adaptation.

Especially check polling for completion of operations.

[Bertha]

Thanks, Pavel A., for taking the time to review the issue.

You are absolutely right, the OSPI HAL polling function for U5 is different from QSPI from L4. However, I did consider this point while adapting the code.

In my case, the polling seems to be working fine. I connected a logic analyzer and observed that during erase, the status register is periodically read, and the process stops when it matches the required value (WIP = 0).

I have attached some screenshots from the logic analyzer, and everything appears to be as expected, except during read and write operations.

Here's a new test I conducted:

I initially wrote the following line:

uint8_t aTxBuffer[] = " ****QSPI communication based on DMA****  ****QSPI communication based on DMA****  ****QSPI communication based on DMA**** ****QSPI communication based on DMA**** ****QSPI communication based on DMA**** ****DAXI communication based on DMA**** ";

As always, it worked perfectly. However, when I commented it out and used the following line instead:

uint8_t aTxBuffer[] = " This is a test let's try it ";

And here the code :

  BSP_QSPI_Init();
  BSP_QSPI_Erase_Block(0);
//  BSP_QSPI_Erase_Chip();
  BSP_QSPI_GetStatus();
  BSP_QSPI_Read(aRxBuffer, 0, BUFFERSIZE);
  BSP_QSPI_Write(aTxBuffer,0,BUFFERSIZE);
  BSP_QSPI_Read(aRxBuffer, 0, BUFFERSIZE);
  BSP_QSPI_Read(aRxBuffer_2, 0, BUFFERSIZE+20);

I wanted to see the contents of the buffersize and the +20 part.

I expected it to be part of the previous row or filled with 0xFF due to the erase block function.

But the result I obtained was unexpected: I only got 0x00 values.

It seems that the erase function is setting 0x00 instead of 0xFF.

However, I'm still puzzled as to why it works with the first row (even with slight modifications).

By the way, all GPIOs are set to no pull-up or pull-down, except for the CS pin, which is pulled up, and status - config and secured register are all good (no block protected).

Best regards,

[S.Ma]

Have you checked out the errata sheet in case ?

[Pavel A.]

Hmm. I don't have MX25R64. Can it be kind of reading out of internal page buffer rather than from the memory?

Try to test with sector != 0 and offset != 0.

[Bertha]

Dear S.Ma,

Thank you for the advice. Yes, I followed it, and there was no mention of this on the OSPI part. This is a valuable tip to always check this file. In some cases, I have wasted a lot of time by not reading it.

Regards

[Bertha]

Hi Pavel,

Good idea, so I tested with sector != 0 and offset != 0.

I performed the test using the address 0x21005. Surprisingly, I obtained the exact same results with the same issue occurring. The small row of data is not working while the larger one is working again. I can assure you that I have never written to that specific address before, and I started with the smaller row.

It's puzzling because it seems like we may need to use align(X) or write to more than one page for it to work. However, this doesn't make sense either since a page is 256B and my row is only 248B, and it works with offset = 0.

By the way, I also noticed something strange with Erase_block. If I increase the block value, the HAL_OSPI_Command returns an error, but it works just fine with a smaller value. I need to debug further and investigate all these points. I will keep you updated, in the mean time if someone else has any suggestion I am all listening. 

[Bertha · Accepted solution]

Dear ST Forum Members,

I wanted to share an experience some of you might find helpful:

Initially, everything seemed fine with the code, but we encountered an issue that we traced back to the jumper cables. They were either too long or of subpar quality. After a quick replacement, everything is now working seamlessly.

Big shout-out to the ST and Macronix support teams for their thorough investigation and assistance in pinpointing the issue.

Cheers,

[Pavel A.]

Ah, jumper cables! Sure enough. This is pain (( Thank you for sharing your solution.