Part Number: LAUNCHXL-CC1352P
Recently we tried to increase amount of messages flowing through our test network, and every time we started tests one by one every board stopped receiving messages. We checked command status and it was PROP_ERROR_RXBUFF. What I understand from description of this error (No available Rx buffer at the start of a packet) is that assigned queue was too small and RFCore tried to put new message in it but it was full. What I don't understand is why after this error occurs, posted Rf_cmdPropRx doesn't call callback when any new packet is being transmitted by other board. After flushing all commands and posting Rf_cmdPropRx its status changes to ACTIVE (0x02) and we are even able to get proper rssi read, but no received message callback after this error. Is there any way to somehow configure RFCore to not block receiving messages after this error?
I cannot see why you should not be able to receive any callback after having the PROP_ERROR_RXBUFF status. I have done several tests using the rfPacketRX example from the SDK, and modified it so that it have gotten status set to PROP_ERROR_RXBUFF, but in all cases I can always receive the next packet.
To be able to get an overflow, I made the buffers 5 bytes to small for the larges packets the radio could receive:
#pragma DATA_ALIGN (rxDataEntryBuffer, 4);
NUM_APPENDED_BYTES - 5)];
MAX_LENGTH + NUM_APPENDED_BYTES - 5))
/* Failed to allocate space for all data entries */
The default code example will not enter RX again if it for some reason (for example if status is PROP_ERROR_RXBUFF), so I modified it to run the RX command again in case it exits RX:
/* Enter RX mode and stay forever in RX */
RF_EventMask terminationReason = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropRx,
// A stand-alone radio operation command or the last radio
// operation command in a chain finished.
// Command cancelled before it was started; it can be caused
// by RF_cancelCmd() or RF_flushCmd().
// Abrupt command termination caused by RF_cancelCmd() or
// Graceful command termination caused by RF_cancelCmd() or
// Uncaught error event
uint32_t cmdStatus = ((volatile RF_Op*)&RF_cmdPropRx)->status;
// Packet received with CRC OK
// Packet received with CRC error
// Observed end trigger while in sync search
// Observed end trigger while receiving packet when the command is
// configured with endType set to 1
// Received packet after having observed the end trigger; if the
// command is configured with endType set to 0, the end trigger
// will not terminate an ongoing reception
// received CMD_STOP after command started and, if sync found,
// packet is received
// Received CMD_ABORT after command started
// No RX buffer large enough for the received data available at
// the start of a packet
// Out of RX buffer space during reception in a partial read
// Observed illegal parameter
// Command sent without setting up the radio in a supported
// mode using CMD_PROP_RADIO_SETUP or CMD_RADIO_SETUP
// Command sent without the synthesizer being programmed
// RX overflow observed during operation
// Uncaught error event - these could come from the
// pool of states defined in rf_mailbox.h
I can with this code send packets that are not room for in the data entry and status will be set to PROP_ERROR_RXBUFF, but the next packet I send of proper size, will be received OK.
If you are not able to solve your problems based on the code I have posted, you should make a small example based on one of the default examples in the SDK, that fails, so that we can do some debugging here.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Siri:
The problem is that we never sent packets that could exceed buffer length of one entry. And Rx commands maxPktLen was also set to avoid PROP_ERROR_RXBUFF. The board just randomly stops receiving new packets. We were able to somehow solve this problem. Before solving the problem, callback from rx command had simple processing and placing received packets in queue written by us, so it went from dataQueue to processing it to our own structure and then into our queue. Now the callback does nothing and lowest priority task just checks status of current data entry and does the same thing as the callback used to. Is it possible that because operations in radio callback was so long something could just went wrong? My assumption is that when a lot of short packets were being received not every callback was called and some packets was left in the queue and after some time the queue was full because only callback was taking those messages from queue and after omitting NUM_DATA_ENTRIES callbacks queue was full with not processed packets.
In reply to Piotr Klimkowski:
First of all, you RX code should not only handle the packets you are sending. It should handle all kinds of packets. That means that even if your transmitter never sends a packet longer than 30 bytes, the receiver can find sync word in noise and interpret the next receive data (noise) as the length byte. If this is a value larger than 30, you either needs to filter it away using length filtering, or you need to make sure that your data entries are large enough to receive the complete packet (length byte + 255 data bytes + status byte).
If you have made sure that the data entries are large enough to handle the packet sizes that you have allowed the radio to received, you still need to make sure that you are emptying the data entries fast enough so that there is room for the next packets received.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.