STM32h725 Slave PSSI bad length

[mkhairy]

Hello,

I'm trying to use the PSSI bus in slave mode to transmit data from a small FPGA. After some time chasing a weird bug (I'm losing 8 32bit words at the end of packet) I decided to use a logic analyzer on the bus and it showed a weird behavior from the stm32.

Code configuration:

The code is called in a loop with a flag reset in the transfer callback complete:

if (((USBD_CDC_HandleTypeDef*) hUsbDeviceHS.pClassData)->TxState == 0) {
  if(PSSI_RCV_CPLT) {
    PSSI_RCV_CPLT = 0;
    if (!buf_sel) {
      if(HAL_PSSI_Receive_DMA(&hpssi, (uint32_t*)tbuf , 512)!= HAL_OK) {
       Error_Handler();
      }
      buf_sel = 1;
      if(CDC_Transmit_HS(abuf, 2048) != USBD_OK) {
       uint8_t badusbtiming = 1;
      }
    } else {
      if(HAL_PSSI_Receive_DMA(&hpssi, (uint32_t*)abuf , 512)!= HAL_OK) {
        Error_Handler();
      }
      buf_sel = 0;
      if(CDC_Transmit_HS(tbuf, 2048) != USBD_OK) {
        uint8_t badusbtiming = 1;
      }
    }
   }
 }

Reset of the PSSI complete flag.

void HAL_PSSI_RxCpltCallback(PSSI_HandleTypeDef *hpssi)
{
 PSSI_RCV_CPLT = 1;
}

At the begins of the first valid buffer the USB data and the bus capture are aligned:

 

 But at the end of the first buffer there is a loss of 8*sizeof(uint32_t) => 32 byte.

 

 We can see on the capture that those missing byte are transferred through the bus and dropped and the begins of the next packet align.

 While looking at the full packet length it appears why we have that results. The total valid time of PRDY signal is 83.28us, knowing the clock runs at 25MHz (period of 40ns) it means there are 2082 cycle of PRDY valid, removing the first cycle (where PDE is not asserted) and the last cycle discarded (I repeat this one later) it makes 2080 cycle. If we take an expected length of 2048 cycle and add the 32 missing byte it reaches 2080 cycle.

For now I can lock in FPGA the length to 2048 and hope for the PRDY to go low but it's not a good solution. Maybe I'm doing something wrong, do you have any idea of why this behavior and what I may be doing wrong ?

Thanks a lot,

[mkhairy]

For now I added a workaround allowing me to continue working on this project.

Deasserting data enable doesn't help, PRDY is still enabled no matter what. So I basically send garbage and stale my FIFO as soon as PRDY is asserted for more than 2048 cycle and until next PRDY cycling.

[Tesla DeLorean]

Sure it's not a cache coherency issue?

[mkhairy]

I'm not sure of anything. Is it possible that a cache coherency issue cause the PRDY signal to last 32 cycle more than expected ?

[RhSilicon]

Unfortunately, in the USB Host code, I noticed some difference in the functioning of the STM32H7 HAL code in relation to the functioning of the code for STM32F4. Perhaps the F4 code received more updates that were not implemented in the H7 codes.

I found another possible PSSI-related BUG:

With polling and generating pulses with a gpio I accomplish to receive data but it required to have two adittional clocks before DE get low and one or two pulses after. Another observation is that after transmitting a package the clock polarity change from FALLING to RISING. is the any errata?

https://community.st.com/t5/stm32-mcu-products/parallel-synchronous-slave-interface-pssi-host-to-host-app-note/td-p/260196

I don't know if it helps, but I found this post:

For an example of communication between two STM32H7 devices connected via the PSSI, please see the one included in the STM32CubeH7. The location of the example is:
STM32Cube_FW_H7_Vx.x.x\Projects\NUCLEO-H723ZG\Examples\PSSI\PSSI_Transmit_Receive_DMA

https://community.st.com/t5/stm32-mcus/how-to-configure-and-use-the-pssi-on-the-stm32h7/ta-p/49811

[Pmanauth]

Hello,

On STM32H7A3ZI FW example, you can find the example PSSI_Transmit_Receive_DMA. In this example, we saw that there is a Clean_DCache management. Here is the part of the code of the reception process with the clean:

while(Request_received != 1)
{
if(HAL_PSSI_Receive_DMA(&PSSI_Handle, (uint32_t*)pData8_M_RCV , sizeof(pData8_M_RCV)/4)!= HAL_OK)
{
Error_Handler();
}

while(PSSI_HAL_PSSI_ReceiveComplete_count !=1)
{
/* wait until receiving data is complete */
}

if(Fetch_Slave_Request(pData8_M_RCV) == 1)
{
Request_received = 1;
}
/*
CPU Data Cache maintenance :
It is recommended to clean the CPU Data cache after the DMA transfer.
As the destination buffer may be used by the CPU, this guarantees Up-to-date data when CPU access
to the destination buffer located in the D1 AXI-SRAM (which is cacheable).
*/
SCB_CleanDCache_by_Addr((uint32_t*)pData8_M_TRSMT,sizeof(pData8_M_TRSMT));

HAL_Delay(10);

PSSI_HAL_PSSI_ReceiveComplete_count = 0 ;
}

You can see there is a clean done between each receive transfer:  SCB_CleanDCache_by_Addr((uint32_t*)pData8_M_TRSMT,sizeof(pData8_M_TRSMT));

Hoping this will help.

[tyler-hayslett · Accepted solution]

Hello!

I got bit by this bug too.

Please see my writeup here: https://community.st.com/t5/stm32cubemx-mcus/pssi-read-functions-disable-pssi-which-ruins-backpressure-effect/td-p/596420

The short answer is that the FIFO gets dumped every time the read function is called which looses bytes if you were expecting to use the PSSI signals to backpressure an external interface!

Cheers!

[mkhairy]

Hello,

Thanks for your answer, I came to the same conclusion, and I think I'll ditch this STM32 and do the design with an other chip.

It seems possible to circunvent the problem but adding to the problem I also notice spurious timing problem on the DATA_READY signal coming from the STM32.

Cheers !

[tyler-hayslett]

I also saw weird spurious content on my RDY signal in addition to the FIFO bug!

I stuck a picture of the worst case behavior that I captured. In my case it was due to a weak pullup on the output pin of the ICE40 FPGA I had on the other end of the interface. When the HAL_ library disables the interface and blanks the FIFO, it also releases drive on the IO pin allowing it to float. I solved this by disabling the pullup on the ICE40 output, and enabling a pulldown on the STM32 RDY input.

You can prevent the FIFO bug too, by simply commenting out the "HAL_PSSI_DISABLE(hpssi);" at the top of the read function. Does this fix go away every time you regenerate the code? yes. Should I open a issue against the github for the HAL_ library? probably. Has this allowed me to get rock solid PSSI operation out of my part? Also yes. 

Here's to hoping you don't have to re-design too much!
Best,
Tyler

[mkhairy]

I'm using active low signal but got exactly same weird problem I captured.

On see this one you can see DRDY going crazy and causing the trigger of a DE too early.

In my system I also use an ice40 so I force the pull-up to avoid DRDY being released too early. It fixes a lot but still I have glitches sometime making it unreliable. If you datastream must be stable for long time I suggest you test it deeply because sometime it can run for hours before starting to glitch.

I'll do some more testing, but my confidence in the PSSI bus is really low now.

Thanks a lot,

Cheers.