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 <ged...@rtems.org > <mailto:ged...@rtems.org>> wrote: > > > > On Fri, Jan 29, 2021 at 9:57 AM Robin Müller <robin.muelle...@gmail.com > <mailto:robin.muelle...@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.muelle...@gmail.com > <mailto:robin.muelle...@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.muelle...@gmail.com > <mailto:robin.muelle...@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 <j...@rtems.org > <mailto:j...@rtems.org>> wrote: > > > On Fri, Jan 29, 2021, 5:52 AM Robin Müller <robin.muelle...@gmail.com > <mailto:robin.muelle...@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.hu...@embedded-brains.de > <mailto:sebastian.hu...@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.hu...@embedded-brains.de > <mailto:sebastian.hu...@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@rtems.org <mailto:users@rtems.org> > http://lists.rtems.org/mailman/listinfo/users > <http://lists.rtems.org/mailman/listinfo/users>_______________________________________________ > users mailing list > users@rtems.org <mailto:users@rtems.org> > http://lists.rtems.org/mailman/listinfo/users > <http://lists.rtems.org/mailman/listinfo/users>_______________________________________________ > users mailing list > users@rtems.org <mailto:users@rtems.org> > http://lists.rtems.org/mailman/listinfo/users > <http://lists.rtems.org/mailman/listinfo/users>
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
