Weird glitch comes periodically

[Kasun Dinesh]

Hi,

Recently, I started getting a wired glitch on the LCD periodically. I m using touchGFX 4.15 and CUbeIDE 1.5. After commenting some code relevant to the UI, Glitch doesn't comes. Any one have an idea what might cause this? Video is attached

https://www.youtube.com/watch?v=ghRrd-VNGKc

Thanks a lot.

[Romain DIELEMAN]

Hi,

Are you using a custom hardware or a ST development kit ? Did you start your project from an application template available from TouchGFX Designer ?

/Romain

[Romain DIELEMAN]

Does this glitch happen only with this UI or also with the other available UI templates ?

[Kasun Dinesh]

Hi, thanks for your quick reply. I m using custom PCB but same components in STM32H750. So i can say its H750 dev kit. But i m using a different screen (800x480). I got the touchgfx generated project for h750 cubeide and developed from there. Glitch happens every other screens as well. I did more toubleshooting and found out that, if i commented a variable defined in the model, glitch dosent happens.

This is the specific section in my model

protected:
 
  ModelListener* modelListener;
 
 
 
//  HomeScreenRuntimeData homeScreenRuntimeData;

[MM..1]

Maybe better is show code where this variable is commented too. Header file not help.

[Kasun Dinesh]

Here i have commented all the areas which is using this variable. But once is defined it in the model.hpp, this happens. Is this defined in stack? Does touchgfx use new keyword for model?

[MM..1]

Glithes is produced with any code in model tick , that doing long time mean some milisec. Then we need see what you comment.

[Kasun Dinesh]

Hi,

This is my model class hpp.

#ifndef MODEL_HPP
#define MODEL_HPP
 
#include <LCDConfig.hpp>
#include <HomeScreenRuntimeData.hpp>
#include <runtime_data.h>
#include <Event.h>
 
class ModelListener;
 
class Model
{
public:
    Model();
 
    void bind(ModelListener* listener)
    {
        modelListener = listener;
    }
 
    void tick();
 
    LCDConfig * getLCDConfig();
 
    void setLCDBrightness(int brightness);
 
    void setVibrationIntensity(int vibrationIntensity);
 
    void vibrate();
 
    void setCANTermination(bool terminate);
 
    void saveHomeScreenButtonState(uint16_t pageIndex, uint16_t buttonIndex, bool isPressed);
 
    void saveHomeScreenCurrentPage(uint8_t pageIdx)
    {
        HOMESCREEN_RUNTIME_DATA_t* pt = home_screen_runtime_data_get();
        pt->selectedPage = pageIdx;
    }
 
    HOMESCREEN_RUNTIME_DATA_t* getHomeScreenRuntimeData()
    {
        return home_screen_runtime_data_get();
    }
 
    void pushUiEvent(Event_t * pEvent);
 
protected:
    ModelListener* modelListener;
//  HomeScreenRuntimeData homeScreenRuntimeData;
 
#ifdef SIMULATOR
    LCDConfig lcdConfig;
#endif
};

Once i commented "HomeScreenRuntimeData homeScreenRuntimeData;" it start working.

But later on i added another C file to control a buzzer. Then the glitch started again

[Kasun Dinesh]

Does any one got any ideas why this happens? Help is much appreciated. We are stuck in production due to this glitch.

Thanks in advance.

[N. SANTINI]

Hi,

H7 MCU means Cortex-M7 which means background optimizations such as instruction re-ordering, speculative accesses.

There are chances that these glitches are due to a wrong Memory Protection Unit (MPU) configuration.

The MPU allows to disable the Cortex-M7 optimizations, if the configuration provided in the Application Templates are fine for most cases they may not be on custom board, notably on external memories.

The consequences of a wrong MPU configuration goes from wrong data read (leading to display glitches for example) to hardfault...

Please have a look a the following MooC : https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-moocs/STM32_MPU_tips.html

As well as the following application note : https://www.st.com/resource/en/application_note/dm00272912-managing-memory-protection-unit-in-stm32-mcus-stmicroelectronics.pdf

To summarize you need to disable accesses to all addressable external memories (even not connected ones) and then define an area for each connected one taking care of how many masters can access the memory, if code can be executed or not, etc.

Best regards,

Nicolas