Zigbee IRQ causing RS232 Problems

[mjcoury]

I have a very interesting problem...

I have a gateway module tied to a PC via RS232 @ 115200

I have zigbee messages from no less than 4 devices. These messages are slow to come in (greater than 250 ms in between a message from each device, sometimes seconds) and some are responses to messages sent out.

These messages are converted in the gateway to RS232 @ 115200 and sent to the PC.

The PC in return sends messages over RS232 @ 115200 back to the gateway.

It "APPEARS" that the SMAC masks interrupts at somepoint (my guess when the Zgibee IC is RX'n a message)and the message from the PC to the gateway over RS232 will be missing parts or in some cases, the end of string byte will be missed and the next message will be cacatinated to the first.

My first inclination was to use the RTS and CTS Lines of the RS232 port. I have not been successful getting codwarrior to compile any change to the driver.c file I get a error C2801 missing '}' this is mind blowing, I cannot compie if i add asm("nop"); to the driver.c file... without the ability to assert a RTS break at the start of the interrupt, I have no way to use this method as a solution..

Any ideas?


Thanks

[bigmac]

Hello mjcoury,

Do you actually get over-run errors?  Does the problem persist if you reduce the baud rate?  This may be the penalty of using such a high baud rate - if interrupts are disabled for more than about 80 microseconds there would be a problem.  I assume that the execution time of one or more ISRs may exceed this value.

I also notice that the SCI interrupts are of relatively low priority.  It might be feasible to examine the state of the SCI receive flag at the beginning of other ISRs, to give higher priority to the received SCI data - provided this is not detremental to these ISRs.

On the issue of hardware flow control, is the CTS output signal actually implemented on your board?  Not sure about the reason for your compile errors.  Why not post the section of code where you have the problem.

Regards,
Mac

Message Edited by bigmac on 2006-06-07 11:25 AM

[mjcoury]

The error is the following:

I am Rx SCI input at the time that I am transmitting or recieving Zigbee Messages. I look for a complete string that terminates in a CR & LF. if the timing is just right, i will be missing values in the middle of the string, or I will be missing the CR & LF and then the next string is attached to the damaged string.

The problem actually has been here at 38400. We actually increased the baud rate to 115200 to try to fix it, thinking we were having throughput problems

Looking for the SCI Rx flag is an interesting idea, but we loose more than one character (it appears)at any given time, so polling at the beginning may not be the "best" fix.

on the 13192-SARD, Port A controls two lines of the DB9 connector which correspond to RTS and CTS - so it looks feasable.

the compile problem is located in drivers.c of the SMAC provided by freescale.

/**
* Copyright (c) 2004, Freescale Semiconductor
* Freescale Confidential Proprietary
*
* File name : drivers.c
* Project name: SMAC (Simple Media Access Controller)
*
* Department : Freescale Radio Products Division
*
* Description : This is the SMAC C source driver file for the HC(S)08 MCU and
* MC13192 transceiver.
* The driver controls all interfaces to/from the MC13192 by the SPI, selected
* interrupt source and MCU GPIO's assigned to other MC13192 pins.
* The SMAC driver is the lowest layer of C code.
* Actual hardware interconnects from the MCU to the MC13192 are defined in the
* MC13192_hw_config.h header file.
*
* $Author: r01160 $
* $Date: 2005/07/29 03:30:40 $
* $Name: $
*/

That is the header for the code. I am not able to compile any change to the beginning of the ISR....

I've tried for grins, asm("nop"), PTAD_PTAD0 = 0, I am not doing something right....


Thanks,


Mike

[bigmac]

Hello Mike,

I am not familiar with your board, but I believe that communications between the MCU and the 13192 uses the SPI, with the MCU as the master.  So the MCU has control over all SPI operations.  What is the specific interrupt used for these communications?  Is the ISR processing likely to take more than 80 microseconds?  If so, this would be a very long ISR.

Another issue could be the presence of timer interrupts, since these have higher priority than the SCI interrupt for the serial port.  Could there be any reason for an associated ISR processing to be prolonged?

Can I presume that the existing ISR for the SCI receive interrupt simply clears the interrupt flag, reads the incoming character value, places it in a FIFO buffer, and then exits?  This assumes that the processing of the contents of the receive buffer would occur outside of any ISR.

Since the read and storage of an incoming serial character should be a quick process, there is probably no reason the same thing can't be done at the beginning of other ISRs in the event that the RDRF flag for the SCI is set.  This should prevent the possibility of over-run errors due to the ISR processing time, and without the complexity of re-enabling interrupts within an ISR.  In the event of a very lengthy ISR (not sure why this would be so) you mignt need to test the RDRF flag more than once throughout the ISR.

Still not sure about your compile problem - I would need more information than the big long comment of your last post - perhaps the actual C code of the ISR of concern.

Regards,
Mac

[mjcoury]

There is a ISR fired when the Zigbee has recieved data. Then the MCU as you correctly stated performs the SPI (Master) trasnfer of data. I don't know where yet but in the SMAC code there is a point where Interrupts are re-enabled. I can recieve messages of sizes up to 40 - 60 characters... which could take up some time. over 80 us? I would guess so..

As it stands there is a bit of code in the SCI Rx ISR... not a good idea I know.. i need to move it out.

The compile problem occours in the drivers.c code of the SMAC 4.0 package provided by freescale, I could attach the drivers.c file but it would be (i think) pretty useless since it would never compile on its own)

Mike

[bigmac]

Hello Mike,

When the Zigbee receives data, which interrupt is used?  Is the SPI master transaction under SPI interrupt control?  I think that this shouldn't be necessary for a master, especially if a fast SPI clock rate is used.

I was assuming that interrupts would be disabled only during the actual ISR processes.  If they are being disabled outside of an ISR, this might be the problem.  I might be wary of them remaining disabled while multiple bytes to or from the Zigbee are processed.

Your reference to receiving messages of 40 to 60 characters - I assume you mean from the SCI, rather than the Zigbee.  At your SCI baud rate, 40 characters would take about 3.5 milliseconds.

The drivers.c file should compile on its own provided any (non-standard) header files referenced are also available.  My understanding is that you have a compiler problem, rather than a linker one.

Regards,
Mac