BeeKit WirelessUART problems

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

BeeKit WirelessUART problems

3,125 Views
Balk
Contributor II
I'm using a MC13192 + GT60 SARD board (actually the PAN802154HAR - based very closely on the SARD)and have recently tried to use the BeeKit package for SMAC applications.

After loading the WirelessUART sample program on BOTH boards, I find that there are 3 problems:
1) Only one board seems to be able to TX messages to the other
2) After a few dozen keystrokes, erroneous characters seem to be sent
3) Shortly thereafter, all communication seems lost between the boards. It stays this way until I reprogram the board.

I should mention that I loaded the same identical file onto both boards.
As well, I am using a GT60, although the program is written for a GB60. I've been told by freescale support however, that the different MCU does not matter.

Any help is appreciated, thanks!
Labels (1)
0 Kudos
4 Replies

532 Views
giga
Contributor I
The Zigbee transceiver interrupts need to be disabled during the SPI access to prevent double cycles.  The problem manifested itself as loosing the clock if using the clock from the transceiver and therefore communications with the debugger was lost.  Even when it was switched to the internal clock it didn't lose comms with the debugger, but it still stopped working after the SPI cycle during a wireless transfer.  Once the interrupts during SPI were disabled everything seems to be working.
 
Not sure if that fits your set-up or not but hopefully it may help you.
0 Kudos

532 Views
Balk
Contributor II

giga wrote:
The Zigbee transceiver interrupts need to be disabled during the SPI access to prevent double cycles. The problem manifested itself as loosing the clock if using the clock from the transceiver and therefore communications with the debugger was lost. Even when it was switched to the internal clock it didn't lose comms with the debugger, but it still stopped working after the SPI cycle during a wireless transfer. Once the interrupts during SPI were disabled everything seems to be working.
Not sure if that fits your set-up or not but hopefully it may help you.



Giga, thanks so much for your replies - the following link will take you to a fairly thorough document on the PAN802154HAR module. It is based very closely on the SARD board.

http://www.panasonic.com/industrial/components/pdf/zigbee_appnote_1105.pdf

If you were experiencing the same problems as me, and disabling the Zigbee transceiver interrupts worked - it is definitely something i should try.

I have not gone into each project file in depth - may i ask exactly where I can make the neccessary changes to the software? You mention that the interrupts need to be disabled before SPI access - where exactly does this take place? And should the be immediately re-enabled once SPI access is complete?

Thank you kindly.
0 Kudos

532 Views
giga
Contributor I
I ported the Wireless UART to a QG8 and am seeing the same thing except it happens much faster (only one character needs to be sent).  I am thinking there may be something related to the stack, but I am not sure yet and have just started digging into this one.  I looked for a schematic of the PAN802154HAR and couldn't find one.  Was curious to see a comparison between the SARD, the PAN802154HAR, and my target hardware.   Do you have a schematic I can compare?  There is one pin (RXTXEN) useage that I am investigating now as well as I don't have control of it like the Wireless UART does, however, my understanding is that you can accomplish the same thing via the SPI interface to the registers.
0 Kudos

532 Views
stevasway
Contributor III
Hi Balk,
I tried the same application on my SARD hardware and I didn't find problems, maybe one of this two SARD is damaged.
Anyway you have to consider that that demo application is not a real wireless UART because there is an handshake (ACK) when you send a packet from a board to the other.
So if you sent a stream of bytes probably you don't receive all the bytes that you sent.
This is not a problem of hardware, but a software problem.

Bye
Stevasway
0 Kudos