CYRF7936 Radio Receiver problem: returns same buffered data.

[dougm007]

Hi,

I am using multiple, identical custom CY8C24894 PSoC boards, with Artaflex AW24S radio boards (using CYRF7936 radio chip), in a system. I am using the non-streaming, WirelessUSB LP driver code for the radios. One "Host" board serves as the interface to a PC, via a USBUART module, and requests 16-byte data packets from the other remote boards, each responding to a unique command for that board, such as "0x1F" for Board #1, "0x2F" for Board #2, etc. For example, the host will transmit "0x2F" to all of the boards, and only Board #2 returns a 16-byte string and the other boards do not respond. This works as designed, except that, randomly, the Host board will fail during a request for data, and return, for example, all "0x1F"s for the 16-byte packet, when requesting data from Board #1. Thereafter, regardless of what command is given ("0x1F", "0x2F", etc) the Host radio returns the string of "0x1F"s. I have written over the receive buffer data, so I know the Radio is passing these values to the PSoC each time. I have verified with an oscilloscope that the remote boards are actually transmitting "real" data (not a string of "0x1F"s, "0x2F"s, etc), but the Host radio SPI bus shows the stream of "0x1F"s being passed from its own radio to its PSoC. Once or twice, this problem will correct itself, but soon the Host will resume returning the string of "0x1F"s.

There does not seem to be a dependence on how fast data is requested and I have verified the behavior with my own C# program as well as a hexadecimal terminal emulator. As it happens, the 3.3V regulator for the PSoC and radio supply is outputting only just a hair over 3.0VDC, which I know is a bit marginal for the PSoC, but I have measured the same voltage on my CY3209 PSoC Express EVK. When this problem first occurs, a timeout I implemented for the "RadioGetReceiveState() check loop" is exceeded. Thereafter, the "RadioGetTransmitState() check loop" (used for transmitting commands to all of the remote boards) also exceeds a timeout limit.

***So to be clear, it seems that a malfunction of the Host Radio is causing it to return a string of "0x1F"s that it has buffered and is disregarding the actual, valid data being transmitted to it.

1) Can someone explain what may be happening?
2) Is there some way to very rapidly (say in less than 100msec or so) reset the Radio, or perhaps one of its registers, to rectify this problem?

I have a big demo coming up next Wednesday and am DESPERATE for a solution!!!

Regards,

"Desperate" Doug

[dougm007]

Update on this issue: I still don't know WHY the "host" radio receiver occasionally (every 1 -2 seconds in a 20msec transmit loop) "hangs" and return a string of constants (like 0x1F or 0x2F, which are command bytes I transmit with this radio to remote radios). I won't completely re-state the problem, but the remote radios actually respond to the host receiver with good data, so the host radio goes through the motions of (successfully) transmitting, though with a transmit error, followed by a receive error when it is asked to look for the remote radio response. ***However, a "RadioForceState(0x04)" clears the radio and makes it start working again.*** Of course, it would be nice to know why this happens and this is not a good long-term fix to have so much data dropped.

Doug

[dougm007]

This problem has been very frustrating, but I will leave this post with some lessons learned, that I hope will help others:

1) I had to declare transmit and receive buffers globally (outside of main(), where all modules can see the declarations) to get "streaming radio transmissions" to work at all.

2) When I put the radio receive buffer AND the radio transmit buffer on the same memory page (page 0, in my case), my application started working, just as it had using "non-streaming" transmission. Before doing this, I would usually get ONE good request for data transmission to a remote radio, with ONE good return transmission, thereafter receiving garbage, but usually the 9th byte of last good transmission received would be repeated throughout the entire packet returned by the Host radio for a receive operation.

3) I implemented "timeouts" on transmissions and receives, so not to get stuck in an infinite loop. I would check transmit or receive status, delay, check status again, etc. Keep the "delay" between checks small, like 100usec or so, so radio buffer contents are not depleted before remaining data in the packet can be loaded.

4) When the radio "hangs" (doesn't respond in a reasonable timeout and usually returns constants over-and-over), returns a transmit or receive RADIO_ERROR, or returns an unexpected number of bytes, issuing a RadioForceState(0x04) to force the radio to IDLE state got the radio working again for the next cycle.

Hope this helps someone!

Good luck,
Doug