请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
器件型号：CC1310 工具与软件：
嗨、团队：
我在 CC1310中的代码定期(以11ms 的间隔)将18字节数据包发布到要传输的射频内核。 通常、我会按预期完成–我看到 RF_EventTxEntryDone 在 RF_postCmd ()之后大约350us、紧接着是 RF_EventLastCmdDone。 在大约20到大约800秒之间的任意位置(即、 在先前成功的事务发生之前的1/11ms * 800 = 73k 之后)后、射频内核会作出响应 更早 (大约145us 后)并发送 RF_EventLastCmdDone 事件 之间的比较 实际传输数据包或触发 RF_EventTxEntryDone 事件。 据我所知、在所有情况下、射频内核中断前对射频内核的最新指令为：
rfPostCmdResult = RF_postCmd( Cc1310_CcRf_RfHandle_g, TxOperation, RF_PriorityNormal, &TxBlocksCallback, RF_EventTxEntryDone);
我的 TxOperation 传输准备代码如下：
static void PrepareRfTransmission(uint8_t numBlocks, boolean_t highSpeed)
{
RF_EventMask result;
SetupBlockQueue(numBlocks, highSpeed);
TxEntryCurrent = (rfc_dataEntryPointer_t *)TxEntryQueue;
// RF_cmdTxHS and RF_cmdPropTxAdv must be configured differently.
if(Cc1310_RfSettings_IsHighSpeedMode() || Cc1310_RfSettings_Is4fskMode())
{
/* Address filtering feature has been leveraged to effectively extend the SYNC word, thereby preventing
* adverse behaviour arising from false syncs, which were occurring approx. once per minute. This is implemented
* on the TX side by simply lengthening the user data buffer by two bytes - the first two byte being the address
* - not by configuring the PHY differently in any way.
*/
/* Configure high speed TX command */
/* See e2e.ti.com/.../cc13
* 10-rf_cmdtxhs-behaves-differently-to-rf_cmdproptxadv-in-an-unexpected-way/3797148#3797148
* For advice provided by TI to get the HS working.
*/
RF_cmdTxHS.pQueue = &TxQueue;
RF_cmdTxHS.pktConf.bUseCrc = 1;
RF_cmdTxHS.startTrigger.triggerType = TRIG_NOW;
RF_cmdTxHS.startTrigger.pastTrig = 1;
RF_cmdTxHS.startTime = 0;
RF_cmdTxHS.pktConf.bCheckQAtEnd = 1;
RF_cmdTxHS.condition.rule = COND_STOP_ON_FALSE;
TxOperation = (RF_Op*)&RF_cmdTxHS;
}
else // "Regular" speed command
{
/* Configure CMD_PROP_TX_ADV */
RF_cmdPropTxAdv.pPkt = (uint8_t*)&TxQueue;
RF_cmdPropTxAdv.pktLen = 0; // CRITICAL. #### TODO - or else?
RF_cmdPropTxAdv.pktConf.bUseCrc = 0;
RF_cmdPropTxAdv.startTrigger.triggerType = TRIG_NOW;
RF_cmdPropTxAdv.startTrigger.pastTrig = 1;
RF_cmdPropTxAdv.startTime = 0;
TxOperation = (RF_Op*)&RF_cmdPropTxAdv;
}
TiDrv_TiGpio_SetGreenLed(1);
/* Set the TX frequency */
RF_cmdFs.frequency = Cc1310_CcRf_Frequency_g;
RF_cmdFs.fractFreq = Cc1310_CcRf_FractFreq_g;
RF_InfoVal info;
RF_Stat stat = RF_getInfo(Cc1310_CcRf_RfHandle_g, RF_GET_CURR_CMD, &info);
TiDrv_TiGpio_TestPointsWriteData(3, TIDRV_GPIO_TESTPIN_DEBUG_RAW,
TIDRV_GPIO_TESTPIN_DEBUG_NO_FRAMING, TIDRV_GPIO_DO_REENABLE_INTERRUPTS);
if(info.ch >= 0)
{
RF_flushCmd(Cc1310_CcRf_RfHandle_g, info.ch, 0);
TiDrv_TiGpio_TestPointsWriteData(4, TIDRV_GPIO_TESTPIN_DEBUG_RAW,
TIDRV_GPIO_TESTPIN_DEBUG_NO_FRAMING, TIDRV_GPIO_DO_REENABLE_INTERRUPTS);
CmdFlushes++;
}
result = RF_runCmd(Cc1310_CcRf_RfHandle_g, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, NULL, 0);
TiDrv_TiGpio_TestPointsWriteData(5, TIDRV_GPIO_TESTPIN_DEBUG_RAW,
TIDRV_GPIO_TESTPIN_DEBUG_NO_FRAMING, TIDRV_GPIO_DO_REENABLE_INTERRUPTS);
TiDrv_TiGpio_MyValidateAssert(RF_EventLastCmdDone == result, 35);
/* We always send something, whether it's Pipelined data, Regular-Speed (i.e. ACK this slot) data, or Slot Control
* Headers only. In the case of the latter, this could even be one of several Retry Slot Control Headers, as it
* takes two slots to depart from High-Speed mode.
*/
// Don't request SPI data until the main slot transmission is underway
TiDrv_TiGpio_SetGreenLed(0);
}
使用 SetupBlockQueue()、如下所示：
static void SetupBlockQueue(uint8_t numBlocks, boolean_t highSpeed)
{
rfc_dataEntryPointer_t* dataEntryPtr;
uint8_t i;
uint8_t dataEntryCounter;
uint8_t dataEntryCounterMax;
uint16_t length;
uint16_t spiBlockBytes;
spiBlockBytes = VolShare_RegMap_GetReg(VOLSHARE_REGMAP_REG_SPI_BYTES);
// Re-interpretation of simple byte array
dataEntryPtr = (rfc_dataEntryPointer_t*)TxEntryQueue;
/* We must use TxQueue and Data Entry queues as they were intended, here. This is because, although RF_cmdTxHS will
* not send queue entries back-to-back, RF_cmdPropTxAdv will, so the linked list must be established for the latter.
*/
// We do not yet know whether we'll receive more or fewer data blocks than there are entries available.
TxQueue.pLastEntry = NULL;
// High-speed mode can only send one transmission in a single Tx Operation (i.e. single preamble, key-up/down etc.)
dataEntryCounterMax = highSpeed ? 1 : NUM_DATA_ENTRIES;
if(CCRF_SETUP_BLOCK_QUEUE_ONE_BLOCK_TXN == numBlocks)
{
length = VOLSHARE_DEVCC1310_HEADER_LEN + CCRF_NUM_ADDRESS_BYTES;
}
else
{
length = highSpeed
? numBlocks * (spiBlockBytes + CCRF_NUM_ADDRESS_BYTES)
: 1 * (spiBlockBytes + CCRF_NUM_ADDRESS_BYTES);
}
// Create the linked-list of transmit entries.
for(dataEntryCounter = 0; dataEntryCounter < dataEntryCounterMax; dataEntryCounter++)
{
// Configuration of generic data entry header
dataEntryPtr->status = DATA_ENTRY_PENDING;
dataEntryPtr->config.type = DATA_ENTRY_TYPE_PTR;
dataEntryPtr->length = length;
dataEntryPtr->pNextEntry = &TxEntryQueue[(dataEntryCounter + 1) * RF_QUEUE_DATA_ENTRY_BUFFER_SIZE(1)];
if((dataEntryCounterMax - 1) == dataEntryCounter)
{
dataEntryPtr->pNextEntry = TxEntryQueue;
}
dataEntryPtr = (rfc_dataEntryPointer_t*)(dataEntryPtr->pNextEntry);
}
TxQueue.pCurrEntry = TxEntryQueue; // Current entry is the first in the queue
// Determination of final entry is more involved, since that may not yet be possible.
if(highSpeed || (numBlocks <= 1))
{
TxQueue.pLastEntry = TxQueue.pCurrEntry;
}
else if(numBlocks <= dataEntryCounterMax) // Traverse the linked-list to find the final Tx entry.
{
dataEntryPtr = (rfc_dataEntryPointer_t*)TxEntryQueue;
for(i = 0; i < numBlocks - 1; i++)
{
dataEntryPtr = (rfc_dataEntryPointer_t*)(dataEntryPtr->pNextEntry);
}
TxQueue.pLastEntry = (uint8_t*)dataEntryPtr;
}
/* else ... last block is at least one full wrap of the circular block queue - must defer assignment until
* we're on the last wrap.
*/
LastEntrySet = TxQueue.pLastEntry != NULL;
}
我有：
- 验证(立即) rfPostCmdResult！= rf_ALLOC_ERROR (-2、在\simplelink_cc13x0_sdk_4_20_02_07\source\ti\drivers\rf\rf.h 中定义)
- 已验证、当 EventLastCmdDone 事件发生并在回调 TxBlocksCallback()中被识别为该事件时、TxEntryCurrent->length 是我预期的值(16 + 2个地址[过滤]字节)。
- 虽然在准备 TxOperation 和实际使用 RF_postCmd ()()发布 TxOperation 之间存在射频内核命令,但我不明白这些命令会如何导致将来的 RF_postCmd ()失败。
它就像 TxOperation 被准备和发布它之间的某种事情破坏了一样、然而 TxEntryCurrent -> length 字段既不为零、也不是我预期的值(16 + 2 = 18)。
这可能是什么原因造成的？ 我可以执行哪些调试来(帮助)对此进行诊断？
请参阅随附的图片、了解更多详细信息。
TIA 提供任何帮助。
此致、
Sean。
