This is a repost of the message I left on the "STM32 MCUs Touch GFX and GUI" and I'm hoping that it gets some more traction in this section of the forum.
Apologies for the repost.
I'm in the process of migrating from an STM32F779AIY6TR to an STM32U5A9NJH6Q and I'm running into issues with the DSI communications to my LCD on the U5 platform that were not present with the F7 when using the same parameters.
Hardware setup:
LCD Panel - E30RB-I-MW340-N (Sitronix ST7701S TFT IC) Focus LCD: MIPI Driver Pseudocode
U5 Processor (DSI not working) STM32U5A9NJH6Q
F7 Processor (DSI working) STM32F779AIY6TR
Modes:
Video Mode, Non Burst Mode with Event
LP transitions are enabled for all video areas.
16 Byte command maximums
Commands are transmitted in Low Power mode
Clock and other parameters that seem potentially relevant (same for both platforms generated from CubeMX):
PHY DSI 240MHz
DSI lane byte clock 30 MHz
DSI txclkesc 6 MHz
Automatic clock lane control is disabled (per the U5 Errata)
PHY Low Power offset 0 CLK
BTA is enabled
Issues / Symptoms / Oddities:
- Short writes seem to be working on the U5. Issuing simple commands to the LCD like "All pixels on" are responded to.
- Long writes do not seem to be working consistently. Issuing the commands to display the Sitronix's built in test image work <5% of the time (but do seldom work).
- Deriving the Byte Land Clock from the PHY DSI breaks the DSI peripheral on the U5. The Byte Lane Clock has to be derived from PLL3P for unknown reasons. Looking at the U5 Discovery code, the procedure for clock configuration on that product is different from what CubeMx is generating for my U5 platform.
For example the U5 Discovery code has the DSI peripheral started and then the clock source switched over to the DSI PHY (see below).
// Start DSI
if (HAL_DSI_Start(&hdsi) != HAL_OK)
{
Error_Handler();
}
/* Switch to DSI PHY PLL clock */
RCC_PeriphCLKInitTypeDef PeriphClkInit;
PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_DSI;
PeriphClkInit.DsiClockSelection = RCC_DSICLKSOURCE_DSIPHY;
HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit);
/* USER CODE END DSIHOST_Init 2 */
While the CubeMX generated code for my platform handles this inside of HAL_DSI_MspInit(DSI_HandleTypeDef* dsiHandle).
- Differential DSI clocks look roughly between the same for the F7 and U5 when scoped (My scope is limited to 5Gsps / 1GHz BW and I don't have active probes so I'm pushing the limits of what I can realistically measure). But the peak to peak is ~500mV for the clock lines and the frequency is on target.
- The U5 clock does not seem to consistently transfer to LP (I'm not seeing the differential high speed clocks going to the LP logic levels the same way as the F7). Though my measurements on the U5 were taken prior starting FreeRTOS (but after initializing the DSI / LTDC / TouchGFX) so this might not be an apples to apples comparison with the F7, where I measured while video was streaming.
Things tried:
- I've adjusted the PHY DSI clocks down to 120MHz and up to 500MHz on the U5 to see if there is a signaling issues with going too fast or slow for what the hardware can handled (all DSI data and clock lines are matched length and 100ohm impedance in the layout, so everything should be ok from a layout perspective).
- Adjusted the PHY LP offset to every value possible
- Disabled BTA on the U5 (unsurprisingly this breaks comms completely).
- Tried various combinations of Flow Control Configuration.
- Confirmed clock and data lane pins are correctly mapped in the IOC.
- Enabled Contention Error Detection
- Restricted LP commands to only the vertical blanking period and adjusted the maximum packet size down as low as 8 bytes and up to 32 bytes.
- Adjusted the PHY Timings (LP to HS and HS to LP transition timings) to various values.
At this point, I'm at a loss for what to look into next. The autogenerated peripheral configuration code for the F7 and U5 differs in various ways when I run a diff. Most of the differences seem to relate to a general refactoring of code but there are configuration parameters on the U5 that aren't present in the F7. For example PLLInit.PLLVCORange, PLLInit.PLLChargePump, and PLLInit.PLLTuning are present in the U5 as configurable parameters, but not in the F7.
Any help would be appreciated on the matter.
