BLE implementation causing GPIO reset pin to stay High

[DvAgas]

I am using a GPIO pin (P1.05) as a reset signal for an external CPU component. The pin functions correctly and stays low when tested in a basic GPIO application. However, as soon as I implement the BLE stack, the pin behavior changes: it stays High by default and only toggles Low for a few milliseconds when triggered, before immediately returning High.

It appears something in the BLE initialization or a hardware conflict is pulling this pin High. I have defined the pin in my overlay as GPIO_ACTIVE_HIGH. Is there a known conflict with Port 1 Pin 5 when using the BLE controller, or is my initialization order incorrect?

[Håkon Alseth]

Hi,

 

I am using a GPIO pin (P1.05) as a reset signal for an external CPU component. The pin functions correctly and stays low when tested in a basic GPIO application. However, as soon as I implement the BLE stack, the pin behavior changes: it stays High by default and only toggles Low for a few milliseconds when triggered, before immediately returning High.

Are you using sysbuild and do multi-image builds for the appcore? If yes, then you need to disable gpio forwarding in the sub-images, such as mcuboot.

 

Kind regards,

Håkon

[DvAgas]

Thank you for the reply
The project is not currently configured to use Sysbuild or perform multi-image builds for the network and application cores.Its a standard, single-image Zephyr application.

[Håkon Alseth]

Hi,

 

Q1: Could you share the generated zephyr.dts file?

Q2: Can you try to set/clr the gpio at boot-up and see if this works as intended? For testing purposes, to see if the pin actually toggles.

 

Kind regards,

Håkon