cancel
Showing results for 
Search instead for 
Did you mean: 

STM32CubeIde 1.17.0 debug issue for STM32MP257 board

MBassi
Associate III

Hello,

I'm trying to debug firmware code for M33 in NS mode. The board is running openSTLinux6.6 BSP in opteemin mode. M33 is running at 400MHz by setting in optee DT: 

FLEXGEN_CFG(0, XBAR_SRC_PLL4, 0, 2)

 and by running in firmware:

HAL_Init();
SystemCoreClockUpdate();

 I used two application to test:

The first one is very simple and do a GPIO (configure in output mode) set and reset

LL_GPIO_SetOutputPin( (GPIO_TypeDef *) GPIOD, LL_GPIO_PIN_1 );
LL_GPIO_ResetOutputPin( (GPIO_TypeDef *) GPIOD, LL_GPIO_PIN_1 );

but when I used an analyzer to watch the GPIO signal, I got a time of 1,7us for set/reset that It seems to me to slow for running at 400MHz (as you can see from the first attached image).

The second application is designed to exchange data with an A35 application using two piece of shared memory and IPCC. It's a simple loopback test where M33 copy data (from 0 to 1024 bytes) to first shared memory and signal data's ready through IPCC to A35, A35 receive the data and copy it back to the second piece of shared memory and signals to M33. Using some GPIOs in M33 firmware as test points (TP) and an analyser I notice that the time spent by M33 for memcpy is much higher as I expected, more or less 650us for 1024 bytes (P0 in second attached image), while the time spent by A35 to read IPCC Channel Flag read the data from shared memory and copy it back is more or less 13,2us for 1024 bytes (P1 in second attached image). 
The code I used for M33 memcpy and set/reset TP GPIO is

LL_GPIO_SetOutputPin( (GPIO_TypeDef *) GPIOD, LL_GPIO_PIN_11 );
memcpy( (void *) &recived_message, SHMEM_M33_RECEIVE, (size_t) current_size );
LL_GPIO_ResetOutputPin (GPIO_TypeDef *) GPIOD, LL_GPIO_PIN_11 );

I don't Know if I missed something in M33 clock configuration or I don't understand somethings in M33 memory management, could someone help me please?

Regards     

Marco

0 REPLIES 0