完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
在编写同时使用uart和ota的程序中,发现进入串口中断后导致panic,提示如下:
Guru Meditation Error: Core 0 panic'ed (Cache disabled but cached memory region accessed).经过一顿凶猛的排错分析,是因为uart的中断函数uart_rx_intr_handler_default内调用uart_hal_is_tx_idle宏导致的。 uart_hal_is_tx_idle宏是uart_ll_is_tx_idle的别名,而uart_ll_is_tx_idle定义如下:Code: Select all static inline bool uart_ll_is_tx_idle(uart_dev_t *hw){ typeof(hw->status) status = hw->status; return ((status.txfifo_cnt == 0) && (status.st_utx_out == 0));} 由于uart.c多处调用这个函数,所以编译器自作聪明地把它编译成了非内联函数(意图是减少代码占用?),且elf能找到uart_ll_is_tx_idle标号。uart_ll_is_tx_idle函数被安排在默认的flash地址,最终导致了运行时panic。 我的临时解决方法是,在uart.c文件里加入如下声明:Code: Select all static inline bool uart_ll_is_tx_idle(uart_dev_t *hw) __attribute((always_inline)); 如此以来uart_ll_is_tx_idle不会被编译为非内联函数,经测试问题解决。 但是,希望乐鑫官方把idf内源码中的inline关键词都替换为__attribute((always_inline)),因为inline关键字不可靠! 期待下次idf版本更新能解决此bug,自己修改idf源码真的是权宜之计、临时之策。 |
|
相关推荐
1个回答
|
|
在这种情况下,我们需要采取以下步骤来解决问题:
1. **检查代码中的inline函数**:首先,检查您的代码中是否有使用`inline`关键字的函数。这些函数可能会被编译器优化,导致它们被放置在Flash存储器中。如果这些函数在中断服务例程(ISR)中被调用,可能会导致访问未被缓存的内存区域。 2. **将inline函数移动到RAM中**:如果发现有inline函数在ISR中被调用,您可以尝试将这些函数的实现从Flash移动到RAM中。这可以通过使用` IRAM_ATTR`宏来实现,例如: ```c __attribute__((section(".iram1"))) void inline_function() { // 函数实现 } ``` 这将确保该函数的代码被放置在RAM中,而不是Flash。 3. **检查中断服务例程中的其他问题**:除了检查inline函数外,还需要检查ISR中的其他潜在问题。例如,确保在ISR中没有使用可能导致堆栈溢出的大型数据结构,或者确保ISR中的代码没有执行时间过长。 4. **优化代码结构**:如果可能的话,尝试优化代码结构,以减少在ISR中执行的代码量。这可以通过将一些操作移出ISR,或者使用任务调度器来实现。 5. **使用调试工具**:如果问题仍然存在,您可以使用调试工具(如ESP-IDF的gdb)来进一步分析问题。这可以帮助您找到导致错误的具体代码行。 6. **更新固件和工具链**:确保您使用的ESP-IDF和工具链是最新版本的,因为新版本可能修复了一些已知的问题。 |
|
|
|
只有小组成员才能发言,加入小组>>
545浏览 6评论
457浏览 5评论
有没有办法在不使用混杂模式的情况下实现Wifi驱动程序接收缓冲区访问中断呢?
438浏览 5评论
441浏览 4评论
411浏览 4评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-11-22 11:15 , Processed in 0.758516 second(s), Total 48, Slave 41 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号