出出啊
出出啊
It is Not the Mountain We Conquer, but Ourselves

注册于 4 months ago

回答
627
文章
13
关注者
39

位数少了丢精度。这个文件不是给人看的,是给机器看的,纠结这个没意义。

这个问题,有全项目代码没有?这两行代码能知道这么严重的问题根源出在哪儿?

八成是应用代码不严谨,在这个平台上跑过去了,换另外一个平台就不行。

阻塞函数本身就是这个特性啊,它不管你有没有拔掉网线。如果需要检测这个,就不能使用阻塞方式。超时退出后要么检测硬链接,要么使用心跳包和服务端通信判断网络是否联通。

arm-none-eabi-gcc: error: CreateProcess: No such file or directory

这是没找到 gcc 啊

你那个函数怎么定义的,来一行函数名定义的代码。

很多人反映过类似的问题,可能相关的线程已经瘫痪了,但是其它线程还跑着。怀疑驱动里有地方有内存越界写的地方,但是一直没找到。

读写放到一个线程里特清晰,也安全。多线程共享io,读写加锁是很有必要的。
一个外设,没有必要减少打开关闭操作,这样不更快吗?

哪个文件包含了 finsh_config.h ? 这个文件可能不是必须的,尝试改改去掉它,或者把它里面重复定义的宏删掉。

这种问题,检查你所有申请的内存,有没有溢出的,越界写内存的。
明显是内存堆被破坏了,free的时候出错。

有缓存的啊,中间不一定有多少级缓存的。读文件数据少的时候,可能是从缓存返回的,不一定每次都读扇区。

这个问题很严重啊。
do rt_hw_spin_lock initialization.
这个之后轮到初始化啥了?
能定位出错的位置吗?

第一个错误,错误来源于一个应用文件,先不说 'tfm_ns_lock.h' 这个头文件所在路径有没有添加,那个 c 文件可以不编译的,先删掉再说。
第二个错误,没有添加对链接文件?

事出反常,必有妖孽
这种问题只能一部分一部分排查

  1. list_thread 结果的 status 和 error 列,没有任何参考价值。当在 finsh 里执行 list_thread 命令时,running 线程肯定是 tshell ;无论任何时刻, idle 线程总是 ready 状态。其它线程看情况。error 列几遍看到非零值,也并不能说明什么(至少目前是这样,不代表三四年之后还会是这样)
  2. 有源码吗?我真的特想知道你们怎么做到的,把工作线程跑飞了。
  3. 目测,你的线程名8个字节了。减少一个试试吧。

回到
顶部

发布
问题

投诉
建议