SPI multiple devices radio lockup

[Joris Hoogeboom]

Hi all,

I'm encountering an issue where there are two devices on the SPI bus a tri-color LED driver (a glorified shift register), and the rf23b radio. http://www.onsemi.com/PowerSolutions/product.do?id=NLSF595

These leds are driven by this library http://www.elcojacobs.com/shiftpwm/

First, there was the issue of the SPI bus having only one status register, so if having two devices requiring different settings, that must be dealt with (this one is solved, but maybe for future reference and other people having problems).

The other issue is that the radio locks up after sending just one or two packets. I'm using one radio to send a message every 2 seconds and the other that has the leds also to receive only, in a setup very similar to the simple server/client in the examples.

Turning on the debugging serial.prints gives some more info, but also it changes the problem, it starts receiving for a longer period.

- I'm getting some Funny no Interrupt! messages, FIFO full and IFFERROR messages.

- Going by the information found in another thread actually disabling those IFFERROR interrupts makes it lock up a lot later, but it doesn't solve it, inevitably it happens.

- introducing a delay in the main loop also makes it go longer before locking up (weird!)

Using a logic analyser, I've found that the SS behaviour of both devices is good, they are not inadvertedly writing or reading during the other devices SPI communication. However I'm positive but not absolutely certain that is also the case of the SPDR register. (Sidenote: the radio really doesn't like it's clock probed during initialisation, it always failed init if i connect a probe to the CLK line, but after finishing initialisation it seems not so impacted and I can see it toggling during SPI transfers)

I'm not exactly sure what "locked up" means, I've been reading a lot of threads on this group, possibly it means deadlocked?

Without the introduction of the Leddriver code the radio is absolutely fine, so it must be something in the SPI interaction, but what? Any clues? What am I looking for?

[Mike McCauley]

Hi,

Not sure what your problem is but...

maybe loading of the SPI lines is too much with 2 devices connected? The fact
that just probing the clock causes misbehaviour is very odd. Does that also
happen when only the radio is connected?

Cheers.

--
Mike McCauley VK4AMM mi...@airspayce.com
Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia
http://www.airspayce.com
Phone +61 7 5598-7474 Fax +61 7 5598-7070

[Joris Hoogeboom]

Hmmm, strangely enough it only happens sometimes when probing the CLK that it fails init, I had a lot of lines on the logic analyser. Just probing the clock does not lead to failed inits on it's own apparently.

Anyway, the SPI line is heavily used by the Led driver code, which basically bit-bangs PWM across the SPI-line (ugh bad idea in hindsight), by shifting led on and off real quick with every octet. But I see no collisions using the logic analyser...

What about getting IFFERRORs? I've seen another thread in this group that had issues with that, it's coming up consistently before locking up. I know the rf22 hoperf documentation by heart by now and even been reading the Si4430/31/32 docs in hopes of finding more about the IFFERROR, but nothing..

This is a test with the debugging serials prints on:

IPREAVAL

interrupt 0 10

interrupt 80 92

IFFERROR

interrupt 10 92

IRXFFAFULL

interrupt 2 12

IPKVALID 129 55

interrupt 80 12

IFFERROR 

and a typical packet received (not coinciding with a specific serial msg up here) :

In other threads about locking up I found similar issues with the IFFERROR locking up the radio, not sure why, disabling it does not resolve it in my case. Some of them were a bit older, is there still possibility that it's deadlocking in some way? Or has that been taken care of in updates?

[Joris Hoogeboom]

Okay, I had a hunch that the led driver I'm using was not to be used along other SPI devices since it didn't tri-state it's inputs on a HIGH slaveselect line.

So I cut the traces and breadboarded in a bilateral switch (active high) and an inverter attached to the slaveselect line of the led driver, so that if not asserted, it would basically have high-impedance on CLK and MOSI.

However that did nothing, since I already cut the traces I tried a more radical test, just running all the code with the traces still cut, the outcome is that nothing has changed and it still locks up after a couple messages.

Just to be safe I also ran it off  a LiPO battery instead of the usb programmer, same thing.

Unlikely, but could a write collision in the SPI lead to a deadlock?

[Mike McCauley]

On Saturday, February 15, 2014 07:52:17 AM Joris Hoogeboom wrote:
> Okay, I had a hunch that the led driver I'm using was not to be used along
> other SPI devices since it didn't tri-state it's inputs on a HIGH
> slaveselect line.
>
> So I cut the traces and breadboarded in a bilateral switch (active high)
> and an inverter attached to the slaveselect line of the led driver, so that
> if not asserted, it would basically have high-impedance on CLK and MOSI.
>
> However that did nothing, since I already cut the traces I tried a more
> radical test, just running all the code with the traces still cut, the
> outcome is that nothing has changed and it still locks up after a couple
> messages.
>
> Just to be safe I also ran it off a LiPO battery instead of the usb
> programmer, same thing.
>
> Unlikely, but could a write collision in the SPI lead to a deadlock?

Yes, probably.

Cheers.

> > <https://lh3.googleusercontent.com/-LKpH5mFdZrM/Uvq53swm6MI/AAAAAAAAAHE/Gr
> > 3MzVAxFuQ/s1600/Screen+Shot+2014-02-12+at+01.00.55.png>

[Joris Hoogeboom]

Just wanted to let you know with the new version that has the softwarespi implementation, it all works fine and dandy together :)