STM32MP257f-ev1 GPIO_EXTI_CM33_NonSecure example

[kt46]

I am attempting to modify the code in the STM32MP257f-ev1 GPIO_EXTI_CM33_NonSecure example to use LED2 vs LED3. The example runs correctly with the code provided, but simply changing LED3 to LED2, it does not run properly. The code compiles without error, yet LED2 does not illuminate when user button 2 is pressed. 

Following the provided code and reference manual documentation, RM0457 Rev5 / pg.861, it appears all of the code is present in the example. To initialize LED2, VDDIO3 must be powered up to provide power for Port D I/Os. LED2 is on Port D. 

During debug, the debugger does not stop at main, even though the Set breakpoint at main is checked in the Startup tab of my Debug configuration. This prevents me from stepping through the code to potentially identify what is going wrong. I have tried manually setting breakpoints and those seem to be disregarded as well. Skip all breakpoints is not enabled.

Furthermore, I do not know a way to verify whether VDDIO3 does in fact power up. Examining the PWR_CR1 SFR, it is not setting the bits necessary to enable or monitor VDDIO3. For future potential projects, I will likely need to power up other dormant VDDIOs.

Any suggestions are much appreciated.

[Zakaria1]

Hello @kt46,

There is a possibility to use the stm32mp2xx_hal_pwr_ex driver, which provides the function:
HAL_StatusTypeDef HAL_PWREx_EnableSupply(uint32_t periph);
This function allows you to validate a peripheral's supply voltage, which is required before using the peripheral.
For example, if you want to enable the supply for VDDIO3, you should add the following line in your main.c
HAL_PWREx_EnableSupply(PWR_PVM_VDDIO3);
The parameter PWR_PVM_VDDIO3 is already defined in stm32mp2xx_hal_pwr_ex.h.
Other available parameters include PWR_PVM_VDDIO1, PWR_PVM_VDDIO2, and PWR_PVM_VDDIO3.

Best Regards,
Zakaria

[kt46]

Zakaria,

I had added: HAL_PWREx_EnableSupply(PWR_PVM_VDDIO3) in the code just after the HAL_Init(). It is also already included in the BSP_LED_MspInint (Led) within the BSP_LED_Init (Led_TypeDef Led) function, in the example code. This did not solve the problem. Once again, I cannot get the Debug to stop at main() in order to see where the problem might be.

I am able to control LED2 in the userspace through the libgpiod library with the commands:

Board $> gpioset -c gpiochip3  8=1         // LED2 turns on 

Board $> gpioset -c gpiochip3  8=0         // LED2 turns off

But the GPIO-EXTI code compiled within STM32CubeIDE will control not LED2.

Executing:     Board $> gpioget -c gpiochip3; after loading the GPIO_EXTI example on the board, gpiochip3 returns;

gpiochip3 - 16 lines;

           ...

            line     7:     "PD7"               input    consumer="kernel"

            line     8:      "PD8"              input  (consumer is blank)

I would have expected PD8 to return as an output with consumer="LED2", capable of illuminating LED2.  

[VishalC]

Hi

To help resolve your LED2 and debug issues, could you clarify how you are running the STM32MP257f-ev1 GPIO_EXTI_CM33_NonSecure example? Are you operating the board in Production mode (with OSTL) or Engineering mode? Understanding your setup will help determine if there are any restrictions or configuration differences that could affect VDDIO3 power-up, GPIO initialization, or debugging behavior.

[kt46]

Hello,

My Debug configuration is running on the thru Linux core (Production mode) setting. I have further discovered all of the Resource Isolation Framework (RIF) configurations and have been investigating the potential of this preventing my access to both the PWR and the GPIO peripheral registers. Being rather new to this environment, any guidance is greatly appreciated. 

Currently I am attempting to locate the correct *-rif.dtsi file that applies to this GPIO_EXTI example. It does not appear directly in the Project Explorer of the CubeIDE. I have located the res_mgr.c file, which indicates that the CM33 is running in the unsecure mode, as the project name implies, but it's a little unclear if the thread mode is privileged or unprivileged. It is my understanding that the configuration(s) in the *-rif.dtsi file and the Compartment ID setting will determine access to the registers that enable the VDDIO3 power supply as well as the GPIO ports/pins.

V/R,

kt46