Weird GPIO interaction

I’m running two of my programs (in BASIC, plus a little bit of assembler) on an rpi3B.

One, entirely in BASIC, uses IIC_Control to send and receive data from an interface connecting a 1-wire device to the IIC bus.

The other uses the GPIO module calls XGPIO_ReadEvent within a TickerV service routine to check the status of 2 of the GPIO pins, and sets a pollword bit to indicate which has changed state.

If both these programs run together, then I get spurious pollword returns in the second program. It’s always bit 16 set, which means a transition detected on GPIO pin number 4. (I also check pin 5, which never gets these spurious returns.)

Why?

If there’s something IIC related to do with pin 4, I could modify the hardware to use a different pin, and alter the software to match. I don’t want to do that though if there’s any random element involved.

It’s unlikely to be a major problem, because when the second program is in use, the first will not be running. It’s annoying though, as during debugging it’s useful to be running both.

If both these programs run together, then I get spurious pollword returns in the second program. It’s always bit 16 set, which means a transition detected on GPIO pin number 4. (I also check pin 5, which never gets these spurious returns.)

Which port is this? ie. do you mean GPIO16 or GPIO48.
There doesn’t look to be anything exciting about GPIO16, but GPIO48 can be the SD card clock, which will transition whenever the card is looked at.

That aside, why not just mask the event bits you’re not interested in. It’s a polled interface, so no harm collecting the event and just shrugging it off.

Which port is this? ie. do you mean GPIO16 or GPIO48.

Sorry, I don’t understand the question. If it helps, the code fragment that does the testing is below.
The pins I am using are GPIO numbers 4 and 5, different numbers of course on the connector.

DEF FNtestpin(pass%)
[OPT pass%
; R7 counts events handled in this pass of isr
; R6 holds the bitmask for the events found
; DID A PIN CAUSE AN EVENT
;
                mov r6,#0           ; CLEAR bit mask
                mov r7,#0           ; clear count
                mov r0,#startpin%  ; try this pin
                 FNswi("XGPIO_ReadEvent")
                bvs isr_error     ; clean up AND exit ISR
                cmp r0,#1         ; RETURN 1 IF active, but 0 if not
                bne nextpin
                ;
                add r7,r7,#1      ; increment COUNT OF events
                orr r6,r6,#startmask%
                mov r0,#startpin%  ; reset the event
                mov r1,#0          ; CLEAR it
                FNswi("XGPIO_WriteEvent")
                bvs isr_error     ; clean up AND exit ISR
.nextpin
                mov r0,#finishpin%  ; try this pin
                FNswi("XGPIO_ReadEvent") ; test
                bvs isr_error     ; clean up and exit ISR
                cmp r0,#1         ; RETURN 1 IF active, but 0 if not
                bne testpin_exit         ; all done
                ;
                add r7,r7,#1      ; increment COUNT OF events
                orr r6,r6,#finishmask%
                mov r0,#finishpin%  ; reset the event
                mov r1,#0          ; CLEAR it
                FNswi("XGPIO_WriteEvent")
                bvs isr_error     ; clean up and exit ISR
.testpin_exit
                ldr r5,[r12]      ; GET current pollword
                orr r6,r6,r5      ; add in the bits FOR this pass
                str r6,[r12]      ; store back
]
=""
:

You need to have a bitset of events that you are interested in – don’t go looking for, and then arbitrarily clearing down, bits that you have no interest in – others may depend on them.

[Edit: Apologies – I saw constants like startpin, finishpin, and a nextpin label and naively assumed a loop was going to be involved without looking further]

You need to have a bitset of events that you are interested in

I’m only testing and resetting bits 4 and 5, for GPIO4 and GPIO5. I can’t remember where I found the documentation for GPIO_ReadEvent and GPIO_WriteEvent – the documentation on the ROOL website has placeholders for those functions. It’s working (except when another application conflicts).

There’s a lot more discussion of this here: https://www.riscosopen.org/forum/forums/11/topics/14797?page=1

I picked those pins because by default they seem to be I/O pins, not special functions. This issue suggests that GPIO4 may have a different use. Looking now at one of the many online pin descriptions, I see one where GPIO4 is described as GPCLK0. All the other pin layout diagrams I have found show GPIO4 as a general purpose I/O pin.
That might indicate why I have a problem. GPIO6 might be a better choice.

Also going through the code, I see then FNswi is unsafe. It does register and state preservation round the switch to SVC mode before entering the swi. However it was using the bottom 5 bits of the PCSR instead of the bottom 4. It’s a hangover of trying to learn assembler from old online code examples. Now altered.

Did you try

SYS "OS_WriteMode", 4, 0

beforehand? I would of thought that would stop any other ports (like GPCLK0) from affecting the pin.

Did you try

SYS "OS_WriteMode", 4, 0

beforehand?

Here’s the initialisation section

OSCLI("SET GPIO_PRESENT 1")
OSCLI("RMENSURE GPIO 0.00 SET GPIO_PRESENT 0")
IF FNgetsysvar("GPIO_PRESENT") ="0" THEN PROCwarn("GPIO module must be present"):ERROR 1,"NO GPIO MODULE"
REM SETUP THE HARDWARE
startpin%=4
finishpin%=5
REM set as input
SYS "GPIO_WriteOE",startpin%,1
SYS "GPIO_WriteOE",finishpin%,1
startmask%=1<<16
finishmask%=1<<17
mode%=0 + (1<<7) + (1<<9): REM input, enable events, falling edge
SYS "GPIO_WriteMode",startpin%,mode%
SYS "GPIO_WriteMode",finishpin%,mode%
REM clear existing events
SYS "GPIO_WriteEvent",startpin%,0
SYS "GPIO_WriteEvent",finishpin%,0

The IIC to 1-wire module I’m using has a socket that goes on pins 1-10 of the GPIO header. I don’t know whether pin 7 (GPIO4) is connected in the module, but I suspect it might be. However a close look at the PCB suggests not.

All this however is leading me in the direction of changing the pin used from GPIO4 to GPIO6. Ten minutes with a soldering iron, and 30 minutes updating the software and making sure I’ve found ALL the references.

Probably not the cause of Alan’s problem(?), but I had a look at the Pi GPIO HAL: I think it might be missing a PHPSEI / PLP wrapper for the common routine called by EdgePollStatus – if we have one fg task polling the event status, it reads, furtles bits, then writes that GPIO register, but a bg task (could be unrelated, looking at different pins) might have changed that GPIO register value in the background, so a stale one could then be written by the fg task. Compare with the WriteMode function which does have the atomic GPIO r/w.

All this however is leading me in the direction of changing the pin used from GPIO4 to GPIO6. Ten minutes with a soldering iron, and 30 minutes updating the software and making sure I’ve found ALL the references.

That time was a bit optimistic. Ten minutes to move a wire from one pin to another, an hour to track down a faulty push-button switch that decided to fail JUST AS I OPENED THE BOX. Half an hour to swap the PI3 for another one, after I managed to apply 24 volts to a GPIO pin. (Anyone got a use for dead pi’s? That’s two now.)

Another hour tidying up the wiring to make it easier to work on the thing out of the box, and another 20 minutes changing two capacitors to shorten the debounce times, now that I’ve got rid of the spurious second pulses.

There was only one other reference to the pin number.

Judging by this: https://www.raspberrypi.com/documentation/computers/os.html#gpio-and-the-40-pin-header GPIO4 is no longer a general purpose I/O pin by default. Most other online versions of this diagram differ.

However, this: https://pinout.xyz/pinout/gpclk# suggests that GPIO5 and GPIO6 are also clock outputs. WTF?

GPIO 4 is used by the Witty Pi so is assumed to be general purpose. I don’t think it is implied that GPIO 4, 5 and 6 are not general purpose, so far as RISC OS is concerned.

The Witty Pi 3 documentation suggests that the 1-wire interface (which uses GPIO 4 by default in Linux) is disabled or re-assigned by commenting out the driver in the Linux firmware.

#dtoverlay=w1-gpio

RISC OS firmware does not enable the 1-wire interface.

Nevertheless, when running a program that polls the IIC bus every 10 seconds, GPIO4 gets the occasional transition, at times that seem random. The program also writes to the SD card every ten minutes. Changing from GPIO4 to GPIO6 seems to have eliminated the problem. It’s been running for 15 hours so far, with no spurious events being recorded.