Using LwIP on the STM32H7
Mr. Andrei Chichak
groups at chichak.ca
Mon Feb 1 21:32:03 UTC 2021
Is there any advantage to using bsd networking over LWiP, or vice versa?
With Robin’s BSP, if it gets released, I think I should be able to finish up my bsd networking BSP for STM32F7. I’ll also see what I can do about getting it going for F4 as well.
Andrei
> On 2021-January-29, at 12:21, Gedare Bloom <gedare at rtems.org <mailto:gedare at rtems.org>> wrote:
>
>
>
> On Fri, Jan 29, 2021 at 9:57 AM Robin Müller <robin.mueller.m at gmail.com <mailto:robin.mueller.m at gmail.com>> wrote:
> The whole code base I'm using might go public soon so I will also send the link here
> as soon as it is. I think this might also be useful for people who would like to evaluate how to set up Eclipse and the CMake build system for
> their application
>
> Kind Regards
> Robin
>
> This will be greatly appreciated, thank you. Glad you got it working, and in relatively short order!
>
> On Fri, 29 Jan 2021 at 17:47, Robin Müller <robin.mueller.m at gmail.com <mailto:robin.mueller.m at gmail.com>> wrote:
> 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.
> 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
> use lwIP, based on the example application provided by STM.
>
> BSP Changes:
>
> Inside bsps/arm/stm32h7/start/bspstart.c:
>
> I changed the HAL_GetTick() function, which returned 0 previously to return the tick count by default:
>
> uint32_t HAL_GetTick(void)
> {
> return rtems_clock_get_ticks_since_boot();
> }
>
> 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
> HAL or by example applications and it's a lot of hassle to replace every call with rtems_clock_get_ticks_since_boot()
>
> bsps/arm/shared/start/linkcmds.base:
>
> I added following section to the linker file.
> 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
> I only have the STM32H7
>
> /* Ugly solution for now */
> .lwip_sec (NOLOAD) : ALIGN_WITH_INPUT {
> . = ABSOLUTE(0x30040000);
> *(.RxDecripSection)
> . = ABSOLUTE(0x30040060);
> *(.TxDecripSection)
> . = ABSOLUTE(0x30040200);
> *(.RxArraySection)
> } >SRAM_3 AT> REGION_TEXT_LOAD
>
> bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c:
>
> On line 364 in HAL_ETH_Init, 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
> to get lwIP to work properly.
>
> #ifndef __rtems__
> /* SET DSL to 64 bit */
> MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);
> #endif /* __rtems__ */
>
> On line 2648 in ETH_DMATxDescListInit comment the preprocessor guard so that the function is executed. This is necessary
> so the DMA descriptors are set up properly.
>
> Do the same for ETH_DMARxDescListInit starting at line 2687.
>
> I think that was all. Hope it helps some people
>
> Kind Regards
> Robin Müller
>
>
>
> On Fri, 29 Jan 2021 at 15:45, Robin Müller <robin.mueller.m at gmail.com <mailto:robin.mueller.m at gmail.com>> wrote:
> I think I might have found one issue. In the HAL_ETH_Init(ETH_HandleTypeDef *heth) function
>
> The following piece of code was excluded:
>
> #ifndef __rtems__
> /* SET DSL to 64 bit */
> MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);
> #endif /* __rtems__ */
>
> 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.
> 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,
> 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
> load those additional sections for lwIP.
>
> Kind Regards
> Robin
>
> On Fri, 29 Jan 2021 at 14:18, Joel Sherrill <joel at rtems.org <mailto:joel at rtems.org>> wrote:
>
>
> On Fri, Jan 29, 2021, 5:52 AM Robin Müller <robin.mueller.m at gmail.com <mailto:robin.mueller.m at gmail.com>> wrote:
> Hi,
>
> I am actually configuring the MPU with the following function, which was taken over from the STM32 example project:
>
> /*Configure the MPU attributes */
> void MPU_Config(void)
> {
> MPU_Region_InitTypeDef MPU_InitStruct;
>
> /* Disable the MPU */
> HAL_MPU_Disable();
>
> /* Configure the MPU attributes as Device not cacheable
> for ETH DMA descriptors */
> MPU_InitStruct.Enable = MPU_REGION_ENABLE;
> MPU_InitStruct.BaseAddress = 0x30040000;
> MPU_InitStruct.Size = MPU_REGION_SIZE_256B;
> MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
> MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
> MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
> MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
> MPU_InitStruct.Number = MPU_REGION_NUMBER0;
> MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
> MPU_InitStruct.SubRegionDisable = 0x00;
> MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
>
> HAL_MPU_ConfigRegion(&MPU_InitStruct);
>
> /* Configure the MPU attributes as Cacheable write through
> for LwIP RAM heap which contains the Tx buffers */
> MPU_InitStruct.Enable = MPU_REGION_ENABLE;
> MPU_InitStruct.BaseAddress = 0x30044000;
> MPU_InitStruct.Size = MPU_REGION_SIZE_16KB;
> MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
> MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
> MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;
> MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
> MPU_InitStruct.Number = MPU_REGION_NUMBER1;
> MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
> MPU_InitStruct.SubRegionDisable = 0x00;
> MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
>
> HAL_MPU_ConfigRegion(&MPU_InitStruct);
>
> /* Enable the MPU */
> HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);
> }
>
> If I read the function correctly, it configures the descriptor areas as non-cacheable and the LwIP heap region
> as non bufferable. I call this in hardware_init, which is the first function called in my Init funnction
>
> void hardware_init() {
> BSP_LED_Init(LED1);
> BSP_LED_Init(LED2);
> BSP_LED_Init(LED3);
>
> MPU_Config();
>
> /* Initialize the LwIP stack */
> lwip_init();
>
> /* Configure the Network interface */
> Netif_Config();
>
> }
>
> I checked everything again and basically the setup appears to be identical to the example now.. I'm confused that it's not working.
> I also supplied the following interrupt function in my C code:
>
> /**
> * @brief This function handles Ethernet interrupt request.
> * @param None
> * @retval None
> */
> void ETH_IRQHandler(void)
> {
> HAL_ETH_IRQHandler(&EthHandle);
> }
>
> But it appears not to be called..
>
> 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.
>
> It shouldn't be installed directly at the hardware level.
>
> --joel
>
>
> Kind Regards
> Robin
>
> On Fri, 29 Jan 2021 at 12:03, Sebastian Huber <sebastian.huber at embedded-brains.de <mailto:sebastian.huber at embedded-brains.de>> wrote:
> On 29/01/2021 12:01, Robin Müller wrote:
>
> > The HAL_ETH_Transmit call just times out. If I set the timeout to 20
> > to HAL_MAX_DELAY, the function will just block indefinitely.
> > Does anyone have an idea why this might happen?
> I would check the memory settings in the MPU for this area. You probably
> need some sort of device memory (uncached).
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at embedded-brains.de <mailto:sebastian.huber at embedded-brains.de>
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/ <https://embedded-brains.de/datenschutzerklaerung/>
>
> _______________________________________________
> users mailing list
> users at rtems.org <mailto:users at rtems.org>
> http://lists.rtems.org/mailman/listinfo/users <http://lists.rtems.org/mailman/listinfo/users>_______________________________________________
> users mailing list
> users at rtems.org <mailto:users at rtems.org>
> http://lists.rtems.org/mailman/listinfo/users <http://lists.rtems.org/mailman/listinfo/users>_______________________________________________
> users mailing list
> users at rtems.org <mailto:users at rtems.org>
> http://lists.rtems.org/mailman/listinfo/users <http://lists.rtems.org/mailman/listinfo/users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20210201/5134e034/attachment-0001.html>
More information about the users
mailing list