2021-02-11 06:28 AM
I have an STM32H743 connected to a screen that uses ST7789 via FMC (i.e. parallel connection) using 8-bit bandwidth and A18 to select between command and data.
The current code has an issue that the screen output is messed up (see pictures below) if I don't add a sleep to my write functions that uses FMC.
The code is working (no need for delay) under STM32CubeIDE but I ported it to work as part of MicroPython.
Things that I already considered:
Any pointer on what might be the issue? Is it a FMC clock configuration? some configuration on external memory location?
Any config that slows down the FMC as RAM access
Appendix:
#define COMMAND_LOCATION 0xC0000000
#define DATA_LOCATION 0xC0040000
static uint8_t* fmc_command_pointer = (uint8_t*) COMMAND_LOCATION;
static uint8_t* fmc_data_pointer = (uint8_t*) DATA_LOCATION;
void writeCommand(uint8_t command)
{
*fmc_command_pointer = command;
HAL_Delay(100);
}
//*****************************************************************************
void writeData(uint8_t data)
{
*fmc_data_pointer = data;
HAL_Delay(1);
}
Filling the screen with the color blue without the delay in writeData produces:
With the delay (after a while since it takes 1ms per pixel) fills it correctly:
Solved! Go to Solution.
2021-02-13 08:20 AM
Found the issue, it was a missing volatile on the pointers to the FMC memory or as in STM32HAL syntax __IO - the code should be:
static __IO uint8_t* fmc_command_pointer = (__IO uint8_t*) COMMAND_LOCATION;
static __IO uint8_t* fmc_data_pointer = (__IO uint8_t*) DATA_LOCATION;
Now why this works in my STM32CubeIDE is a mystery, probably a gcc compile flag
2021-02-13 08:20 AM
Found the issue, it was a missing volatile on the pointers to the FMC memory or as in STM32HAL syntax __IO - the code should be:
static __IO uint8_t* fmc_command_pointer = (__IO uint8_t*) COMMAND_LOCATION;
static __IO uint8_t* fmc_data_pointer = (__IO uint8_t*) DATA_LOCATION;
Now why this works in my STM32CubeIDE is a mystery, probably a gcc compile flag