STM32u5a9 hexa-spi PSRAM issue

[nwm_35]

I am attempting to bring up a custom board using a STM32U5A9 chip. I modeled the board off of the STM32u5a9j-dk dev kit (the one with a circular screen). I've been able to get our LCD screen to work over DSI and touchGFX currently runs fine.

Now I am trying to run the frame buffer off of a PSRAM chip (the exact same chip on that is on the dev kit board - aps512xxN-OBR. Note that the DK chip says aps512xxN-OBRx while our custom board chip says aps512xxN-OBR. This seems to be inconsequential based on the datasheet however.) I am using BSP drivers found on the stm32u5 github page. The board I am using is currently missing the octospi flash from the devkit but in a future iteration of the board I will be using that.

I have been unable to complete initialization of the PSRAM on the custom board due to a timeout in the first registerRead after the PSRAM is reset. However when I run this same code on the dev kit it runs just fine and intitialization works. I've triple checked the GPIO connections between the MCU and PSRAM and they are correct. Where else should I be looking to figure this out? I was under the impression that if the hardware matched 1:1 then the code should work but what other hardware on the dev board can impact the hexadeca-spi operation?

[KDJEM.1]

Hello @nwm_35 and welcome to the Community :),

Do you use the same STM32U5A9J-DK Altium_Designer project ?

Do you use the same line length and thickness as in the STM32U5A9J-DK Altium_Designer project to connect the PSRAM?

Could you please check the PSRAM pins?

Thank you.

Kaouthar

[nwm_35]

Kaouthar,

Thank you for your response. I went over our PCB with our hardware engineer. Our lines are all within 10mil of eachother so we're well below the 50mil requirement. What does byte0 and byte1 mean here though? Our clock is less than 100mils away from our data lines, but by looking at your stm32u5a9j-dk board your clock line also doesn't seem to be further than 100mil from data lines. So if byte0/byte1 aren't data lines what are they referring to?

We are not using your altium designer project because we use kiCAD but we've checked the psram pins against your schematic several times.

Please let me know what else you need from me. 

[KDJEM.1]

Hi @nwm_35 ,

Byte0: DQS0, IO0, IO1,..,IO7 signals, these lines are match length with a maximum tolerance of 50mils.

Byte1: DQS1, IO8,..,I15 signals, these lines are match length with a maximum tolerance of 50mils.

CLK  is 100 mils from any signal (DQS0, IO0, IO1,..,IO7, DQS1, IO8,..,I15).

Could you please try to decrease the HSPI frequency and let me know if the PSRAM issue is solved or not? 

Thank you.

Kaouthar

[nwm_35]

Kaouthar,

We were able to achieve communication by increasing the prescaler in the BSP code for the stm32u5 to 2. This is fast enough to run a 480x800 screen at 16bpp and 28fps. However this is unable to support our other screen (720x1280, 16bpp, 52 fps). Our traces are packed too closely, and so we are working on a board revision that will allow higher frequency communication. We've copied the traces exactly as they appear on the stm32u5a9j-dk board. Do you have any specs on how much data we will be able to transfer over the hspi lanes when they are correctly laid out?

[KDJEM.1]

Hello @nwm_35 ,

Could you please try to increase the frequency slowly by using other HSPI clock sources? What is the maximum frequency for which you can communicate with HSPI interface?

In STM32U5 devices, any of the four clock sources, (SYSCLK, pll1_q_ck, pll2_q_ck, pll3_r_ck) can be used for HSPI clock source.

-->how much data we will be able to transfer over the hspi lanes?

Depends on:

- Mode: SDR (single-data rate) or DTR(double-transfer rate).

- Type of read/write: synchro- or no-synchro-.

- Refresh and boundary

Please take a look to RM0456 precisely Hexadeca-SPI interface (HSPI).

Thank you.

Kaouthar

[nwm_35]

Kaouthar,

I'm now running the hspi ram at 208 mhz, the maximum that appears to be supported by the stm32u5 and no prescaler. There is still this screen tearing issue, only on transitions. The length of time that the tearing occurs is cut down by increasing the hspi clock, but we still have over a second of static on screen transitions. I am using variable latency, 16 byte linear bursts, and my IO mode is set to X16 mode.

Are there any strategies still to try or should I be concluding that this hardware does not support driving a screen of this resolution?

[KDJEM.1 · Accepted solution]

Hello @nwm_35 ,

I'm now running the hspi ram at 208 mhz,

The HSPI interface can reach 160MHz as mentioned in the datasheet.

For the screen issue, I advise you to check the LCD timing configuration.

Please take a look at AN4861 may help you.

Kaouthar

[KDJEM.1]

Hi @nwm_35 ,

Any update about this issue?

If you need further clarification, please do not hesitate to share it :).

If you request is answered please click on Accept as Solution on the reply which solved your issue or answered your question.

Thank you.

Kaouthar

[nwm_35]

Kaouthar,

We wound up making two boards, one spaced out identically to the dev board and one where the traces were significantly closer together (52% of the area for all the traces). As far as I've been able to tell they work identically. We're running the HSPI peripheral at 208mhz. It works well enough to store a 480x800x16bpp frame buffer on the psram, but a 720x1280x16bpp frame buffer is too large to use without screen tearing. For anyone else with this problem, storing the first touchgfx buffer on internal RAM, and the double and animation buffers on the PSRAM makes the larger screen look good for everything but animations. 

Thanks for your help.