STM32F05x移植GD32F1x0注意事项

只看该作者 · 2015-1-20 19:59

前言：本以为能很顺利的移植，结果130这颗芯片虽然是M3的core，实际上外部PIN与GPIO等寄存器结构与M0一致，NVIC部分又与M3一致，简言之，130即有M3的“基因”，也有M0的“基因”，主要这颗芯片是为了与ST的M0芯片抢市场。由于刚上市，所以Library从ST M0的Library基础稍作修改。寄存器名称虽然不一样，但是实际地址与功能是完全一样。下面重点列出在移植过程中，我遇到的问题：

只看该作者 · 2015-1-20 20:00

A0：在Keil中，Device选型：

A0：GD32f130c6应当选择STM32F101C6/8，因为该系列寄存器与GD130最接近。左图为100，右图为101，实际130的SPI包含I2SCFGR与I2SPR寄存器。

只看该作者 · 2015-1-20 20:00

只看该作者 · 2015-1-20 20:01

另外使用STLINK读取的Device，如图：

只看该作者 · 2015-1-20 20:02

Q1、EXTI中断无效？

A1:

只看该作者 · 2015-1-20 20:02

其中在操作SYSCFG寄存器时，必须先使能SYSCFG的CLK，这个问题在M0上也是一样的，但是我在移植过程中，忽略了这点。

导致花了一些时间才找到这个问题。找类似这种bug，两方面着手，一用硬件仿真，看外设寄存器是否与预设一直；二设置完后直接串口打印出来。

只看该作者 · 2015-1-20 20:03

Q2、NVIC配置部分需要增加下面两句，M0无此配置，M3则有。

A2:

只看该作者 · 2015-1-20 20:03

另外中断优先级配置因为有组的概念，所以也有所不同，如;

只看该作者 · 2015-1-20 20:04

Q3、EXTI在handler mode进入stop mode后不能唤醒，在thread mode中进入可以唤醒？

A3:

如果在Handler mode进入STOP mode，需要唤醒，则唤醒源的中断优先级必须必进入stop mode的handler 优先级更高。否则同级或更低级的中断无法唤醒，除非退出中断。这也是在thread mode进入可以被唤醒的原因。

只看该作者 · 2015-1-20 20:05

如在timer2中进入stopmode，在exti按键唤醒。demo：

只看该作者 · 2015-1-20 20:05

Q4:SPI寄存器区别：

A4：SPIx_CR1 Bit11，051中该bit(CRCL)是CRC length，130是FF16(FF16)是data frame formate；

SPIx_CR2 bit15-bit8,130中高8位为保留字节，051则有其他定义，如fifo触发值与data size。因此130中没有该库函数：

只看该作者 · 2015-1-20 20:06

通讯库函数区别：

只看该作者 · 2015-1-20 20:07

Q5：使用HSE时，有效采样数的区别：
A5:

只看该作者 · 2015-1-20 20:07

Q6：中断向量表区别，GD兼容051，但又涵盖M3的中断入口。另外051不支持自定义中断入口偏移地址。
A6:

只看该作者 · 2015-1-20 20:08

Q7：GPIO区别：
A7:虽然130为M3，但是GPIO部分与M0的寄存器结构完全一致。

Q8：Flash区别：

A8：虽然130为M3，但是Flash部分与M0结构大概相同，包含对OB区域的读写与读保护等级，多了一个烧断功能，此时不能还原为保护或无保护状态。

只看该作者 · 2015-1-20 20:08

加读保护功能与M0一致，在使用JLink Flash中使用去除读保护是，device必须选择STM32F101系列，否则去除保护功能无效。

但有部分寄存器位有所不同，如：

只看该作者 · 2015-1-20 20:09

Q9:RCC区别：
A9：M0中只有APB总线给外设提供CLK，但是M3中分了两组不同的CLK对应不同的外设，分别为APB1，APB2。如下：

只看该作者 · 2015-1-20 20:10

只看该作者 · 2015-1-20 20:11

Q10：ID读取位置：
Flashsize位置不同,130与M3一致，但UID却与M0一致。如：

M0：

只看该作者 · 2015-1-20 20:12

Q11：电源特性区别：
A11：