<div dir="ltr"><div><div><div><div><div>Alright, I figured out the issue, that was an application level problem, the UDP frames are received and sent without issues as far as I can see.<br></div>I think I might submit a patch soon with some of initial improvements. But I will summarize the changes I had to do here for now in case other people want to <br></div><div>use lwIP, based on the example application provided by STM.<br></div><br></div><div><b>BSP Changes:</b><br><br></div><div><b>Inside bsps/arm/stm32h7/start/bspstart.c:</b><br><br></div><div>
I changed the HAL_GetTick() function, which returned 0 previously to return the tick count by default:
<br><br></div><div>uint32_t HAL_GetTick(void)<br>{<br> return rtems_clock_get_ticks_since_boot();<br>}<br><br></div>I'm not sure whether there was a specific reason to have it return 0 by default, but that led to some issues because this function is generally called by the <br>HAL or by example applications and it's a lot of hassle to replace every call with rtems_clock_get_ticks_since_boot() <br></div><br></div><div><b>bsps/arm/shared/start/linkcmds.base:</b><br><br></div><div>I added following section to the linker file.<br></div><div>This is a really ugly solution because this file is used by all ARM bsps. I might look into how to make it stm32h7 specific, but it worked for me now because<br></div><div>I only have the STM32H7<br></div><div><br> /* Ugly solution for now */<br> .lwip_sec (NOLOAD) : ALIGN_WITH_INPUT {<br> . = ABSOLUTE(0x30040000);<br> *(.RxDecripSection)<br> . = ABSOLUTE(0x30040060);<br> *(.TxDecripSection)<br> . = ABSOLUTE(0x30040200);<br> *(.RxArraySection)<br> } >SRAM_3 AT> REGION_TEXT_LOAD<br><br><b>bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c:<br><br></b></div><div>On line 364 in <b>HAL_ETH_Init</b>, comment out the preprocessor guards to set the DSL to 64bit. I don't know what this line exactly does yet, but it was necessary <br></div><div>to get lwIP to work properly.<br><br></div><div><b></b></div><div>#ifndef __rtems__<br> /* SET DSL to 64 bit */<br> MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);<br>#endif /* __rtems__ */<br><br></div><div>On line 2648 in <b>ETH_DMATxDescListInit </b>comment the preprocessor guard so that the function is executed. This is necessary<br></div><div>so the DMA descriptors are set up properly.<br><br></div><div>Do the same for <b>ETH_DMARxDescListInit</b> starting at line 2687.<br><br></div><div>I think that was all. Hope it helps some people<br><br></div><div>Kind Regards<br></div><div>Robin Müller<br></div><div><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 29 Jan 2021 at 15:45, Robin Müller <<a href="mailto:robin.mueller.m@gmail.com">robin.mueller.m@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div>I think I might have found one issue. In the HAL_ETH_Init(ETH_HandleTypeDef *heth) function <br><br></div>The following piece of code was excluded:<br><br>#ifndef __rtems__<br> /* SET DSL to 64 bit */<br> MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);<br>#endif /* __rtems__ */<br><br></div>I reintroduced the line and now I have been able to receive UDP frames and send some back. I am still missing some frames, but at least it's working now.<br></div><div>I might look into how to put the lwIP section in a separate linkcmd file once I have figured out why some frames are missing, but the way I see it, <br>it is driver specific (STM used SDRAM3 for the required lwIP memory. One way would be to add an option in the config.ini like STM32H7_USE_LWIP and then<br></div><div>load those additional sections for lwIP.<br>
</div><br></div>Kind Regards<br></div>Robin<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 29 Jan 2021 at 14:18, Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 29, 2021, 5:52 AM Robin Müller <<a href="mailto:robin.mueller.m@gmail.com" target="_blank">robin.mueller.m@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi,<br><br></div>I am actually configuring the MPU with the following function, which was taken over from the STM32 example project:<br><br>/*Configure the MPU attributes */<br>void MPU_Config(void)<br>{<br> MPU_Region_InitTypeDef MPU_InitStruct;<br><br> /* Disable the MPU */<br> HAL_MPU_Disable();<br><br> /* Configure the MPU attributes as Device not cacheable<br> for ETH DMA descriptors */<br> MPU_InitStruct.Enable = MPU_REGION_ENABLE;<br> MPU_InitStruct.BaseAddress = 0x30040000;<br> MPU_InitStruct.Size = MPU_REGION_SIZE_256B;<br> MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;<br> MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;<br> MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;<br> MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;<br> MPU_InitStruct.Number = MPU_REGION_NUMBER0;<br> MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;<br> MPU_InitStruct.SubRegionDisable = 0x00;<br> MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;<br><br> HAL_MPU_ConfigRegion(&MPU_InitStruct);<br><br> /* Configure the MPU attributes as Cacheable write through<br> for LwIP RAM heap which contains the Tx buffers */<br> MPU_InitStruct.Enable = MPU_REGION_ENABLE;<br> MPU_InitStruct.BaseAddress = 0x30044000;<br> MPU_InitStruct.Size = MPU_REGION_SIZE_16KB;<br> MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;<br> MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;<br> MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;<br> MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;<br> MPU_InitStruct.Number = MPU_REGION_NUMBER1;<br> MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;<br> MPU_InitStruct.SubRegionDisable = 0x00;<br> MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;<br><br> HAL_MPU_ConfigRegion(&MPU_InitStruct);<br><br> /* Enable the MPU */<br> HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);<br>}<br><br></div><div>If I read the function correctly, it configures the descriptor areas as non-cacheable and the LwIP heap region<br></div><div>as non bufferable. I call this in hardware_init, which is the first function called in my Init funnction<br></div><br>void hardware_init() {<br> BSP_LED_Init(LED1);<br> BSP_LED_Init(LED2);<br> BSP_LED_Init(LED3);<br><br> MPU_Config();<br><br> /* Initialize the LwIP stack */<br> lwip_init();<br><br> /* Configure the Network interface */<br> Netif_Config();<br><br>}<br><br></div>I checked everything again and basically the setup appears to be identical to the example now.. I'm confused that it's not working.<br></div><div>I also supplied the following interrupt function in my C code:<br><br>/**<br> * @brief This function handles Ethernet interrupt request.<br> * @param None<br> * @retval None<br> */<br>void ETH_IRQHandler(void)<br>{<br> HAL_ETH_IRQHandler(&EthHandle);<br>}<br><br></div><div>But it appears not to be called..<br></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Is the irq being registered via the RTEMS interrupt APIs? If not and you are getting an interrupt, I'd wonder why you aren't seeing a spurious interrupt flagged.</div><div dir="auto"><br></div><div dir="auto">It shouldn't be installed directly at the hardware level.</div><div dir="auto"><br></div><div dir="auto">--joel</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div><div><br></div>Kind Regards<br></div>Robin<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 29 Jan 2021 at 12:03, Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" rel="noreferrer" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 29/01/2021 12:01, Robin Müller wrote:<br>
<br>
> The HAL_ETH_Transmit call just times out. If I set the timeout to 20 <br>
> to HAL_MAX_DELAY, the function will just block indefinitely.<br>
> Does anyone have an idea why this might happen?<br>
I would check the memory settings in the MPU for this area. You probably <br>
need some sort of device memory (uncached).<br>
<br>
-- <br>
embedded brains GmbH<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:sebastian.huber@embedded-brains.de" rel="noreferrer" target="_blank">sebastian.huber@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 16<br>
fax: +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
<br>
</blockquote></div>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" rel="noreferrer" target="_blank">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a></blockquote></div></div></div>
</blockquote></div>
</blockquote></div>