Problem configuring OCTOSPI on STM32H735 - writes going to the wrong location

[Rlamkin]

We have been using the STM32H735G-DK eval board for a while with no issues with the STM OCTOSPI interface which is connected to a S70KL1281DABHI023

When switching to our target we had to change to using a S27KS0642GABHI020 HyperBus RAM device.

We have been unsuccessful configuring the STM interface to allow valid communications with the HyperBus RAM and would really welcome some assistance.

  The effect seen is that;

• write any value to the HyperBus RAM at address 0x04
• Read back 0x04and it reports 0x00
• However using uVision "memory watch" the data written to 0x4 is now read back from address 0x00
• We can repeat this for 0x5,06,07  and these read back in 0x1, 2, 3 respectively
• write to 0x08,  and the data disappears completely.
• write to 0xC and it appears in 0x08.
• And repeat through the memory. 

This is the output of the write/read test for addresses 0x00 to 0x1f is shown below.

write h base=70000000 Base[0x0] w=0x00
write h base=70000000 Base[0x1] w=0x01
write h base=70000000 Base[0x2] w=0x02
write h base=70000000 Base[0x3] w=0x03
write h base=70000000 Base[0x4] w=0x04
write h base=70000000 Base[0x5] w=0x05
write h base=70000000 Base[0x6] w=0x06
write h base=70000000 Base[0x7] w=0x07
write h base=70000000 Base[0x8] w=0x08
write h base=70000000 Base[0x9] w=0x09
write h base=70000000 Base[0xa] w=0x0a
write h base=70000000 Base[0xb] w=0x0b
write h base=70000000 Base[0xc] w=0x0c
write h base=70000000 Base[0xd] w=0x0d
write h base=70000000 Base[0xe] w=0x0e
write h base=70000000 Base[0xf] w=0x0f
write h base=70000000 Base[0x10] w=0x10
write h base=70000000 Base[0x11] w=0x11
write h base=70000000 Base[0x12] w=0x12
write h base=70000000 Base[0x13] w=0x13
write h base=70000000 Base[0x14] w=0x14
write h base=70000000 Base[0x15] w=0x15
write h base=70000000 Base[0x16] w=0x16
write h base=70000000 Base[0x17] w=0x17
write h base=70000000 Base[0x18] w=0x18
write h base=70000000 Base[0x19] w=0x19
write h base=70000000 Base[0x1a] w=0x1a
write h base=70000000 Base[0x1b] w=0x1b
write h base=70000000 Base[0x1c] w=0x1c
write h base=70000000 Base[0x1d] w=0x1d
write h base=70000000 Base[0x1e] w=0x1e
write h base=70000000 Base[0x1f] w=0x1f

read h base=70000000 Base[0x0] r=0x04 =! w=0x 0
read h base=70000000 Base[0x1] r=0x05 =! w=0x 1
read h base=70000000 Base[0x2] r=0x06 =! w=0x 2
read h base=70000000 Base[0x3] r=0x07 =! w=0x 3
read h base=70000000 Base[0x4] r=0x00 =! w=0x 4
read h base=70000000 Base[0x5] r=0x00 =! w=0x 5
read h base=70000000 Base[0x6] r=0x00 =! w=0x 6
read h base=70000000 Base[0x7] r=0x00 =! w=0x 7
read h base=70000000 Base[0x8] r=0x0c =! w=0x 8
read h base=70000000 Base[0x9] r=0x0d =! w=0x 9
read h base=70000000 Base[0xa] r=0x0e =! w=0x a
read h base=70000000 Base[0xb] r=0x0f =! w=0x b
read h base=70000000 Base[0xc] r=0x00 =! w=0x c
read h base=70000000 Base[0xd] r=0x00 =! w=0x d
read h base=70000000 Base[0xe] r=0x00 =! w=0x e
read h base=70000000 Base[0xf] r=0x00 =! w=0x f
read h base=70000000 Base[0x10] r=0x14 =! w=0x10
read h base=70000000 Base[0x11] r=0x15 =! w=0x11
read h base=70000000 Base[0x12] r=0x16 =! w=0x12
read h base=70000000 Base[0x13] r=0x17 =! w=0x13
read h base=70000000 Base[0x14] r=0x00 =! w=0x14
read h base=70000000 Base[0x15] r=0x00 =! w=0x15
read h base=70000000 Base[0x16] r=0x00 =! w=0x16
read h base=70000000 Base[0x17] r=0x00 =! w=0x17
read h base=70000000 Base[0x18] r=0x1c =! w=0x18
read h base=70000000 Base[0x19] r=0x1d =! w=0x19
read h base=70000000 Base[0x1a] r=0x1e =! w=0x1a
read h base=70000000 Base[0x1b] r=0x1f =! w=0x1b
read h base=70000000 Base[0x1c] r=0x00 =! w=0x1c
read h base=70000000 Base[0x1d] r=0x00 =! w=0x1d
read h base=70000000 Base[0x1e] r=0x00 =! w=0x1e
read h base=70000000 Base[0x1f] r=0x00 =! w=0x1f

The main OCTOSPI settings are

#define OCTOSPI_DEVICE_SIZE 23
#define OCTOSPI_FIFO_THRESHOLD 4
#define OCTOSPI_FIFO_CLOCK_PRESCALER 4
#define OCTOSPI_CHIP_SELECT_HIGH_TIME 8
#define OCTOSPI_TRANSFER_RATE 250
#define OCTOSPI_HYPERRAM_RW_RECOVERY 3
#define OCTOSPI_MAX_TRANSFER 0
#define OCTOSPI_HYPERRAM_LATENCY 6

The OCTOSPI mux clock in 200MHz

[KDJEM.1]

Hello @Rlamkin and welcome to The Community;

 

Is the delay block enabled or disabled?

Could you please refer to AN5050 table 8. and check your OCTOSPI configuration.

 

Please take a look at Help needed for tuning 64Mb HYPERRAM (S27KL0642DPBHI020) on STM32H735IGT6 discussion may help you.

 

Thank you.

Kaouthar

[Rlamkin]

Thankyou for your response - we will look through the info you have pointed at and let you know how it went.

Yes the delay block was enabled during all my testing.

[KDJEM.1]

Hello @ATempleyPEL ,

 

For more investigation could you please share your project and the memory datasheet?

Also could you please try to decrease the OCTOSPI frequency:

 

Thank you.

Kaouthar

 

[ATempleyPEL]

Hi,

The device we are using is: https://www.infineon.com/dgdl/Infineon-S27KL0642_S27KS0642_3.0_V_1.8_V_64_Mb_(8_MB)_HyperRAM_Self-Refresh_DRAM-DataSheet-v09_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ee8a1c47164 

I will try reducing the frequency, however we are not using either PC2 or PC3 for the interface

[LCE]

> #define OCTOSPI_HYPERRAM_LATENCY 6

This is definitely wrong, check the memory's datasheet.

Just looking quickly over it, it seems latency is always 4 cycles for writing, also for reading, but for some readings an additional 4 cycles (don't know when, don't know how to set this in OCTOSPI).

Check RM: OCTOSPI HyperBus latency configuration register (OCTOSPI_HLCR)