chEvtWaitAny triggering when I haven't sent it anything

[reportingsjr]

I am writing a driver for an IC that pulls a line low to signal that it has data that needs to be read.

I have my code set up to interrupt when that line is pulled low which sends a signal via chEvtSignalI to a thread that has a chEvtWaitAny followed by the spi commands to read from the IC.

For whatever reason it seems that chEvtWaitAny is getting a signal even though the interrupt should not have triggered and I don't send an event anywhere else in my code.

The interrupt and thread that do this are here: https://github.com/reportingsjr/rfidBoa ... ver.c#L231

I have attached a screen capture of my logic analyzer showing what is going on at the hardware level.

Channel 5 is the line that gets pulled low and triggers the interrupt. The large grey areas on the SPI clock are where cr95hfMessageThread is trying to read from the IC. You can see that the first three are directly after channel 5 is pulled low and the interrupt triggers. On the fourth read there is no interrupt being triggered. Could chEvtWaitAny be getting a signal from somewhere else somehow?

Thanks for the help! I've been stuck on this one for two weeks now!

[Coreglider]

Put code that changes pin state in your interrupt handler and use you logic analyser to see actually it triggered or not.

[Giovanni]

Good idea, or even a breakpoint.

Probably you are getting an interrupt that you don't expect, it happens a lot...

Just a note, that "(eventmask_t)20", why 20?

Giovanni

[reportingsjr]

Ah, I tried toggling a pin and setting breakpoints.

Toggling the pin showed that there is an interrupt at the very beginning.

The odd part: when I put the breakpoint in that first spurious interrupt disappears and the program works correctly!

I am using the linaro gcc toolchain. Could it be a bug in the toolchain?

Also, the reason I am using 20 as an event signal is because I wasn't sure if 1 would be used by something else and might have been sending an event signal to that thread an causing the issue. Obviously this is not the case. I will change it back to 1.

[Giovanni]

Hi,

The problem with 20 is that it is equal to 10100 binary, so you are using 2 bits instead of one.

About the toolchain, you need to use a GCC for bare metal, like the one here: https://launchpad.net/gcc-arm-embedded

Giovanni

[reportingsjr]

the linaro toolchain is a bare metal toolchain. I am also using the toolchain you linked on a different computer and I was still getting the same problem.

I ended up disabling autostart on that interrupt channel. I added extStartChannel... after all of my initialization code and voila! No more early spurious interrupts.