This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] RTOS/CC2640:CC2640应用问题/UART 驱动程序

Guru**** 2609955 points
Other Parts Discussed in Thread: CC2640, SYSBIOS

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/581562/rtos-cc2640-cc2640-app-question-uart-driver

器件型号:CC2640
Thread 中讨论的其他器件: SYSBIOS

工具/软件:TI-RTOS

CC2640定制4x4应用。 CCS 6.2、ble_sdk_2_02_01_18、XDS 200调试器。 应用使用 SPI (主器件)、UART (仅在传感器校准期间进行有线外部处理器通信)和 ADC 驱动器(仅当存在外部传感器时才使用 ADC 驱动器、否则不使用)。

校准后、会进行下电上电、传感器在正常模式下运行、而不会打开 UART 驱动程序。

传入 UART 消息帧的确切长度未知。 UART 报文帧之间的时间也未知。 每个报文帧都有一个标头字节的开始、后跟一个报文帧标识字节。 CC2640与外部处理器通信时没有其他握手方法。

UART 驱动程序的当前使用:读取回调、写入阻塞模式。

应用程序顺序:

1.      如果 UART 接收引脚有活动、则只打开 UART 驱动程序。

2.      如果 UART 驱动程序被打开,则开始等待 UART 字节到达。 UART 每次读取一个字节。

3.      如果 UART 读回调触发、将 UART 事件放入 RTOS 队列中。 当前、在 swi 上下文中使用 enqueue 函数(由 UART 读取回调触发)。

4.      传入的消息帧被汇编到 RTOS 队列中。 在汇编消息时、UART 还会从 RTOS 队列写入数据。 UART 写入后、CC2640会返回等待传入的 UART 消息、直到校准完成。

5:      2个连续传入字节之间的最大超时设置为1900个时钟周期(每个时钟节拍10us)、据此丢弃传入帧。

在读取回调模式下使用 UART 需要持续读取 UART 驱动程序、除非有数据要从 UART 驱动程序写入。 UART 读取指示-1的状态错误、有时会变为0。

升级到 ble_sdk_2_02_01_18后、当传感器通过 UART 进行通信时、会报告硬故障错误。 硬故障(BFAR)的存储器位置导致未知的存储器位置。 设置 ARM 高级功能会在硬件故障时停止调试器、但 ROV 不会更新异常报告和进一步了解问题所需的信息。 此错误似乎被存在的调试语句屏蔽(不会发生硬故障异常)。

在使用 ble_sdk_2_02_00_31通过 UART 进行通信时、也会注意到一些不一致之处。 当对特定 UART 消息的响应发生更改时、这似乎会消失。 其他方面都很好。

一位 TI 工程师对项目进行审阅后、建议添加 UART 任务并在阻塞模式下读取 UART。

UART 任务仅在存在 UART 引脚活动的情况下创建、而不是在其他情况下创建。

UART 任务优先级= 2

SBP 任务优先级= 1

设置了一个信号量来提醒 SBP 任务 UART 已完成写入、因此 SBP 任务可以在 UART 消息结束时接管。

该设置正在打破 BLE 广播。 无论是否存在 UART 活动、传感器都会达到硬故障异常。 GAP 角色任务最终被阻止、并且 ROV 中显示了一个栈大小为0的未知任务。 (随附两个屏幕截图)。

使用 UART 任务与连续读取 UART 是否更好的设计? 如果这是设计固件的更好方法、如何设置 UART 任务?

还是这不是 UART 驱动程序设置和监控的问题、而所有问题都适用于 CC2640R2芯片和堆栈? 请提供建议。

谢谢、

Priya

  

 

 

 

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Priya、

    在包含在 ble_sdk_2_02_01_18和 ble_sdk_2_02_00_31中的 TI-RTOS 版本中、我没有看到 CC26XX UART 驱动程序有任何显著差异。  因此、我认为您现在看到的硬故障不是由于升级到2.01.18时 UART 驱动程序发生的变化所致。

    您在具有0堆栈大小的 ROV 中看到的任务可能是尚未构建的静态任务。  这是可以的,一旦在任务上调用 Task_construct(),它将在 ROV 中看起来正确。

    是否可以附加应用的.cfg 文件?  也许可以对某些内容进行配置、以获得有关硬故障的更好信息。  您可以检查是否已启用异常解码。  在.cfg 文件中查找类似如下的内容:

    var m3Hwi = xdc.useModule('ti.sysbios.family.arm.m3.Hwi');

    并确保 m3Hwi.enableException 设置为'true':

    m3Hwi.enableException = true;

    //m3Hwi.enableException = false;

    //m3Hwi.exHandlerFunc =空;

    此致、

    Janet

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    e2e.ti.com/.../4300.cc2640-_2D00_-exception.cfgJanet、

    在我发布到这里之前、我正在收集更多信息。

    中的 ble_sdk_2_02_00_31和 ble_sdk_2_02_01_18发生异常

    没有调试语句。 只有在之后才可能注意到此问题

    堆栈升级、但始终在那里。两种应用程序都使用了相同的应用程序文件集

    SDK。

    2.为 ble_sdk_2_02_01_18附加了 cc2640.config 文件。
    这一行也添加到了 simple_peripheral.c.

    void execHandlerHook (Hwi_ExcelContext * ctx){for(;);}

    3.两个屏幕截图用于 ble_sdk_2_02_01_18项目。

    一个是使用配置文件中的异常处理程序语句生成的、

    另一个是使用 SysMin 缓冲区的配置文件生成的。

    请注意、异常的描述在两个配置文件之间发生了变化。

    4. SysMin 配置中的 LR 将导致 反汇编中的有效位置。

    还随附了这方面的屏幕截图。

    我希望 精确地缩小异常发生的位置和时间。

    谢谢、

    Priya

      

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    最终使用这些调试方法和解决了该问题
    不同的 TI RTOS 设计方法进行设计。

    e2e.ti.com/.../2145465

    谢谢、
    Priya