STM32U5 hspi fifo

[rdl_42]

Greetings!

I'm working with an STM32U5G9 processor, trying to communicate to a HyperBus psram over the hspi peripheral.  My initial simple test is to try to do an indirect read of the psram 16 bit id register at register space address 0.

I am capturing the HyperBus communication with a logic analyzer and everything looks as expected, except for an extra clock pulse at the end of the transaction.

My problem is that I am not seeing the expected fixed Id register contents when I read the HSPI_DR.  The expected Id register value is seen on the bus with the logic analyzer.  I have dug in enough to understand that the DR read actually pulls from a 64 byte fifo, and that the number of bytes in the fifo are indicated by the contents of HSPI_SR:FLEVEL[0:6].  I have checked the fifo level before initiating a 2 byte HperBus read, and see 0.  I initiate the transfer by writing the HSPI_AR register and immediately after the transfer, FLEVEL indicates 30 bytes in the fifo.

A bit of test code to pull these 30 bytes into a debug array shows 28 bytes of 0, with the expected psram ID value in the last two bytes of the fifo.  I have 7 clocks specified for tacc = initial access latency (STM RM0456 Rev 5, Figure 169).  The psram holds RWDS high to request a second set of 7 latency clocks.  This gives 14 latency clocks, or 28 clock edges.  If I increase the number of latency clocks, the number of extra bytes in the fifo increase correspondingly.

It looks like the hspi in HyperBus indirect mode is receiving data on the latency clock pulses and storing in the DR fifo.  Has anyone else seen this, or been able to get hspi HyperBus indirect register space access to work on the STM32U5G9?

My project and test code are largely generated by CubeMX 6.12.1, using STM32Cube_FW__U5_V1.6.0.

Thanks for any insight that can be offered.

-Rob

[KDJEM.1]

Hello @rdl_42 ,

 

About the FIFO in indirect-write mode, data written to the HSPI_DR register is stored on the FIFO before it is sent to the external device during the data phase. If the FIFO is too full, a write operation is stalled until the FIFO has enough space to accept the amount of data being written.
In indirect-read mode, reading HSPI_DR register gives (via the FIFO) the data that was received from the external device.

If the FIFO does not have as many bytes as requested by the read operation and if BUSY = 1, the read operation is stalled until enough data is present or until the transfer is complete, whichever happens first.

For more information about the FIFO characterization please take a look at RM0456 section FIFO and data management and to this FAQ.  

Could you please check the status DQSE bit of the HSPI_CCR register?

 

Thank you.

Kaouthar

[rdl_42]

Kaothar,

Enabling the DQSM pin took care of the unexpected bytes in the fifo.  I thought I had it enabled, but an incorrectly filled field in the XSPI_HyperbusCmdTypeDef structure that would have been caught if I had "Enable Full Assert" checked in CubeMX caused the issue.  Thanks for that tip.

Now I am seeing 3 pulses of the DQSM signal after the latency time.  This suggests 6 bytes are being read.  I am only requesting 2 bytes and am only seeing two bytes read into the fifo.  Any comment on this?

Thanks,

-Rob

[KDJEM.1]

Hello @rdl_42 ,

 

Thank you for updating post. 

Could you please take a look at these erratas.

 

 

Are you in this case?

Thank you.

Kaouthar