国产替代和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折腾一周,慢慢分析,属于原创,如需转载,请注明出处,谢谢。