解决gd32 串口uart 乱码

只看该作者 · 2021-12-28 23:04

<p>$ git diff CMSIS/GD/GD32F10x/Include/gd32f10x.h</p><p>diff --git a/CMSIS/GD/GD32F10x/Include/gd32f10x.h b/CMSIS/GD/GD32F10x/Include/gd32f10x.h</p><p>index 38a25ff..8a470c5 100644</p><p>--- a/CMSIS/GD/GD32F10x/Include/gd32f10x.h</p><p>+++ b/CMSIS/GD/GD32F10x/Include/gd32f10x.h</p><p>@@ -60,7 +60,7 @@ OF SUCH DAMAGE.</p><p> #ifdef GD32F10X_CL</p><p> #define HXTAL_VALUE    ((uint32_t)25000000) /*!< value of the external oscillator in Hz */</p><p> #else</p><p>-#define HXTAL_VALUE    ((uint32_t)8000000) /* !< from 4M to 16M *!< value of the external oscillator in Hz*/</p><p>+#define HXTAL_VALUE    ((uint32_t)12000000) /* !< from 4M to 16M *!< value of the external oscillator in Hz*/</p><p> #endif /* HXTAL_VALUE */</p><p> #endif /* high speed crystal oscillator value */</p>

外部改成12Mhz

只看该作者 · 2021-12-28 23:05

复制

$ git diff CMSIS/GD/GD32F10x/Include/gd32f10x.h

diff --git a/CMSIS/GD/GD32F10x/Include/gd32f10x.h b/CMSIS/GD/GD32F10x/Include/gd32f10x.h

index 38a25ff..8a470c5 100644

--- a/CMSIS/GD/GD32F10x/Include/gd32f10x.h

+++ b/CMSIS/GD/GD32F10x/Include/gd32f10x.h

@@ -60,7 +60,7 @@ OF SUCH DAMAGE.

 #ifdef GD32F10X_CL

 #define HXTAL_VALUE    ((uint32_t)25000000) /*!< value of the external oscillator in Hz */

 #else

-#define HXTAL_VALUE    ((uint32_t)8000000) /* !< from 4M to 16M *!< value of the external oscillator in Hz*/

+#define HXTAL_VALUE    ((uint32_t)12000000) /* !< from 4M to 16M *!< value of the external oscillator in Hz*/

 #endif /* HXTAL_VALUE */

 #endif /* high speed crystal oscillator value */

只看该作者 · 2021-12-28 23:09

大概意思是判断一个标识位，如果有那个标识位，则采用另一条公式来计算倍频。暂时猜测那个标识位是GD32专用。
但是这样解决不了我的问题，我们的MF系统采用的是寄存器设定波特率，根本就没有使用库函数。我就想理清思路搞清楚这里为什么要这样修改，然后我依葫芦画瓢同样操作寄存器。结果我失败了，这里的17跟上面的15同样莫名其妙，不过+17比下面原来的+2刚好多了15，看来有什么关系。

只看该作者 · 2021-12-28 23:10

就以0x20000000作为切入口，查看它在RCC->CFGR中的用途。

果然是GD32专用，0x20000000是第29位保留位。
小飞觉得这一位跟前面的15有关，那么我们尝试把前面分频使用的0x08000000改为0x20000000试试

只看该作者 · 2021-12-28 23:10

RCC->CFGR |= (uint32_t)(0x20000000 | RCC_CFGR_PLLSRC_HSE | RCC_CFGR_PLLXTPRE_HSE_Div2 | RCC_CFGR_PLLMULL12);

只看该作者 · 2021-12-28 23:16

这个时候系统跑起来了，串口没有乱码，但是USB口不能使用，当然了，USB在108MHz不能用呀。
这样子算是解决了串口乱码这个问题。
但是有个非常奇怪的问题，Keil调试看到系统时钟是48MHz，通过寄存器换算也是，百思不得其解！
花哥提醒，Keil的RCC调试界面是为STM32准备的，看GD32的特殊频率可能不准。
其实关键就在于这个29位，由于它的存在，导致RCC_GetClocksFreq函数计算108MHz分频时忽略了29位，从而得到48MHz，也就是8M/2*12，那个15不见了。
因此，GD32新手需要修改RCC_GetClocksFreq是为了让频率计算结果为108MHz，从而解决串口乱码问题。而我用0x0800000分频的时候，MCU实际工作在48MHz，然后在串口那里计算波特率的时候，我使用了108MHz。两者犯了不同的错误，导致了相同的结果，然后歪打正着解决了这个问题。
之前很多人让我等比例换算频率，108M是72M的1.5倍，然后在波特率那里也这样算。但是我不服气，因为F407是168M，也是这个公式。
结论表明：串口乱码的关键是计算波特率的频率必须与实际MCU频率相符！

只看该作者 · 2021-12-28 23:19

对于MF系统来说，不能使用USB是不可原谅的，于是我们测试96MHz和120MHz，分别12倍频和15倍频，USB分别2分频和2.5分频，非常好算！
通过Keil调试发现系统成功工作在96MHz和120MHz，但是显示的USB频率有时是64MHz，有时是96MHz/80MHz/120MHz，很是莫名其妙！
PC无法发现USB设备，非常郁闷！
后来无意中清空一次芯片Flash后才明白，原来是TinyBooter工作在120MHz已经启动，但是TinyCLR还跑在72MHz，导致发现不了USB。
重新编译TinyCLR到120MHz后解决问题，发现USB。
并且，在刷写TinyCLR的时候，速度明显加快，大概100k Byte/s

只看该作者 · 2021-12-28 23:21

实际上这些问题可能不是很难，但是官方没有统一的详细的文档（没有说清楚为什么那样子改）。
事后在网上发现一个信息：

只看该作者 · 2021-12-28 23:26

真是坑爹呀，有木有？？？

120MHz主频，加上Flash零等待，性能提升应该不止50%了吧，对于性能不足的MF来说，可是极大的利好！
至于是否稳定，咱不懂，直接装上流水线试试！

End.