STM32H7 Hyperram Write sequence not correct

[niklasdiehm]

Dear ST-community,

im Niklas Diehm and currently working on a student project, developing a Formula Student racecar. This year, we want to build a new dashboard for the driver. Therefore, we want to use a STM32H725ZGT6 with an external Hyperram S70KL1282.

For testing, we connected a Nucleo-H723 to our self-developed PCB-Shield and tried sending read and write operations. We generated the HAL-Abstraction using CubeMX and for logic we are using the provided BSP-Code from here.

The commands are not failing (HAL_OK), but the Write-Operations are not working. Below you can see two images of scopes from an oscilloscope. The yellow line is the clock signal, the green RWDS. The read operation looks as described in the Hyperbus-Protocol (Command Frame, then 2x initial delay, then RWDS aligned with clock signal). The write operation however stops after the 2x initial delay. Can you find the error here?

Read-Operation:

Read operation

Write-Operation:

Write operation

Attached you find our CubeMX configuration.

If you need any more information, please let me know.

The code looks like this (only the relevant parts):

uint8_t dataWrite16 = 0xAAAA;
uint32_t ramAddress = 0x00000020;
uint8_t errorCode;
errorCode = S70KL1281_Write(&hospi1, &dataWrite16, ramAddress, 16);

The function S70KL1281_Write is defined as the following:

int32_t S70KL1281_Write(OSPI_HandleTypeDef *Ctx, uint8_t *pData, uint32_t WriteAddr, uint32_t Size)
{
OSPI_HyperbusCmdTypeDef sCommand;

 /* Initialize the write command */
sCommand.AddressSpace = HAL_OSPI_MEMORY_ADDRESS_SPACE;
sCommand.AddressSize = HAL_OSPI_ADDRESS_32_BITS;
sCommand.Address = WriteAddr;
sCommand.DQSMode = HAL_OSPI_DQS_DISABLE;
sCommand.NbData = Size;

 /* Configure the command */
if (HAL_OSPI_HyperbusCmd(Ctx, &sCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
return S70KL1281_ERROR;
}
 /* Transmission of the data */
if (HAL_OSPI_Transmit(Ctx, pData, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
return S70KL1281_ERROR;
}
return S70KL1281_OK;
}

[KDJEM.1]

Hello @niklasdiehm and welcome to the Community 🙂,

Could you please check  the Hyperbus configuration and precisely the initial latency.

For that I advise you to refer to OSPI_HyperRAM_MemoryMapped example and check the OCTOSPI configuration.

This example describes how to write and read data in memory-mapped mode in the OCTOSPI HyperRAM memory and compare the result with an intensive access. The HyperRAM memory is an S70KL1281 memory.

I hope this help you!

Thank you.

Kaouthar

[niklasdiehm]

Hello Kaouthar @KDJEM.1 ,

Thank you for your response!

I checked the Hyperbus configuration to meet the described one in the linked article. The only change I made is the set the hardware access time / initial latency to 7 because of this document. The authors state that when changing from S70KL1281 to S70KL1282 you must set the initial latency from 6 to 7.

Do you have another idea of what the problem is here?

[LCE]

What's the speed it's running at?

Have you checked that all the signals have (at least roundabout) same length, including the data line length on the Nucleo (which is terribly routed, because it's a multi-purpose board...)?

Have you tried using memory mapped mode?

I have only used the H735 discovery with the old S70KL1281, but in a few weeks I'll have my custom board with the S70KL1282. And I expect it to work as well as the 1281...

[KDJEM.1]

Hello @niklasdiehm,

Thank you for updating post.

Could you please try to decrease the OCTOSPI frequency?

Thank you.

Kaouthar

[niklasdiehm]

We are running the Hyperram at 20 MHz for testing. For testing we created a Shield for the Nucleo and not really cared about the trace lengths. Do you think this could cause the problem? The strange thing is that the read operations seem perfectly fine.

Using memory mapped mode is not working too, reading seems fine (I cant prove the outcome because of the not working write operations), but writing statements are looking as captured above

[niklasdiehm]

Hello Kaouthar,

we decreased the frequency from nearly 100 MHz to 20 MHz. Changing to a even lower frequency (e.g. 1MHz) doesn´t solve the problem too.

[LCE]

At 20 MHz trace length is probably not an issue.

At 100 MHz with the double data rate it might get problematic if length difference is really big (which it already is on the Nucleo, AFAIK, so check your board if that makes it worse).

Rule of thumb for propagation delay for PCB traces: 6 ps / mm

Conclusion: for now, keep testing at 20 MHz

GPIOs: have you double checked all pins and alternate functions?

OCTOSPI setup:

read and write have individual DQS = RWDS enables, so check this register for the DQSE bit:

/* WRITE: WCCR */
OCTOSPI1->WCCR = OCTOSPI_CCR_DQSE ...

[KDJEM.1]

Hi @niklasdiehm ,

Could you please check the DQSE bit of the OCTOSPI_WCCR because in memory-mapped write you can get an error response when DQS output is disabled.

Workaround

When doing memory-mapped writes, set the DQSE bit of the OCTOSPI_WCCR register, even for memories that
have no DQS pin.
If the DQS output is asserted on memory-mapped writes while the AXI bus transfer has some byte-enable bits
deasserted, the bytes that should be masked get written to the memory.

For more information, I advise you to take a look to the errata sheet section "2.7.6 Memory-mapped write error response when DQS output is disabled".

I hope this help you.

Kaouthar

[LCE]

@KDJEM.1 

I'm pretty sure that the S70KL1282's RWDS pin is the same as the DQS signal, so it must be connected and used for both read and write. And it would be a HAL or Cube error if it would not do that.

@niklasdiehm 

So, as I already said, check DQSE in WCCR.

Please post your HyperRam init.

Another thing: check the mode you're in, I think in memory-mapped mode you cannot trigger other write actions and vice versa.

PS:

sCommand.DQSMode = HAL_OSPI_DQS_DISABLE;

just saw that, that kills write DQS...