cancel
Showing results for 
Search instead for 
Did you mean: 

Problem configuring X-CUBE_AI on STM32H743IIT6 with existing TouchGFX setup

JfSDK
Associate II

1. X-CUBE_AI forces the use of the bypass clock source and enables both I-Cache and D-Cache.

2. Following the advice in https://community.st.com/t5/edge-ai/x-cube-ai-integration-and-clock-errors/td-p/706076 allowed me to avoid the bypass clock source, but the caches remain enabled. Additionally, the SystemClock_Config function enters a hardfault at:

RCC_OscInitStruct.HSI48State = RCC_HSI48_ON;

RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;

3. When TouchGFX is not used, X-CUBE_AI can apply templates normally and generates an additional app_x-cube-ai.c file. The code in this file seems self-contained, so the clock initialization issue is likely not related to this.

4. Are there any solutions or workarounds to resolve the clock configuration conflict and disable the forced enabled caches? My project relies heavily on DMA operations, and I prefer not to use the cache.

Thank you for your assistance.

The whole SystemClock_Config function as follow:
void SystemClock_Config(void)
{
RCC_OscInitTypeDef RCC_OscInitStruct = {0};
RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

/** Supply configuration update enable
*/
HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);

/** Configure the main internal regulator output voltage
*/
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE0);

while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}

/** Initializes the RCC Oscillators according to the specified parameters
* in the RCC_OscInitTypeDef structure.
*/
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI48|RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.HSI48State = RCC_HSI48_ON;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLM = 4;
RCC_OscInitStruct.PLL.PLLN = 480;
RCC_OscInitStruct.PLL.PLLP = 2;
RCC_OscInitStruct.PLL.PLLQ = 20;
RCC_OscInitStruct.PLL.PLLR = 2;
RCC_OscInitStruct.PLL.PLLRGE = RCC_PLL1VCIRANGE_1;
RCC_OscInitStruct.PLL.PLLVCOSEL = RCC_PLL1VCOWIDE;
RCC_OscInitStruct.PLL.PLLFRACN = 0;
if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
{
Error_Handler();
}

/** Initializes the CPU, AHB and APB buses clocks
*/
RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
|RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2
|RCC_CLOCKTYPE_D3PCLK1|RCC_CLOCKTYPE_D1PCLK1;
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
RCC_ClkInitStruct.SYSCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.AHBCLKDivider = RCC_HCLK_DIV2;
RCC_ClkInitStruct.APB3CLKDivider = RCC_APB3_DIV2;
RCC_ClkInitStruct.APB1CLKDivider = RCC_APB1_DIV2;
RCC_ClkInitStruct.APB2CLKDivider = RCC_APB2_DIV2;
RCC_ClkInitStruct.APB4CLKDivider = RCC_APB4_DIV2;

if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_4) != HAL_OK)
{
Error_Handler();
}
}

 

1 REPLY 1
Julian E.
ST Employee

Hello @JfSDK,

 

To address the issues with X-CUBE-AI’s forced cache and clock configuration, here are the steps and workarounds you can apply:

 

1. Disabling I-Cache and D-Cache
Unfortunately, X-CUBE-AI enforces enabling both I-Cache and D-Cache during code generation. There is no option in the CubeMX UI or integration flow to disable this automatically.

However, you can manually modify the generated code to disable the caches:

  • After generating the code, locate the relevant cache enabling lines (typically in MX_X_CUBE_AI_Init() or app_x-cube-ai.c) and comment them out.
  • This file is usually generated from a template located in the db directory of the X-CUBE-AI pack installation.

Keep in mind: If you regenerate the project, you’ll need to repeat this step unless you create a custom template or script your post-processing.

 

2. Clock Configuration Fix (Avoiding Bypass Source)
To avoid X-CUBE-AI forcing the use of the HSE bypass clock source, you can modify the board configuration file used during code generation:

Locate the file: X-CUBE-AI installation folder/db/templates/boardExternalMem.xml


Inside this file, you will see an entry like this for die id="450":

<die id="450">
<IP name="QSPI" addr="0x90000000" type="Flash"/>
<IP name="FMC" addr="0xD0000000" type="Ram"/>
<requiredParameters>
RCC.Mode=HSE-External-Clock-Source
RCC.HSE_VALUE=8000000
</requiredParameters>
</die>


To remove the bypass clock constraint, replace it with an empty requiredParameters section:

<die id="450">
<IP name="QSPI" addr="0x90000000" type="Flash"/>
<IP name="FMC" addr="0xD0000000" type="Ram"/>
<requiredParameters>
</requiredParameters>
</die>


If you're using a specific ST board (not just the DIE), apply the same change in the corresponding board entry in the same file.

This change will stop X-CUBE-AI from overriding your clock setup, allowing your custom SystemClock_Config() to remain in control.

3. General Advice

  • Always backup the generated files or use version control, as CubeMX/X-CUBE-AI can overwrite changes during regeneration.
  • If you rely on DMA, it is a good idea to disable caches, or at least ensure proper cache management (invalidation/cleaning) if you can’t disable them.
  • Be cautious about modifying X-CUBE-AI internal files — they may be overwritten when the pack is updated. Use project-specific overrides or post-generation scripts where possible.

 

Have a good day,

Julian

 


In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.