小米AX3000T路由器多设备下载失速？一招固件升级彻底解决
@[toc] 一、问题的困扰：从“满速天堂”到“龟速地狱”您是否也遇到了这样的 frustrating（令人沮丧）的场景？您新购入了一台性能强劲的小米AX3000T路由器，它拥有Wi-Fi 6和NFC一碰连等先进功能。在100M宽带下，当您连接一台设备进行下载时，速度轻松达到理论峰值（约12.5MB/s）。 然而，当家人、室友的多台手机、电脑、平板都连接上Wi-Fi，并开始同时进行下载、看视频等网络活动时，灾难发生了：所有设备的下载速度在短暂地维持满速后，会断崖式地暴跌到仅有500KB/s左右，网络体验瞬间从“高速公路”变成了“乡间小路”。 无论您是重启路由器，还是断开重连Wi-Fi，问题都可能在短时间内再次复现。这并非您的宽带问题，也不是设备问题，而是路由器本身的一个“软”缺陷。 二、原因探究：为何会发生速度断崖？在揭晓最终解决方案前，我们先分析一下导致这种问题的深层原因。这种从高速突然跌落至稳定低速的现象，通常指向路由器固件（Firmware）层面的软件Bug。 QoS（服务质量）引擎缺陷：路由器内置的QoS引擎负责智能分配网络带宽。在旧版固件中，其算法可能存...
STM32F7 使用 FAL 配置片上FLASH
[toc] 使用STM32F767芯片 加载RTT 3.15完整版，采用ENV工具，用KEIL加载工程，使用FAL配置片上FLASH，采用ARMV6编译器 优化等级-0 工程BSP目录下运行env 输入menuconfig进入菜单USER DRIVer CONFIG 是我自己编写的，没有用 从截图所示进入 使能 on-chip FLASH 从截图所示进入 按空格使能，按回车进入配置。如截图所示进行配置 进行保存 使用SCONS命令 无修改进行编译运行，有三个错误 fal_flash.c 47行修改如下 123log_d("Flash device | %*.*s | addr: 0x%08lx | len: 0x%08x | blk_size: 0x%08x |initialized finish.", FAL_DEV_NAME_MAX, FAL_DEV_NAME_MAX, device_table[i]->name, (unsigned long)device_table[i]->add...
Vscode ESP-ID 添加自定义组件解决办法
@[toc] 添加方法ESP-IDF 在搜索所有待构建的组件时，会按照 COMPONENT_DIRS 指定的顺序依次进行，这意味着在默认情况下，首先搜索 ESP-IDF 内部组件（IDF_PATH/components），然后是 EXTRA_COMPONENT_DIRS 中的组件，最后是项目组件（PROJECT_DIR/components）。如果这些目录中的两个或者多个包含具有相同名字的组件，则使用搜索到的最后一个位置的组件。这就允许将组件复制到项目目录中再修改以覆盖 ESP-IDF 组件，如果使用这种方式，ESP-IDF 目录本身可以保持不变。 我提供一种正确设置后还是无法编译通过的方法 https://docs.espressif.com/projects/esp-idf/zh_CN/v4.4.1/esp32/api-guides/build-system.html#id18可以尝试先清除工程编译再编译一次既可
KEIL5 编译器AC6 使用RT-THREAD操作系统 使用组件CmBacktrace方法+addr2line使用
@[toc] 最新解决方案：复制里面代码到对应源文件并编译既可 https://github.com/armink/CmBacktrace/pull/62https://github.com/armink/CmBacktrace/edit/master/cm_backtrace/cm_backtrace.chttps://github.com/armink/CmBacktrace/edit/master/cm_backtrace/cmb_def.h 编译目录下打开ENV工具 输入scons --pyconfig 点击Jump to List ites搜索CmBacktrace双击 配置如下，不要使用GB18030编码，AC6不支持显示，会有警告 点击SAVE CMD中显示 Loaded configuration ‘.config’Configuration saved to ‘.config’Configuration saved to ‘.config’ ENV中输入 pkgs –update 1.输入 scons --target=...
RTT各种错误排查（个人方法）
[toc] 试图切入ARM状态造成的用法Fault 问题：1.可能是内存泄漏 程序中有野指针，导致堆栈破坏； 个人工程中 排查发现为数组拷贝溢出数组大小，野指针导致堆栈破坏。 相应报错可能有： 1.RT_ASSERT 断言死机 2.rt_object_get_type((rt_object_t)thread) == RT_Object_Class_Thread) has assert failed at 都是内存泄漏，导致其他变量被改写。导致错误。 3.使用memchec命令 打印Memory block wrong: 怀疑到内存管理算法问题，改变内存管理算法。报错会不一样哦。 sr: 0x00000000r00: 0x20001268r01: 0x10000000r02: 0xf0000000r03: 0x00000000r04: 0x0801a130r05: 0x0801a130r06: 0x00000000r07: 0x0000008cr08: ...
ART-PI在KEIL的使用教程(个人笔记)
[TOC] ART-PI在KEIL的使用教程(个人笔记) 个人笔记,仅作为个人记录 第一步 下载源码 git clone https://gitclone.com/github.com/RT-Thread-Studio/sdk-bsp-stm32h750-realthread-artpi.git 网站 https://github.com/RT-Thread-Studio/sdk-bsp-stm32h750-realthread-artpi 第二步 查看源码手册说明 路径: sdk-bsp-stm32h750-realthread-artpi\documents 原理图与扩展IO说明 sdk-bsp-stm32h750-realthread-artpi\documents\board 查看UM5001-RT-Thread ART-Pi 快速上手.md 确保开发板功能正常 第三步 连接MSH串口使用控制台 xshell7 连接串口 第四步 编译keil工程 按照链接步骤执行,编译 https://art-pi.gitee.io/website/docs/#...
CUBEMXV6
[toc] CUBEMXV6.70版本 使用STM32H750 之前时钟配置报错的修改办法评论遇到的问题解决办法上述问题,版本重新选择一下 如下图所示修改既可 虽然配置变了,但是实际工程去查看对应代码没有任何修改 没有选项的按下
FREERTOS开启TICKLESS后最大只能349tick休眠的原因分析
@[toc] 空闲线程的运行时间分析原因 开启TICKLESS模式后,在PreSleepProcessing和PostSleepProcessing中打印ulExpectedIdleTime变量,即空闲时间.输出如下 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-56thy2v3-1684831702598)(TICKLESS.assets/image-20230523161450180.png)] 代码如下 123456789void PreSleepProcessing(uint32_t *ulExpectedIdleTime){ log_i("ulExpectedIdleTime %lu", *ulExpectedIdleTime);}void PostSleepProcessing(uint32_t *ulExpectedIdleTime){} 分析 为什么是349tick进入一次空闲线程? 分析FREERTOS源码,在portTASK_FUNCTIO...
stop2模式低功耗无法进入的问题分析
@[toc] 低功耗无法进入的问题分析现象 低功耗进入与退出前后加入打印函数.发现进入低功耗后立刻退出低功耗 打印代码如下 1234log_i("in\r\n");UTIL_PowerDriver.EnterStopMode( );UTIL_PowerDriver.ExitStopMode( );log_i("out\r\n"); 原因 中断标志位挂起未清除导致低功耗进入失败 分析挂起的中断标志位查找 完整的进退低功耗函数如下 123456789101112131415161718192021222324252627282930313233343536373839404142434445#define UTIL_LPM_ENTER_CRITICAL_SECTION_ELP() 扩展到:uint32_t primask_bit= __get_PRIMASK(); __disable_irq() #define UTIL_LPM_EXIT_CRITICAL_SECTION_ELP() 扩展到:__set_PRIMASK(prim...
关于RTC的玄学bug分析与解决
关于RTC的玄学bug分析与解决现象:按键长按或者连续按压导致RTC起振异常;RTC经过的时间读取出来没有变化,或者变化异常 发现:经过一下午复现排查后,按键背面为晶振区域;我摁下按键的手法会按压到晶振区域导致晶振异常;人按下按键时未按压到晶振区域.无法复现;如图 另外该现象体现在如下方面: 使用LSE为时钟源,可能导致初始化失败;看图,BootLoader成功跳转,app初始化错误; 这是错误发生位置,APP的时钟初始化; 对比APP和BL的时钟初始化以及RTC导致失败的原因分析发现. bl中仅初始化了HSE,app中还初始化了LSE,使用了RTC硬件资源导致初始化失败 检测使用RTC的时间去处理的函数,例如延时等操作,会一并异常.现象为无法继续运行下去 不在按压RTC器件后,可能现象还会出现,形变还没消失;还会出现上述情况. 得等待结束 总结: 不要接触挤压精密器件部分 硬件布线应考虑布局,按键背面不应该放精密器件
