cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H7R3 PSSI RDY/DE bug

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

 

0 REPLIES 0