其它应用

华芯微特32位MCU

一、关于变量数组数量定义

在应用中，定义数组变量或其它变量时，需要注意不要超出MCU的RAM大小。如：

有客户应用SWM320系列是，定义了“uint32_t TEST_Buffer1[65536];”临时变量，编译过程中不会出错，但实际应用中MCU没有运行起来，就是定义了256KB的临时变量，超出了芯片的128K大小，此时程序跑飞，连接SWD也出现不可靠现象。重新下载更新程序时，需要争抢在程序跑飞之前，比如点解KEIL下载，然后快速按最小系统板的“RESET”按键，可以有机会进行正常的下载。

如果定义的是全局变量，直接编译会提示以下出错：

.\out\SimplUART.axf: Error: L6406E: No space in execution regions with .ANY selector matching main.o(.bss).

.\out\SimplUART.axf: Error: L6406E: No space in execution regions with .ANY selector matching startup_swm320.o(STACK).

.\out\SimplUART.axf: Error: L6406E: No space in execution regions with .ANY selector matching system_swm320.o(.data).

.\out\SimplUART.axf: Error: L6406E: No space in execution regions with .ANY selector matching stdout.o(.data).

.\out\SimplUART.axf: Error: L6407E: Sections of aggregate size 0x4100c bytes could not fit into .ANY selector(s).

二、关于串口的初始化应用

在对串口应用时，通常会从例程工程中拷贝串口的初始化应用，然后根据实际应用进行端口调整，还需要注意如下：    --2021.5.25

否则，调试过程中会出现串口无输出现象。

三、通过SWD端口找不到芯片内核的排除

1、检测下SWD端口的硬件连接，是否连通，有无短路、悬空？

2、MCU的供电是否正常，芯片工作是否正常？

3、SWD端口软件上是否有进行重置？

4、ISP端口是否加了上拉？具体的ISP端口，查看规格书中的“ISP及FLASH操作”章节。

5、软件上是否应用SLEEP功能？SLEEP状态下，需要进行唤醒后，可以进行正常SWD连接。

6、软件上是否应用了WDT功能，但没有喂狗动作引起芯片不断复位。

以上检查都没有问题，可以通过ISP方式进行擦空，恢复出厂状态后再进行SWD方式连接。

---2021.5.26

四、Keil5打开Keil4的工程

注意：SWM1xx、SWM2xx、SWM32x系列MCU 的例程库是采用MDK Keil4进行编写，在采用KEIL5打开例程工程时可能出现兼容性冲突，出现如下“图F4.4.1”界面，点击“确定”进行工程的迁移。   ---2021.6.1

                           图F4.4.1

具体也可以查看“UM1702 KEIL工程建立说明.pdf”的描述

五、芯片可以找到内核，但不能“stop”，下载程序。

1、先修正下程序，  在初始化完系统时钟后，在调试阶段加一个相对长的时间，如3~5秒，以备程序跑起来不能“stop” 或 找不到内核时，有这个时间来进入SWD模式，出厂默认SWD 是可以进行连接下载的。

2、现在的情况，可以点击复位瞬间，快速点击 KEIL 中的下载功能键，尝试通过抢时间间隙的方式来进行更新程序的下载。  原理 同1。

3、以上两点不行，用ISP方式来擦除芯片程序，恢复出厂默认状态。

六、有源晶振规格  

在支持客户应用过程中，有出现SWM181RCT6 的Trim数据被擦除的情况。 通过外部晶振的校准方式可以重新建立Trim数据段。               

七、调试过程中出现突然下载不了程序

现象：客户应用SWM181RCT6，出现突然不可烧写的问题，现象是目标板不接外部电源可以，接了外部电源就不行。

分析：1、检查ISP引脚是否有变高电平的情况；   

2、排除是否由于添加程序后导致程序跑飞或锁死SWD现象。   

3、是否由于电平匹配问题。

解决： 客户定位到问题点，是由于板子一个配件的馈电导致MCU的供电电压达到了4.4V，仿真器的电源应该是3.6V左右，导致不能仿真。

八、关于TIMER捕捉值的准确性     

客户菘天电子应用TIMER捕获值不准问题，后来发现是捕获中断里加的PRINTF占用时间太多引起的。

--20221.9.22  (摘自陈任明 2021.09.22 邮件周报)

九、关于CAN 总线TX失败的现象   

客户浙江金开物联反馈CAN TX失败问题，给客户排查了波特率设置，外部晶振都没问题，后发现是CAN总线接了终端电阻就可以正常，所以问题点没接终端电阻引起的。

--20221.9.22  (摘自陈任明 2021.09.22 邮件周报)

十、应用中启动看门狗功能后，烧写失败的现象

现象：在处理掇月反馈回来应用SWM32SRET6的硬件平台，都存在烧写不成功的现象。

分析：在KEIL平台上查找MCU内核，都可以找到内核，但在烧写过程中会出现如下图的现象。用不同的工具进行都会出现“Could not stop Cortex-M … …”等现象。

  

  

解决：尝试采用ISP方式，去除板子上ISP端口相应的外围电路，可以进行ISP擦除后进行程序烧写。芯片是没有问题的。

      再次分析客户前面的现象，评估为客户的产品应用中采用了看门狗应用，在应用过程中通过SWD激活了烧写功能后，停止了看门狗喂狗的动作，导致MCU复位了，SWD的烧写过程被破坏，而且内部看门狗得不到喂养，总是在复位，所以出现提示以上现象。

      针对应用中启用了看门狗功能，需要跟新刷写程序，则可以采用以下几种方式，来达到烧写的目的：

      1)、采用ISP 方式进行烧写，在电路设计的时候就需要预留ISP方式接口

      2)、软件上处理，可以在上电初始化，在未开启看门狗功能之前，预留200ms~2s的延时。那么在上电时，在此延时过程中触发SWD方式烧写，则可以实现没有开启看门狗功能条件下顺利下载更新完程序。

      3)、在APP 应用时，可以通过按键，或通讯协议方式来触发停止看门狗功能后，再通过SWD方式可以进行下载烧写。

十一、SWM全系列片内 Flash 的 IAP 使用注意事项

    --Linzh  2023-4-17

现 象: 客户美的家用空调事业部，使用SWM260CBT7对接WIFI模组移植OTA功能时，程序执行擦写260片内Flash数据不生效。--2022.10.31

分析及解决：美的要求确保未初始化变量的初始值可控，会在上电时习惯性将RAM清零，查看程序编译后的map文件，在对RAM清零时将Flash相关操作函数重定向链接地址也一并请零了，导致Flash相关操作函数不生效，并陷入死循环。

注意：对于SWM全系列Flash的IAP操作，早期的标准外设驱动库，使用配置Flash Control寄存器来对Flash进行操作，需要将Flash相关操作函数全部重定向至RAM中执行，且对于个别早期 8 位单片机用户来说，会在上电时习惯性将RAM清零，此时应查看程序编译后的map文件，在对RAM清零时避开Flash相关操作函数链接的区间地址。   

后续更新的标准外设驱动库，使用片内驻留的针对 Flash操作的Thumb 代码程序，则无须将函数映射至RAM中执行（推荐此种方式）。

十二、KEIL的应用

12.1、查找跳转的应用        --Mogw     2023-6-24

现    象：客户久硕，使用的是SWM34SRE，客户反馈在KEIL中无法跳转；

分析解决：工程路径不带中文，问题即可解决；

十三、看门狗应用注意事项

13.1、SWM全系列 WDT 反复喂狗在特定情况下会导致某1次喂狗失败，致使后续所有喂狗语句失效(类似于陷入死锁状态)，从而在用户预期之外触发了WDT异常复位。      --Linzh    2023-11

现      象: 客户美的家用空调事业部，应用 SWM260CBT7, 系统主频配置为外部晶振8M倍频至 40M, 在Boot 中开启看门狗运行，在 boot 跳转 app 之前停止了看门狗，当跳转至 app 执行完必要的初始化逻辑后，先是执行了反复多次无意义的看门狗喂狗操作，而后进行看门狗重新初始化并开启开门狗，最后进入主循环用户逻辑，间隔 ms 级喂狗。在以上流程中的主循环喂狗中出现看门狗正常喂狗后仍复位的异常现象，此现象与延时时序相关，复现频率偶现。

伪代码流程：

boot ：WDT_Init(RST = 0.5s) && Start -> WDT_Feed-> WDT_Stop -> jump_app ->

app：for (i = 0; i < delay_500ms; ++i) { WDT_Feed(); // 等待上电稳定所需的500ms延时中无间    隔喂狗}  -> WDT_Init(RST = 0.5s) && Start  -> delay_170us()//此延时很重要 -> while(1) { WDT_Feed();  delay_2ms(); }

分      析：SAE 明显仿真分析出根本原因与 WDT 内部状态机设计相关，研发当时为了保证异步通信的稳定性，所以留了比较多的操作时钟余量，看门狗要兼顾慢时钟源下的快时钟总线写入，以及快时钟源下的慢时钟总线写入，没有兼顾考虑好连续喂狗这种操作，所以两次喂狗之间一定要间隔 5 个 WDT_CLK，绝对不要出现间隔不足的情况。另外，由于在 WDT 停止后执行喂狗，WDT_CLK 会停止，WDT 内部状态机也会暂停，因此 5 个 WDT_CLK 不能包含计算在 WDT 停止的时间段。

解      决：为了简化上述分析过程中的计算，建议对用户应用WDT时增加如下约束：

1、WDT_Stop()后不要执行 WDT_Feed()

2、WDT_Feed()后不要立即执行 WDT_Stop()，而是要延时 5 个WDT_CLK 及以上。

3、两次 WDT_Feed()之间必须间隔 5 个 WDT_CLK 及以上。

上述约束均已同步更改至 260-Lib，对于其他系列芯片，如WDT 的IP未变，不排除有同样的问题，请参照本问题进行调整。