STM32F407移植NetxDUO无法触发中断

老马新兵

最近刚开在我的407板子上移植NetxDUO，按照netxduo自带的sample和网上的成功示例做，但是始终不成功，解掉了几个坑，比如nx_port.h里的自定义参数没有加上，设置的RX Buffer太小导致初始化不成功，现在internal ip thread已经能够正常运行，试着从电脑上ping，但是设备端始终没有中断触发。查了两天，没找到原因，能否麻烦坛主帮忙看看有什么问题？谢谢了！

附件里包括了ethernet的初始化代码，以及从sample里改过来的代码。

老马新兵

对了，代码运行时，能看到端口上的两盏灯都亮着，但是不闪烁，感觉没有数据进来。从PC端的Ping的结果显示"Host is down".

eric2013

11楼

哪位在stm32f407上把netx duo移植成功了指点我一下，我的无法ping通，谢谢
http://www.armbbs.cn/forum.php?m ... 0360&fromuid=58
(出处: 硬汉嵌入式论坛)

老马新兵

谢谢硬汉！实际上坛子上的几个成功移植的案例，我都看了，但是有一些不一样的是，我现在这个ETH的中断无法触发，不是很确定还有什么特殊的设置需要做

老马新兵

另外一个发现是，DMASR的值一直是0x3802112，应该是接收缓存溢出，继续调试中。

老马新兵

终于解决了，跟楼主给的例子一样，接收数据缓存必须设置足够大才行。我从30改成了40，终于能够成功接收数据了。

这样另一个问题就是：如果要用netxduo，到底需要多大的内存？目前我的板子上没有接外置内存，这个要求还是有些高啊

老马新兵

终于解决了所有的问题。前后大概花了4天，效率真是太低下，鄙视一下自己

总结一下在调试过程中踩到的所有坑，也算给后来人一个教训：

1. 相信大多数人都是从官方的sample code开始做移植，第一个坑在没弄明白所有代码前就是千万别改sample里的设置，比如http://www.armbbs.cn/forum.php?m ... 0360&fromuid=58里的接收的buffer，还有一个就是在创建Thread时候的分配的Descriptor的数目，我遇到的问题是芯片自身内存的原因，试着把数量从50改小，结果发现两个问题：a) nx thread初始化的时候，对DMA Receive Descriptor分配内存时候失败 b) 接收缓存溢出，导致中断根本不会被触发。如果你遇到类似的问题，试着改一下MTU的size，Sample Code里定义的MTU是1500字节，我现在使用的是500字节。相应的，每个IP包的实际数据也就变成了472字节。这个改变实在是不得已而为之。

2. 第二个坑是CubeMX的坑。最主要的一个就是寄存器的设置有问题，需要根据手册调整PHY的参数。

3. 因为是第一次搞ethernet，也不知道这个是不是真正的问题。最开始的时候，PHY 芯片在初始化完成后根本没有反应，琢磨了很久，才试了一下是不是需要做reset，果然，这一步不能少。

4. 热插拔的问题。如果带着网线启动系统之后，Netxduo已经很好地处理了这个问题。但是如果没有网线启动，ethernet driver就会在自协商的过程中失败，导致初始华失败。这时候就必须做一下处理，我采用了一个workaround的，在启动时启动一个timer检测网线是否已经插上，ethernet直到检测到网线才会继续初始化的过程。这样虽然不能解决所有的问题，但是应该能满足基本的实际要求。

如果这几个问题能够在移植的过程中注意到，我估计应该能够顺利移植成功。

eric2013

老马新兵 发表于 2020-12-10 06:32
终于解决了所有的问题。前后大概花了4天，效率真是太低下，鄙视一下自己

总结一下在调试过程中踩到的 ...

谢谢楼主分享。

wxfpuw001

你好，请教楼主个问题，有没有遇到在初始化PHY的底层驱动时(stm32f4xx_hal_eth.c)时，用到了HAL_Delay、HAL_GetTick等与Tick相关的函数时，跑Debug时是正常的，一旦直接下载到板子上后就卡在那个地方过不去。用的校准文件(stm32f4xx_hal_timebase_tim.c)是硬汉提供的：如下：

1. /*
   
2. *********************************************************************************************************
   
3. *        函 数 名: HAL_Delay
   
4. *        功能说明: 重定向毫秒延迟函数。替换HAL中的函数。因为HAL中的缺省函数依赖于Systick中断，如果在USB、SD卡
   
5. *             中断中有延迟函数，则会锁死。也可以通过函数HAL_NVIC_SetPriority提升Systick中断
   
6. *        形    参: 无
   
7. *        返 回 值: 无
   
8. *********************************************************************************************************
   
9. */
   
10. void HAL_Delay(uint32_t Delay)
    
11. {
    
12.         bsp_DelayMS(Delay);
    
13. }
    
14. 
    
15. HAL_StatusTypeDef HAL_InitTick (uint32_t TickPriority)
    
16. {
    
17.         return HAL_OK;
    
18. }
    
19. 
    
20. uint32_t HAL_GetTick (void)
    
21. {
    
22.         static uint32_t ticks = 0U;
    
23.         uint32_t i;
    
24. 
    
25.         if (osKernelGetState () == TX_INITIALIZE_IS_FINISHED)
    
26.         {
    
27.                 return ((uint32_t)osKernelGetTickCount ());
    
28.         }
    
29. 
    
30.         /* 如果ThreadX还没有运行，采用下面方式 */
    
31.         for (i = (SystemCoreClock >> 14U); i > 0U; i--)
    
32.         {
    
33.                 __NOP(); __NOP(); __NOP(); __NOP(); __NOP(); __NOP();
    
34.                 __NOP(); __NOP(); __NOP(); __NOP(); __NOP(); __NOP();
    
35.         }
    
36.        
    
37.         return ++ticks;
    
38. }

复制代码

老马新兵

不知道你有没有解决这个问题。我现在的做法是ThreadX用的是SysTick来做的，HAL_Tick也是根据SysTick来读取的值，没有用到额外的timer，当然精度会有一些影响，我现在的系统频率设置成了200HZ，所以HAL_Delay的精度是5ms。我原来遇到过你说的这种类似的问题，在HAL_Delay()函数中就停住了，就是因为HAL_GetTick()返回的值永远是不变的。基本上这种情况都是因为ThreadX的整个调度出现了问题。你可以看看是不是还有SysTick的中断发生。