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:UART 回调硬故障

Guru**** 2611385 points


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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/577407/rtos-cc2640-uart-callback-hard-fault

器件型号:CC2640

工具/软件:TI-RTOS

CC640 4x4定制板、ble_sdk_2_02_01_18、tirtos_cc13xx_cc26xx_2_20_01_08、

CCS 6.2、XDS 200调试器。

自定义应用在读取回调模式下使用 UART 驱动程序。 UART 接收

一个字节。 它还使用 SPI 和 ADC 驱动器。 UART 仅在传感器期间使用

校准以通过有线连接与外部处理器通信。

当将 ble 堆栈升级为使用 ADC 驱动程序时、传感器将到达

硬故障强制总线故障 PRECISERR。 超时的上限

通过 UART 接收的字节增加、该错误消失。

但是、处理了 UART 回调例程中的一些调试语句

通过 RTOS 队列(粘贴在下面带下划线并以粗体突出显示)。 时间

删除了这些语句、总线故障错误将再次发生。 任务堆栈

 如果发生总线故障、ROV 中会出现溢出、但不会出现溢出。

这些语句调试不会影响传感器的稳态处理。 传感器

还能够通过  3小时校准过程和维持 UART 通信

恢复稳态运行。

为什么固件对是否存在这些调试语句很敏感? 可以

这表示某种类型的任务堆栈溢出? 或者它们是否有助于唤醒

通过 RTOS 队列处理的函数中的 UART 驱动程序活动?

当包含多个字节的消息时、UART 回调停止工作

除非 RTOS 队列函数由这些调试语句唤醒、否则将收到该消息。

谢谢、

Priya

静态接收 UartMsg (uint8_t 值)

   静态 uint8_t i、长度= 5;

 

   system_printf ("\nvalue="%x clkCntDiff =%d clkCnt=%d pekCnt=%d"、value、clkCnt-pitekCnt、clkCnt、pitekCnt、pitekCnt);

 

 

 

静态 UART_enqueueMsg (uint8_t 值)

   sbpEvt_t *pMsg;

 

   //创建消息的动态指针。

 

   if (pMsg = iCall_malloc (sizeof (sbpEvt_t)))

   {

       pMsg->HDR.EVENT = UART_MSG_EVT;

       pMsg->HDR.state =值;

 

       PIN_setOutputValue (PinHandle、Board_HGM_OUT、1);

       //将消息排队。

       Util_enqueueMsg (appMsgQueue、sem、(uint8*) pMsg);

   }

 

静态 SendUartMsg ()

      //通话模式确认

      if (UART_Rx_BUf[0]= 0x55){

             uint8 txbuf[]={0x07};

             UART_WRITE (UART、txbuf、1);

             PIN_setOutputValue (PinHandle、Board_HGM_OUT、0);

             处理 UARTMsg = 0;

             waitForUARTMessage();

             返回;

         }

 

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

    您是否会想到压缩和共享您的应用程序、以便我更好地理解?

    当您收到 PRECISERR 总线故障时、正在访问哪个存储器位置? 这可以输出到控制台、也可以存储在总线故障地址寄存器(BFAR) 0xE000ED38中。

    Derrick
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我可以通过电子邮件向您发送压缩的应用程序吗? 解码后的异常的地址为0x3200310。
    此地址不会导致反汇编中的任何位置。 我不记得看一下 BFAR、
    它可能具有相同的地址。

    我尝试了我最近在这里发布的 BLE SDG 的一些调试。

    e2e.ti.com/.../575078

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

    Priya、

    在调试视图中 、使用断点 模块添加硬件观察点。 使用位置:0x3200310和内存:任意。



    运行应用程序。 应用程序应在尝试读取/写入该存储器位置时中断。

    Derrick

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

    Derrick、

    此帖子附带三个屏幕截图:

    在应用程序运行之前显示的有关 UART 写轮询的错误消息

    调试的。 (如果 debug 语句就位、则不会显示此消息、

    我今天已将其注释掉)。

    2、ROV 上的解码异常地址:

    3、此处是添加硬件断点手表后应用暂停的位置:

    我将很快向您发送项目。 我感谢您可能需要分享的任何见解。

    谢谢、

    Priya

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

    当您增加波特率时、您会观察到什么类型的行为?

    如果将"Debug"语句替换为 Task_sleep (5)、该怎么办?

    我还注意到正在从 Swi (UART 读取回调)调用 malloc。

    您能否增大 SimpleBLEPeripheral_taskFxn 的堆栈大小并观察 ROV 中的任务堆栈峰值?

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

    德里克--

    我能够将 PIN_setOutputValue 替换为 Task_sleep (5)。

    如果 receiveUartMsg (uint8_t 值)内的 System_printf 为

    传感器将保持在适当的位置、并按其应有的方式进行通信。 将其替换为 Task_sleep

    或将其删除会导致相同的硬故障错误。

    我还将 SBP_TASK_STACK_SIZE 增大到了800。

    在进行这些编辑后、传感器会响应外部处理器

    进行通信。

    随附了任务 ROV 的屏幕截图。

    我感谢您的任何见解。

    谢谢、

    Priya

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

    Priya、

    在您的接收器 UartMsg 和 Clock_getTicks()中需要注意的一点是:返回的值在达到可存储在32位中的最大值后将回绕到零。

    根据观察结果,我怀疑 UART_READ()被称为数字时间,这可能会增加堆栈大小。 system_printf()是一个耗时很长的密集型调用。 我建议添加 Task_sleep()的原因是为了查看 System_printf()是否只是导致了无意的延迟。 也就是说、Task_sleep(5)可能过短。

    尝试多次将 System_printf()替换为 Task_sleep()。

    我还注意到、标记为"..."的任务 fxn 仍在吹扫它的堆栈、但我无法在您的应用中识别它是什么? 你有什么想法吗?

    Derrick

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

     Derrick、

    以10us 节拍为单位的32位转换为几乎12小时的时间。

    请告诉我这次的翻译是否不正确--成功的校准

    过程不会超过2-3小时。

    下面的屏幕截图显示了_asm_任务中的下拉菜单。

    此版本的应用程序中不使用数据记录变量。

    校准期间实字节进入 UART 的时间和频率

    不是完全已知的。 是的、正在通过连续读取 UART

    只有在真正接收到一个字节后、才会进行回调。

    我将介绍 system_printf 所需的时间、以确定延迟

    本声明提供了相关内容。 希望它不会这么大

    与外部处理器的通信中断。

    如果您需要任何进一步的信息或想了解任何其他信息、请告诉我。

    谢谢、

    Priya

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    感谢 Derrick 提供定制项目审核和支持!
    非常感谢您及时的帮助。

    使用中的 UART 任务消除了硬故障异常
    取代了持续的 UART 监控。 在这方面需要学习很多东西
    调试的方法。 并且、该驱动程序初始化将被丢弃
    如果用户独立打开 PIN 表。

    Priya