RT-Thread / RT-Thread/rt-thread

FRDM-MCXN947的CAN驱动发送一帧后阻塞

Open
#8,822 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
12.2k
Forks
5.4k
Avg merge
4d 12h
Merged PRs (30d)
40

Description

环境

芯片:NXP-MCXN947
开发板:FRDM-MCXN947
BSP:nxp->mcx->mcxn
工具链:Keil 5, ArmClang V6.21
RT-Thread版本:5.1.0

现象及复现步骤

调用 rt_device_write(can_dev, 0, &msg, sizeof(msg)); 导致阻塞

在编写CAN外设测评时,简单复制了RT-Thread官方文档提供的CAN示例代码,可以正常发送一帧ID为0x78的CAN数据帧

但是对设备写入函数rt_device_write进行简单的for循环发送的时候却出现了阻塞,第一条写入函数后的代码均无法执行,尝试取消掉for循环,直接在rt_device_write后加入rt_kprintf也同样无法打印任何内容。

目前已知

第一次排查

5.1.0版本的mcxn提供的bsp文件中drv_can.c中,flexcan_callback函数有部分被注释,尝试取消注释。
image

并且drv_can.c中的CAN发送函数使用的是NXP提供的FSL库中的阻塞发送函数,推测该函数不能触发发送完成中断。
image

于是作出如下更改:(红框为原有发送函数,绿框为修改后的函数)
77f3033240a447ae373ab7def3b6fe1

修改后的发送函数确实可以运行至flexcan_callbackkStatus_FLEXCAN_TxIdle分支

但是rt_device_write(can_dev, 0, &msg, sizeof(msg));仍然有阻塞问题。

第二次排查

发现更改rt-thread/components/drivers/can/can.c中第169行的等待时长可以解决该问题,但是此方法不严谨,不适合作为解决办法。
can.c已经在RT-Thread源代码中存在时间较长,不应有此类问题,推测是MCXN947的bsp中存在某些错误导致,特此提出issue希望RT-Thread官方能协助排查此问题。
同时我也将过程记录下来发在RT-Thread论坛,详见:

https://club.rt-thread.org/ask/article/ef0ab0d46a298ca5.html

(第一次发issue,如有错误还请见谅🙃)

image

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the blocking call on the FRDM-MCXN947 with RT-Thread 5.1.0, then inspect the MCXN BSP's drv_can.c, especially flexcan_callback and the CAN send path. Compare the blocking and modified send behavior, and inspect components/drivers/can/can.c around line 169. Done means repeated rt_device_write calls return without blocking while CAN frames still send correctly.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
embedded-iot, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.