do FIOSET and FIOCLR need shared memory protection with RTOS

[lpcware]

Content originally posted in LPCWare by william.vh on Sun May 31 12:11:47 MST 2015
Using LPCXprersso IDE with LPC1769 and implementing freeRTOS..but reasonably new to RTOS and the concept of shared resources protection.
I am struggling to determine if FIOSET and FIOCLR need mutex protection if multiple tasks are toggling pins on the same port.

As simple pin set in C looks like this:

33        LPC_GPIO0->FIOSET = (1 << pin);

               0000113c:   movs r3, #1
               0000113e:   lsls r3, r0
               00001140:   ldr r2, [pc, #4]        ; (0x1148 <GPIO_0_on+12>)
               00001142:   str r3, [r2, #24]
               00001144:   bx lr
               00001146:   nop 
               00001148:   stmia r0!, {}
               0000114a:   movs r0, #9

No two tasks use the same pin, but tasks do share the port.
I caught something on the logic analyzer (that I can't recreate) yesterday that can only be explained by a malfunctioning sensor or a shared resource issue. The sensor seems fine.

Do I need mutex protection for the FIOSET and FIOCLR registers?

Thanks in advance.
Billy

[thibaud_ravel]

hi, i have project with two task RTX in LPC1768, two task use FIOSET FIOCLR with = (not |=) and i have corruption on the port. The two task not work in the same pin, but the same port and the read PORT SET is corrupt with a previous value of the port...

[lpcware]

Content originally posted in LPCWare by william.vh on Mon Jun 01 23:05:21 MST 2015
Thanks for the help Mike and star.
I'll cross this one off the list and keep looking.

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Mon Jun 01 02:32:51 MST 2015
However, one thing to watch for is the PIN MASK; that would have problems if two tasks set (and didn't reset to original)
with different values. That would need protection around the entire GPIO operation.

Mike

[lpcware]

Content originally posted in LPCWare by starblue on Mon Jun 01 01:25:53 MST 2015
No, you shouldn't need a mutex.

Such SET/CLR registers exist precisely so that you can set or clear a bit atomically with a single write. It avoids the dangerous read-modify-write, which would indeed need some form of protection.

A common mistake in this context is to use |= instead of =, but that's correct in your example code (maybe not everywhere?).

If the MPU were misconfigured for GPIO it might cause problems (but that would be very unusual). I.e. if GPIO were configured like normal RAM a cache might swallow the first write of two.