Skip to main content
Graduate II
January 28, 2025
Question

STM32H7R3 PSSI RDY/DE bug

  • January 28, 2025
  • 5 replies
  • 1660 views

Hello,
I dug deeper into PSSI behavior, and and I observed unwanted behavior. From my point of view it is a bug.

PSSI is configured as:
OUTEN = 1 (transmit mode)
CKPOL = 0 (outputs driven on rising edge, inputs sampled on falling edge)
RDYPOL = 0 (0 at input indicates that the receiver is ready to receive)
DEPOL = 0 (0 at output indicates that data is valid)
DERDYCFG = 0b11 (Both PSSI_RDY and PSSI_DE alternate functions enabled)
EDM = 0b00 (Interface captures 8-bit data on every parallel data clock)

Chip STM32H7R3Z8T6, clocked at 600MHz from HSI, placed at PCB, powered by 3.3V
PSSI kernel clocked by 150MHz and 300MHz (PLL from HSI)
Transmitted data is rising numbers from 0 to 15, stored in array in AHBSRAM1, manualy written by core to PSSI->DR as 32bit values (four data bytes at one write). See source code:

while (1){
 if(PSSI->SR & PSSI_SR_RTT4B){ // wait until space in PSSI buffer
 PSSI->DR = arr[idxx]; // place data to buffer
 idxx++; // index to next data
 if(idxx >= BLOCK_SIZE){ // transmit all data again
 LL_GPIO_SetOutputPin(GPIOB, LL_GPIO_PIN_8); // indicate position of "pause"
 delay(420); // delay to simulate data "underrun"
 idxx = 0; // reset array index
 LL_GPIO_ResetOutputPin(GPIOB, LL_GPIO_PIN_8); // indicate position of "pause"
 }
 }
}

 

Input clock to PDCK = 16MHz 
Input pulse to RDY = 25ns, center aligned to PDCK falling edge (valid setup and hold time)

Observations:
When RDY pulse comes one or two clocks before DE deassertion, then PSSI "lost" (transmit with DE deasserted) one data byte. This behavior violates RM.

Citation (32.3.5):
"It is driven by the data source/transmitter in order to indicate that the data is valid to be transferred during the
current cycle. When PSSI_DE is inactive, it means that the data must not be sampled by the receiver at the next clock edge.

If the PSSI_DE alternate output function is enabled (through DERDYCFG) in transmit mode
(OUTEN=1), the PSSI drives PSSI_DE on the same PSSI_PDCK edge that the one used to
drive the data (D[15:0]). If a new 8 or 16-bit data (as programmed in the EDM[1:0] control
bits in PSSI_CR) is available for transmission in the internal FIFO, this data is output on the
data outputs (D[15:0]) and the PSSI_DE output becomes active on the current PSSI_PDCK
edge. Otherwise (if the TX FIFO is empty), the D[15:0] outputs remains unchanged on the
next clock edge and the PSSI_DE output becomes inactive."

first scope trace show valid behaviour.
1. Reciever set RDY, to block one data transfer (0b01)
2. PSSI repeats the same data (0b01) at the next clock cycle and succefuly transmit them
3. PSSI succefuly sends following data (0b10)
4. PSSI succefuly sends following data (0b11)
5. PSSI set DE, indicating that following data should not be read by reciever
6. PSSI clear DE and set data to 0b00 and reciever reads them
From reciever point of view data sequence is valid (0b01->0b10->0b11->0b00), RDY is working, DE is working

Valid situationValid situation

second scope trace show invalid behaviour
1. PSSI transmission of 0b10 is blocked by RDY
2. PSSI transmit the same data 0b10 at the next cycle and data is read by reciever
3. PSSI set DE and also writes next data on bus (0b11) - data is not read by the receiver (violating RM claims - red)
4. PSSI clear DE and writes next data on bus (0b00) - data is read by reciever
From rciever point of view data sequence is invalit (0b10->0b11, missing 0b11)

Invalid behaviourInvalid behaviour

third scope trace show similar invalid behaviour

another invalid behaviouranother invalid behaviour

Placing the RDY pulse on any (falling) edge other than the two mentioned above will not show the problem. Similar bahaviour has been observed during previous test with DMA on another chip with PDCK=60MHz. All observations are fully reproducible.

It is obviously serious problem, because reciever has no chance to recognize when DE needs to be respected and when not.

Could one of the ST employees take a look at it?

Thanks,
Michal Dudka

 

    This topic has been closed for replies.

    5 replies

    Graduate II
    February 5, 2025

    Don't you want to take a look at it? The procedure is simple and the consequences are crucial. In every situation when the receiver delays (using RDY) the transmission one or two clocks before the transmitter "planned" to delay the transmission itself (data underrun), it "loses" a byte. It is not rare, after all, I discovered it myself during practical application ...

    Technical Moderator
    February 6, 2025

    Hello @Michal Dudka,

     

    Thank you for sharing this interesting case. I will check this behavior and I will come back to you with details as soon as possible.

    To check this issue, could you share the project that can be used to reproduce this behavior.

    Do you see any issue when both PSSI_RDY and PSSI_DE alternate functions disabled (PSSI_Transmit)? 

    Internal ticket number: 202499 (This is an internal tracking number and is not accessible or usable by customers).

    Thank you.

    Kaouthar

    Graduate II
    March 3, 2025

    Hi. Did you manage to find out if it's just problem of my program or a bug in PSSI?

    Technical Moderator
    March 3, 2025

    Hello @Michal Dudka,

     

    I reported this issue internally for checking.

    Now, this ticket is under investigation. I'll get back to you as soon as possible.

    Internal ticket number: 202499 (This is an internal tracking number and is not accessible or usable by customers).

     

    Thank you.

    Kaouthar

    Graduate II
    July 13, 2025

    Any news about that issue ? 

    Graduate II
    January 8, 2026

    Hi, has the search for the problem progressed ? Does it make sense to try other STM32 MCUs, or do they have the same PSSI block and i can  expect the same problem?