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> wrote:
>
>
> On Fri, Jan 29, 2021, 5:52 AM Robin Müller <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> 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
>>> 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/
>>>
>>> _______________________________________________
>> users mailing list
>> users@rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>
>
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
