GD32E503Vxx SPI W5500通信

国产替代和ETH网关开发，用到了GD32E503Vxx和W5500，首先在W5500 Evaluation board V1.0上，也就是基于STM32F103RCT6的评估板上，移植了DHCP，DNS，MQTT等功能，跑起来很顺利。后续移植到GD32E503VET6自己的板卡上，出现了奇怪的问题。上电配置后，dhcp发送的数据抓包根本看不到，所以收到的llen = getSn_RX_RSR(SOCK_DHCP)一直是0，而跳过dhcp，配置个默认的ip，直接跑后面的dns和mqtt，完全没有问题，这个问题折腾了我快一周，仔细查找问题，原来问题真的是让人意想不到。

先贴GD32E503VET6上SPI的配置吧，我是用的SPI1,要使能复用时钟RCU_AF。

 SPI GPIO 初始化：

SPI1初始化：

 

main函数初始化，不执行复位 ，由于跑了Freertos，所以等系统跑起来默认状态后进行硬件复位和初步的配置。

 

配置好spi，上电后可以先写mac和读mac验证SPI通信是否正常。 

初始上电状态的复位和配置：

下面，重头戏来了：

DHCP_Run ()函数 ，发现运行DHCP时发送DISCOVER报文，抓不到包，说明数据没有发送成功，要么发送成功后数据是异常的，wireshark没法正确解析，

仿真慢慢跟吧，看是哪里出的问题，毕竟同样的程序和驱动，在ST上跑的没问题。

最后发现在send_DHCP_DISCOVER()函数出现问题，下面贴代码：

先贴ST的：

乍一看就是个结构体和数组赋值，没啥高级的骚操作啊，仿真就看出问题了，在GD平台上运行时， 在执行pDHCPMSG->OPT[k++] = strlen((char*)host_name)后，惊奇的是数组索引k变成了0，等于后续赋值又是从0开始，把前面的数据覆盖了。这个问题真是奇葩。。。。

然后贴GD改之后的代码：

 红色是修改后的，既然你算不过来把k清零了，那我再定义个变量，在strlen之前备份一下，strlen之后再把备份值还给K。

完美，抓包可以收到报文了：

 同理，在DHCP所需要发送的报文中，还有send_DHCP_REQUEST函数也要改一下，同样的改法，就不贴图和代码了，然后都改好之后，编译下载：

wireshark上抓包的数据有了，再看看程序的串口打印部分：

DHCP和后续功能全部正常运行，完美。

那么这个bug，也是比较让人无语的，话说GD32E503VET6 是基于ARM Cortex-M33 内核，我百度了下，相比于STM32F103 的cortex-M3，是个增强版本，但是不知道这个增强在实际应用中却是属于倒退。。。

这个坑，踩的着实让人无语。。。￣□￣｜｜

这个bug折腾一周，慢慢分析，属于原创，如需转载，请注明出处，谢谢。