Is GPIOTE driver thread-safe ?

[Vincent Belaïche]

Dear Nordic experts,

While investigating some of my bugs, I had to look into the GPIOTE driver code, and I realized that it has some allocator for mapping GPIOTE channels to pins.

Because the GPIOTE driver connects the input buffer, I call it dynamically in order to minimize power consumption.

So this question came to me: isn't there any risk to mess out the GPIOTE allocator data if two OS tasks make a call to the GPIOTE driver and one is preempting the other.

I anticipated this event by using some FreeRTOS mutex, but well I would like to know if this can really happen in order not to spend OS resource just for the fun of it.

Actually I am just speculating that this may happen, I did not meet it in real life.

I am currently using SDK 15,0,0.

[Susheel Nuguru]

Hi Vincent,

The drivers were not designed to be thread safe yet. While using in any RTOS, I normally protect any global member that is being accessed in multiple context by a mutex. I would recommend you to do the same to be sure of it.

[Vincent Belaïche]

Thank you, this confirms what I anticipated from reading the code.

I think that the driver documentation should be improved for the user to know which driver functions access shared variables, and as such should be protected somehow from thread interaction (by means of some protocol between OS tasks, or some mutex), and which do not need such care.

This would be helpful to have this kind of info for each function that really needs protection to differentiate them from functions, like e.g. nrf_gpio_in_clear, which inherently are thread safe because registers are 32bits in an 32bit architecture, so as long as some GPIO is assigned to some OS Task there is no conflicts.