STM32U5 with MX25R6435F is madness ?

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?

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,