We are trying to use PWM2 on the default pin of SODIMM 28, but in certain specific cases we are finding that after working correctly as a PWM output for a random period of time between 5 seconds and 120 seconds the pin’s function is being changed from altfn = 0 (PWM2) to altfn = -1 (GPIO).
We have removed all the cases from our code for configuring or controlling GPIOs but it is still happening. The only thing we have left is the bootloader is initially configuring this pin as a GPIO (as the pin is controlling a display backlight).
Is there any way of detecting or logging when something has requested a change to the pin function, so we can try to understand what is requesting this change?
We are currently using a custom OS build based on v2.3 of the WEC7 BSP.
Are you able to reproduce this issue on a Toradex Provided OS Build? How exactly you are detecting pin function change? Can you you create a minimal application to reproduce this issue and share its project?
I detected the pin function was changing by calling the Gpio_GetConfigString function to get the altfn configuration option. After using the PWM library to configure the PWM output Gpio_GetConfigString was correctly returning altfn=0 and then after a random period of time it would start reporting altfn=-1.
I added that check as we had noticed that the signal on the pin was changing from a clean PWM output to a fixed logic high.
It is definitely not board specific as we have noticed it on multiple T20.
I am trying to replicate on the Toradex provided OS build and with a minimal application - it is slightly complicated as it only happens in specific cases with our application and there is not a obvious difference compared to when it doesn’t happen.
As I said in my previous message that is exactly what I am trying to do, but I can’t currently find a way of replicating it.
Hence why my original question was whether there was any way of detecting or logging when something has requested a change to the pin function.
Hi @prmartin . This can happen due to the fact that selected pin is used for backlight. Please double check registry settings and verify if BL_GPIO set to -1 (0xFFFFFFFF)
Hi @alex.tx ,
Thank you ever so much for the pointer. I had tried that registry setting before, but your message made me double check the display registry settings. I realized that I had UseSplashSettings enabled so it was ignoring the settings in the registry and using the bootloader settings which had that pin configured for the backlight.
Changing the registry setting has solved the issue completely.
(I’m still not completely sure why the built in backlight driver was only configuring the GPIO in the specific cases that it was, but it doesn’t matter).