"The questions relate to the example proprietary radio code provided by TI, either all possible error results are not enumerated, or they are handled by case statements that just immediately break out, so there is no indication how to handle the error condition and I have not found any guidance in the documentation. If you can point me to the documentation that specifically answers my questions, that would also be great.
I would like to have the code I am writing to be able to correctly handle any radio conditions that occur. I have not encountered any of the error conditions I list below in my current testing but since they are a possibility, the code must handle them. Also, if I understand how they can occur, they I can make them happen and ensure that the code handles them correctly.
If more or better details are needed to address my questions, happy to provide it. As always, I appreciate your help.
1.
AESCBS_oneStepDecrypt
Our proprietary protocol using CBC based encryption/decryption. The code I have written is working, specifically, for example, the result from the AESCBC_oneStepDecrypt() function is always AESCBC_STATUS_SUCCESS. But there are 3 more possibilities the function could return
case AESCBC_STATUS_ERROR: // decryption operation failed (-1)
case AESCBC_STATUS_RESOURCE_UNAVAILABLE: // decryption required hardware resource was not available. Try again later. (-2)
case AESCBC_STATUS_CANCELED: // decryption operation was canceled. (-3)
How should any of these conditions be handled?
2.
In the radio callback function for the ‘receiver’, I have encountered only two status values, PROP_DONE_OK, and PROP_DONE_TXTIMEOUT. Handling the PROP_DONE_RXTIMEOUT status is easy and straightforward, the PROP_DONE_OK leads to 5 possible status values for the message that has been queued shown below. The DATA_ENTRY_FINISHED status is what is desired and so far, always what I have observed, I would like to know what action(s) to take for the other status values if they occur.
PROP_DONE_OK
case DATA_ENTRY_FINISHED: // Radio CPU is finished accessing the entry
case DATA_ENTRY_PENDING: // Entry not yet used
case DATA_ENTRY_ACTIVE: // Entry in use by radio CPU
case DATA_ENTRY_BUSY: // Entry being updated
case DATA_ENTRY_UNFINISHED: // Radio CPU is finished accessing the entry, but packet could not be finished
start of callback furnction
void callback_RFRX(RF_Handle h, RF_CmdHandle cmdHnd, RF_EventMask e)
{
bool cleanup_receive_queue = false;
if ((e & RF_EventLastCmdDone))
{
g_got_a_RF_callback_at_RAT_time = RF_convertUsToRatTicks(RF_getCurrentTime());
RF_Op* cmdRF_Op = RF_getCmdOp(h, cmdHnd); // RF_Op (defined in rf_common_cmd.h), struct __RFC_STRUCT rfc_radioOp_s, get the 'just completed command'
// See rf_prop_mailbox.h for list of all possible radio operation status
switch(cmdRF_Op->status)
{
case PROP_DONE_OK:
…….
The other possible radio callback status values as I understand it are the following. How should they be handled?
case PROP_DONE_BREAK: // RX stopped due to timeout in the middle of a packet
case PROP_DONE_ENDED: // Operation stopped after end trigger during reception
case PROP_DONE_STOPPED: // Operation stopped after stop command
case PROP_DONE_ABORT: // Operation aborted by abort command
case PROP_DONE_RXERR: // Operation ended after receiving packet with CRC error
case PROP_DONE_IDLE: // Carrier sense operation ended because of idle channel
case PROP_DONE_BUSY: // Carrier sense operation ended because of busy channel
case PROP_DONE_IDLETIMEOUT: // Carrier sense operation ended because of timeout with csConf.timeoutRes = 1
case PROP_DONE_BUSYTIMEOUT: // Carrier sense operation ended because of timeout with csConf.timeoutRes = 0
case PROP_ERROR_PAR: // Illegal parameter
case PROP_ERROR_RXBUF: // No available Rx buffer at the start of a packet
case PROP_ERROR_RXFULL: // Out of Rx buffer during reception in a partial read buffer
case PROP_ERROR_NO_SETUP: // Radio was not set up in proprietary mode
case PROP_ERROR_NO_FS: // Synth was not programmed when running Rx or Tx
case PROP_ERROR_RXOVF: // Rx overflow observed during operation
case PROP_ERROR_TXUNF: // Tx underflow observed during operation"
