0xFE frame error interrupts SPI transfer

Hello,

I use XBee Wi-Fi Module in SPI mode.
https://www.digi.com/products/xbee-rf-solutions/2-4-ghz-modules/xbee-wi-fi

Firmware has been updated to version 2026.

I have developed a program based on PIC MCU which sends sensor data close to 1Mbps over SPI interface using UDP from the PIC to the PC. It works fine.

However, occasionally the 0x20 frame sent by the MCU to Xbee is lost due to network traffic. Each frame is 1393 bytes long.

In the event that the frame is not sent correctly the Xbee notifies the MCU using a short 0xFE Frame Error message.

I send messages in the opposite direction from the PC WiFi interface to the PIC MCU using frame 0xB0. These are short configuration messages that are sent very rarely.

I use positive edge interrupt on pin 19 SPI_nATTN on the throughole unit to notify the PIC that there is a new 0xB0 configuration message in the buffer.
Unfortunately there is no way to distinguish the arrival of a Frame error message 0xFE from the true configuration message 0xB0.
In both cases the MCU is interrupted. MCU needs to process the received message.

When the MCU is interrupted by the 0xFE message by the undelivered previous frame 0x20 it interrupts SPI transfer of the subsequent frame 0x20 and the cycle repeats indefinitely with many frames from MCU failing to transmit.

What should I do?
Should the interrupt to the MCU (caused either by 0xFE or a true configuration message 0xB0 from the PC be masked while transmitting the outgoing message 0x20 so that the 1393 byte frame can be sent without interruption?
Is there a way to disable 0xFE altogether?

Should the incoming message (whether 0xFE or 0xB0) be processed and distinguished while simultaneously transmitting outgoing 0x20 message?

What is the right data flow in this case?

Thank you,
Alex.

Your last option is what should be done. IE your buffer should be able to handle both incoming and outgoing messages.

Hello mvut,

I have difficulty understanding your reply.

My last option…
Do you mean storing entire received frame in a separate buffer. However then the PIC MCU would need to stop, analyze, every byte of the 1393-byte long frame and draw a conclusion as to what has caused an interrupt in the first place.
This extra analysis process which will then happen quite frequently and will defeat the idea of sending sensor data at fast rate.

Instead of sending sensor data the MCU will spend all of its computing power analyzing 0xFE frame error messages.

How do I suppress these frame error messages?
Please explain.

Thank you.
Alex.

Yes that is exactly what I am saying. The XBee in this case is nothing more than a cable. So it is your processor and your processor only that has to determine this information.