[参考译文] CC115L：STX 命令上的 FIFO 下溢和 CHIP_RDYn = 1。

很遗憾、我无法打开您发送给我的链接、因此我无法正确查看您显示的数字。

如果您可以提供从 SmartRF Studio 导出的寄存器以及 TX 代码(包括您尝试发送的数据包)、这会很有帮助。 通常情况下、TX FIFO 下溢仅发生在将完整数据包写入 FIFO 之前启动 TX 的情况下(例如、如果发送的数据包长于 FIFO 大小)。

当 CSn 被拉至低电平时、CHIP_RDYn 不为低电平、表示您有硬件问题。

BR

Siri

您好、Siri、

您的链接有问题、或者无法安装免费的 saleae Logic2软件来查看文件？

以下是可直接下载的文件：

www.dropbox.com/.../34.C.05 cc configuration attachement1.Sal

www.dropbox.com/.../34.C.05 cc 普通发送连接2.Sal

www.dropbox.com/.../34.C.05 cc send with undercflow attachement3.sal

www.dropbox.com/.../34.C.05 cc send chip_RDYn 1 attachemment4.Sal

这里是 RFstudio 中的寄存器定义。 它是针对流耗进行优化的100kb 的默认配置。 只有 GPIO2更改为0x06。

# Register settings for CC115L
#     - generated by SmartRF Studio 

sub writeRegisters
{
    my $dev= shift;
    $dev->writeRegister("IOCFG2",0x06);
    $dev->writeRegister("IOCFG0",0x29);
    $dev->writeRegister("PKTCTRL0",0x05);
    $dev->writeRegister("FREQ2",0x21);
    $dev->writeRegister("FREQ1",0x62);
    $dev->writeRegister("FREQ0",0x76);
    $dev->writeRegister("MDMCFG4",0x5B);
    $dev->writeRegister("MDMCFG3",0xF8);
    $dev->writeRegister("MDMCFG2",0x93);
    $dev->writeRegister("MCSM0",0x18);
    $dev->writeRegister("RESERVED_0X20",0xFB);
    $dev->writeRegister("FSCAL3",0xEA);
    $dev->writeRegister("FSCAL2",0x2A);
    $dev->writeRegister("FSCAL1",0x00);
    $dev->writeRegister("FSCAL0",0x1F);
    $dev->writeRegister("TEST0",0x09);
}

FIFO 中的字节数正确。 我已经检查过这个。 它在提供的数据报上可见。 (由于明显的原因、我无法共享代码)

"当 CSn 被拉至低电平时、CHIP_RDYn 不是低电平、表示您有硬件问题。"

1.嗯... 现在、我们已将 CC115l 从 DUT 焊接到另一个电路板、问题仍然存在。 仅更换了 cc115l 芯片。 目前、我们正在将全新的 cc115l 焊接到电路板 DUT 板上。 (交叉替换)。 我会随时通知您。

2. A 您可以在执行命令 STX 之前在数据报上看到我们正在填充 FIFO。 FIFO 填充期间的状态为0x0F (因此一切都正确)。 而当 FIFO 被填满时、对于 STX 命令、SC 会变为高电平、然后变为低电平。 这里的状态是0xFE。 CHIP_RDYn = 1。 电源电压为3.6V、我们已在示波器上检查它是否正常(无任何干扰)

3、本产品已上市5年，我们以前没有发现过这种行为。

此致

 Maciek

我们已经焊接了全新的 cc115l 来代替从 DUT 焊接出来的那个 cc115l。 目前、我们在3小时周期内传输了700帧以上的数据。 未观察到错误！  

--编辑----

5.夜间模块传输超过8000帧，并且未发现错误。

因此、在两个模块中交叉替换 cc115l 后、erroneus 行为遵循 cc115l 芯片。

您是否有许多器件发生故障、是否存在这可能是 ESD 问题的可能性？

Siri

已找到4000个中的14个"损坏"器件... 可能更多。  

这些模块在保修期内从我们的客户那里回来、并在第二个制造步骤中找到(焊接电池并插入到外壳中)。 我们的客户具有 ESD 保护、因此我们非常谨慎、因为我们以前遇到过 ESD 问题、这些问题已经得到确认。 通常可能是 ESD 问题、但我们以前的 ESD 问题 导致 cc15l 获取极高的电流(超过500mA)(手指与天线之间的小火花足以产生此类问题)。 在这里、观察到高电流后不会出现该问题。

在我们的公司中、我们将生产测试和编程这些模块、这些模块采用可容纳16个台钳的 PCB 框架。 在测试和编程过程中，当模块为(未编程、已编程、休眠、正在发送...)时，我们将测试电流 等等)。 我们已将这个 cc115l 从 DUT (坏的那个)焊接到全新的16件框架。 与其他15个模块相比、我们的测试和编程未在该模块上显示任何干扰。

如果这是 ESD 问题、我们如何检查它？

它是否会在 Rentgen 上可见？

您是否有测试此类模块的任何步骤？  

也许我们可以将 一些样品发送到您的实验室进行进一步测试？

如果我们能说100%是 ESD、那就太棒了！ (笑声) 但我不确定。

Maciek

首先：您能否测量 CC115L 上每个引脚到"损坏"器件和"正常工作"器件上接地的阻抗并发布结果？ (您可以在 PCB 级别执行此操作)。 通常、您会看到较低阻抗上的 ESD 损坏。

您说此产品已上市5年以上。 既然您现在已经开始看到问题、您最近是否对生产线进行过任何更改？ 我觉得奇怪的是、您突然开始在成熟的生产环境中逐渐退出。 生产和测试设置是否正确接地？  是否有任何 BOM 更改？  

您好、

两个(工作和不工作)电路板上的阻抗测量值完全相等。 我真的希望这个问题可以通过阻抗检查来确定。

我已更改了模块部分中的固件。 此固件出错。 超时位处理不正确，因此如果模块未将 GDO 引脚置为有效，则没有睡眠命令，模块保持在 TX 模式。 这就是我们找到这些单元的方式。 它们通过保持恒定的 TX 打开来完全破坏与其他模块的通信。 我已修复此错误、现在已正确处理超时。 我还在主帧中发送位、已注意到该超时。 正如我之前所说的、在之前有不良行为(恒定 TX)的模块上、这个位一直显示。 有时在几个小时后，有时是微妙的、有时是有时。 在其他模块上、未观察到该位。 正如我之前所说的、错误行为是遵循 cc115l 芯片(我们已将其焊接到不同的 PCB 上)。

主要问题是在生产过程中无法检测到这种情况。 电流正确、模块正在发送数据... 即使是这个阻抗测量也没有显示任何干扰。 不多。 目前、我们有14个器件投入了4000多个生产。 如果我们能够在生产过程中检测到这一点、这不是问题... 但当设备发送到终端客户端时、这是一个大问题。

是和是。 我们以前遇到过 ESD 问题。 天线和模块上的单个火花开始消耗超过500mA 的电流。 我们检测到了该问题 、因为 电池已发热。 之后是 ESD 保护。  

基本上、我没有看到上面发送的样本所涉及的 SPI 和数据传输问题。 我不知道这是由我们(ESD)引起的问题还是由特定的 cc115l 单元引起的问题。 cc115l 错误来自不同批次的不同产品。

此致 Maciek

您可以尝试完整的 A - B - A 交换吗？ 基本而言：  

-您是否尝试在已知良好的 PCB 上移动故障 CC115L？

-您是否尝试用已知良好的芯片替换故障 PCB 上的故障芯片？  

我们已经焊接了全新的 cc115l 来代替从 DUT 焊接出来的那个 cc115l。 目前、我们在3小时周期内传输了700帧以上的数据。 未观察到错误！  

--编辑----

5.夜间模块传输超过8000帧，并且未发现错误。

因此、在两个模块中交叉替换 cc115l 后、erroneus 行为遵循 cc115l 芯片。

您是否能够向我发送一些失败的样片(如果是这种情况、请向我发送一个朋友请求、我可以向我发送您需要发送的地址)。 在开始正式的 FA 请求之前、我想先看看这一点。   

您需要裸芯片、还是我们应该将其焊接到 PCB 上？ 它应该是什么类型的 PCB？ 可以连接到 RFStudio 的评估板。 我想测试我要发送给您的所有 cc115l、并提供重现问题的解决方案。

只有芯片还可以。 我将在我的端部找到一个 EM 来将其焊接到。 我已接受朋友的请求。  

我收到了硬件。  

我想使用 SmartRF Studio、一个打开接收芯片的 EM 和一个 TRXEB。 SmartRF Studio 能够发送命令选通。 什么是重现您在使用上述内容时看到的内容的方法？  

您好、

首先、我已经发送了完整的电路板(我们的 DUT)、在上电(3.6V)后、器件应该开始发送、并且在每个误差上、焊线上都有引脚高/低。

至于您的问题、上面的逻辑图中附带了整个配置和 TX 命令。

1.我使用了针对100kb 的默认 RFStudio 配置、针对电流进行了优化。 只有 GDO2的行为更改为0x06

2.使用 SPWD (0x39)命令将下一个芯片发送到睡眠模式

3.比 I WAKEUP CC 并在1秒内向 FIFO 中填充数据并多次发送 TX 命令。

4.在几次传输后出现问题。

够了吗？

此致

Maciek

我认为这应该是足够的。 我计划在明天对此进行研究。  

我将其中一个重建器件焊接到 CC115L EM 上、并将其与 TRXEB 和 SmartRF Studio 结合使用以测试：

测试方法：

－选择100kbps 设置

-按"pktTX"初始化  

-将 IOCFG 设置为0x06

-键入随机 FIFO 内容、然后按"写入 TX FIFO"

-按 STX

-按"Write TX FIFO"

－按 STX....

我监测 GDO、请参阅最后一个图。 我不能使用此测试元代码对任何内容进行分类

您好、

感谢您进行所有测试。

作为程序员、我经常使用并听到"在这里它起作用"一句话：)。

对于这两个模块、我们有时不得不等待1.5小时以上、每10秒发送一次帧。 因此、它在第一次错误之前提供540帧。 最差的芯片是我发送给您的 DUT 中的芯片。 在上电后、通常会在几个帧后发生这一错误。 但是、somTimes 等待时间以几十分钟为单位进行测量。

此外、我还看到测试中的一些差异：

电源：您可能有来自测试板的3.3V 电压、而我们有来自电池的3.65V 电压。  

2.我不知道 rfstudio 如何处理与芯片的通信？ 它可能会对错误做出反应并执行其他步骤来发送帧...？ 遗憾的是、我无法从您发送的图中模拟 SPI 通信。 )

3.您使用哪种评估板进行测试？

此致

 Maciek

1.好的

2.好的

很遗憾、我没有任何工具可以在在线模式下连接 rfstudio。 因此、我无法测试任何可重现的图形。 我在第一个帖子中以 Saelae Logic2格式发送了所有 SPI 命令。 可以观察到、每次从 MCU 进行通信看起来都是相同的。 第二、这个问题总是在某些芯片上出现、而在其他芯片上却不会出现。 我很乐意帮助您在电路板上产生问题。 目前、我正在尝试找到这些步骤。  

最好的选择是检查我发送给您的 DUT。 它具有所有 SPI 信号、并且在每次发生错误时触发引脚选通。 在这种情况下、可以分析 SPI。 是的、在这种情况下、我们的 MCU 正在测试中... 但 SPI 看起来不错。

我正在尝试为 rfstudio 确定一些可重现的测试...

您是否能够找到重现此问题的替代方法？  

您好、

很抱歉耽误您的时间、但我被禁止访问 TI.com (编写简单脚本以刷新页面并检查商店中是否有可售器件... 我认为太多了)。

没有我找不到。 我没有开发板。 我发送的这些芯片导致了100%的问题。 最好的解决方案是将 SPI 连接到我发送给您的 DUT、然后加电。 您最多可以在几分钟内发现错误行为

此致 Maciek

我假设使用逻辑分析仪检查 SPI 线路将获得与您最初发布的图相同的图。 请您使用示波器检查线路、以检查逻辑分析仪是否提供了正确的图片(如果逻辑电平或上升/下降时间关闭、与芯片处理电平的方式相比、您在分析仪上看到的情况可能不正确。 可能是您的设计微不足道、某些芯片的设计工作正常、而其他芯片的工作不依赖于 VOL/VOH 电平。  

再次查看这些图、您不清楚是否执行以下操作：

'当 CSn 被拉为低电平时、MCU 必须等到 CC115L 使引脚变为低电平、然后才能开始传输标头字节。 这表示晶体正在运行。 除非芯片处于睡眠或 XOFF 状态、否则 SO 引脚在将 CSn 拉低后将始终立即变为低电平。'

数据表中的值。 您读取的值、即使在交易早期也不会按预期有时显示。

Siri 编写了一个代码来模仿您发布的图。 TRXEB 上 CC115L EM (包含其中一个返回的样本)中使用的硬件：

代码在无限循环中运行：

while(TRUE) {
      
    writeTest(); // Write to the test registers
      
    createPacket(txBuffer);

    // Write packet to TX FIFO with SFTX first
    cc11xLSpiWriteTxFifoWithFlush(txBuffer,sizeof(txBuffer));

    // Strobe TX to send packet
    trxSpiCmdStrobe(CC115L_STX);
     
    while(packetSemaphore != ISR_ACTION_REQUIRED);

    // Clear semaphore flag
    packetSemaphore = ISR_IDLE;

    packetCounter++;

    // Enter SLEEP    
    status = trxSpiCmdStrobe(CC115L_SPWD);
     
    // If status is for example TX FIFO Underflow (0x7F), LCD will show ERROR and the code will     
    // hang
    if (status != 0x0F)
    {
        lcdBufferClear(0);
        lcdBufferPrintString(0, "ERROR", 0, eLcdPage0);
        lcdSendBuffer(0);
        while(1);
    }
    else
    {
        // Update LCD with packet counter
        updateLcd();
    }
}

请注意、SPI 函数始终在 CHIP_RDYn 上轮询、如果未设置、代码将挂起。  

如果发生错误、代码将挂起。 此代码已在夜间运行、到目前为止、已发送了超过7M 个数据包、因此无法对我们一侧的错误进行分类。  

Siri 编写了一个代码来模仿您发布的图。 TRXEB 上 CC115L EM (包含其中一个返回的样本)中使用的硬件：

代码在无限循环中运行：

while(TRUE) {
      
    writeTest(); // Write to the test registers
      
    createPacket(txBuffer);

    // Write packet to TX FIFO with SFTX first
    cc11xLSpiWriteTxFifoWithFlush(txBuffer,sizeof(txBuffer));

    // Strobe TX to send packet
    trxSpiCmdStrobe(CC115L_STX);
     
    while(packetSemaphore != ISR_ACTION_REQUIRED);

    // Clear semaphore flag
    packetSemaphore = ISR_IDLE;

    packetCounter++;

    // Enter SLEEP    
    status = trxSpiCmdStrobe(CC115L_SPWD);
     
    // If status is for example TX FIFO Underflow (0x7F), LCD will show ERROR and the code will     
    // hang
    if (status != 0x0F)
    {
        lcdBufferClear(0);
        lcdBufferPrintString(0, "ERROR", 0, eLcdPage0);
        lcdSendBuffer(0);
        while(1);
    }
    else
    {
        // Update LCD with packet counter
        updateLcd();
    }
}

请注意、SPI 函数始终在 CHIP_RDYn 上轮询、如果未设置、代码将挂起。  

如果发生错误、代码将挂起。 此代码已在夜间运行、到目前为止、已发送了超过7M 个数据包、因此无法对我们一侧的错误进行分类。  

您好、

"我假设使用逻辑分析仪检查 SPI 线路将获得与您最初发布的图相同的图。 请您使用示波器检查线路、以检查逻辑分析仪是否提供了正确的图片(如果逻辑电平或上升/下降时间关闭、与芯片处理电平的方式相比、您在分析仪上看到的情况可能不正确。 可能是您的设计微不足道、某些芯片的设计工作正常、而其他芯片的工作不依赖于 VOL/VOH 电平。"

是的、是的。 示波器显示正确的信号电平。

'当 CSn 被拉为低电平时、MCU 必须等到 CC115L 使引脚变为低电平、然后才能开始传输标头字节。 这表示晶体正在运行。 除非芯片处于睡眠或 XOFF 状态、否则 SO 引脚在将 CSn 拉低后将始终立即变为低电平。'

对。 在第一个附件中、您可以看到芯片配置。

在第二个附件中有"正常帧发送"。 您可以看到、在 CS 低电平后、我们立即通过 cc115l 驱动了这么高的电流。 CS 低电平到 SO 高电平之间的延迟很小。 我要等待、直至变为低电平。

第三个附件在 TX 命令选通期间显示错误行为。 您可以看到 cc115l 在 CS 处于低电平后正确驱动如此高、并且在 CS 下降之前等待正确。

最后一个附件、您提到了一个问题。 但是！！！ 在 CS 处于低电平后、cc115l 不会驱动如此高的引脚、因此我等待如此低的过程会立即完成(因此实际上是极低的)。 并且 从第一个响应字节接收到是0x7F。 但这在前一帧的 TX 选通期间发生第一个错误后发生。

我已经检查过、我认为每个时序和等待环路都是正确的。 这可能是我无法看到的问题。

您好、Siri、

好的、我不理解的是：

1.故障 cc115l 已替换为新的，并已解决问题。

2.故障 cc115l 已被焊接到不同的工作 PCB 上，问题出在错误的芯片上。

3.相同的错误芯片在您的设计中工作正常(测试板)：/我和您的 PCB 上可能有什么不同...？

因此、目前我需要帮助来查找设计中的错误原因和位置。 我发送给您的 PCB 和代码(DUT)。

您能否通过  测试代码提供 SPI 图？

此致 Maciek。

请查找上面的 SPI 图。  

您是否对我发送给我的 PCB 上的测试垫上可以监控哪些节点有了概述？  

您好！

感谢您的参与。 我将对它们进行分析。

我已经向您发送了一份包含引脚说明的纸张。 不幸的是、我在这里找不到它。 可能我只是写了描述、打印并忘记了。

我记得、有一根导线焊接到 PCB 底部的测试焊盘之一。 这个应该表示错误。 (hi->LO 选通)。 可轻松检查 CC115L 引脚排列上的 SPI。  还焊接了 SPI 引脚 、可使用逻辑分析仪进行观察。 它们 连接到 MSP430的引脚：P1.2 (51)、P1.3 (50)、P1.4 (49)、P1.7 (46)、P5.5 (41)。

我前面没有 PCB。 如果我还记得、我注意到 PCB 上有相当多的测试点、并想知道这些测试点上有哪些信号可用。  

其中大多数用于编程目的。 这就是我焊接导线和金针以更轻松地插入分析仪/示波器的原因。

Torstein 和 Siri、大家好、

感谢您的持续支持。 作为客户的 FAE、我想问一下可以采取哪些措施来帮助加快查找这些错误的根本原因的过程？  

据我了解 、问题出在相关的 CC115L 芯片或特定的 PCB 设计上尚不清楚、因为一些"损坏"的器件在 EVM 上工作正常。  在 4000多个批次中、14个"破损"的器件 似乎 表明电路板上存在一些问题、可能是一些临界性稳定条件。

我假设情况确实如此、但我们能否检查这些批次是否来自不同的硅片？  
Maciek、您能否向我发送批次号码 和您的订单号？

我认为 Maciek 的以下摘要总结了我们目前的现状：

1.故障 cc115l 已替换为新的，问题已消失。

2.故障 cc115l 已被焊接到不同的工作 PCB 上，问题出在错误的芯片上。

3.相同的错误芯片在您的设计中工作正常(测试板)：/我和您的 PCB 上可能有什么不同...？

ter、您是否能够测试客户电路板上的芯片？ 根据我的理解、您只能在 EVM 上进行测试。 我认为、如果不对原始 PCB 进行严格测试并遵循相同的测试程序、就很难找到这些问题的根本原因。

感谢您、如果有问题、我很乐意将其转至电子邮件通信。

Daniel Waleniak

当我们收到客户在生产线上看到错误的芯片时、我们始终使用 EMS 进行测试。 我们的测试目标是验证观察到的误差来自芯片本身。 因此、我们希望使用已知良好的硬件(PCB)和软件进行此测试。 我们在使用此方法测试其中一个退回的器件时未发现任何故障。  

在客户电路板上对此类问题进行测试时、由于硬件和软件都未知(从我们的一侧看)、因此其正面受到限制。 如果我在电路板上进行测量、我预计会看到故障(如果不是、我就不会首先收到电路板)。 但电路板是黑盒、我能够监控一些信号、但无法更改任何内容。  

客户是否可以在电路板上运行与我们所使用的完全相同的(高级)软件？   

您好！

是的、但它有一些限制。 我们使用的 MCU 没有硬件 SPI、因此我们使用 GPIO 对其进行仿真。

这些是导致问题的 CC115L 批次：

0212095T40
1069674T41
1191567T41
1319651T41

可以编写具有所需时序的 SW SPI。 因此、应该可以将我们使用的简短示例移植到您的硬件、运行它并比较 SPI 总线上的流量、以查看您的操作是否与我们在 EM 上执行的操作相同。   

是的。 这很明显。  

我已经编写了 SPI 仿真、我确信所需的时序是满意的。 问题是我可能会错。 您能否指出我在第一篇帖子中发送的图上的时序不正确的位置？

您能否提供您希望我运行测试的代码？ 因此、它不会是我的代码。

我想的是19天前发布的代码和14天前发布的 SPI 图。 这是我用来测试返回的其中一个样本的结果、并且不会触发错误。  

我正在查看 PCB：对于 SPI 接口、它是否有一些测试点可以在导线上焊接？ 任何指针、图、我应该如何焊接在导线上？  

您好、

我想知道、自上周以来、您是否有任何反馈要分享？

谢谢、

Daniel

我今天不在实验室中、但我再次查看了原始的 Salee 图、看看时序以外的其他因素是否会导致问题。  

我从图"ccsend with underflow attachemment3.sal"中看到、数据包长度不同于第一个附件、第一个附件是无错误的 TX。 数据包长度与下溢误差之间是否存在任何关联？  (如果出现奇怪的卡在错误等情况)也出现下溢错误、您是否检查了器件在这种情况下实际发送的内容？