On 29/1/21 12:35 am, Robin Müller wrote:
> Are there any other thinks I need to take into account for making LwIP
> work with RTEMS?
I have not used LwIP but there is an RSB package ...
https://git.rtems.org/rtems-source-builder/tree/rtems/config/net/lwip-1-1.cfg
It has a patch. I have no idea a
Thanks for the clarifications. Now I actually understand what the
MPU_Config call from the STM32 example does. I was not sure what that was
for. I reintroduced the lwip sections (from my first mail9
again with the values from the STM32 linker script and used the MPU_Config
call from the STM32 examp
Good morning,
I’ve been trying to get ethernet on STM32F7 going using the bsd networking
stack (not going that well, there is a LOT of undocumented knowledge to
straighten out).
The STM32x7 ethernet controllers need their descriptors and data areas to be
located on 32-byte boundaries with a c
On Thu, Jan 28, 2021 at 10:52 AM Robin Müller
wrote:
> By the way, the lwipopts.h from the STM32 example application appears to
> use the SRAM3 as the LWIP heap memory as well:
>
> /* Relocate the LwIP RAM heap pointer */
> #define LWIP_RAM_HEAP_POINTER(0x30044000)
>
> Might this be an issue?
By the way, the lwipopts.h from the STM32 example application appears to
use the SRAM3 as the LWIP heap memory as well:
/* Relocate the LwIP RAM heap pointer */
#define LWIP_RAM_HEAP_POINTER(0x30044000)
Might this be an issue? I'm also not sure whether any interrupts are
configured .. but I t
Okay, I managed to achieve the initialization process by adapting the BSP
to perform the descriptor list initialization.
Unfortunately, the program now appears to crash in the following polling
function, which is called every 100 ms:
void ethernetif_input(struct netif *netif)
{
err_t err;
stru
Alright, I think these descriptors were not initialized inside the
functions:
ETH_DMATxDescListInit
ETH_DMARxDescListInit
because they are wrapped in preprocessor guards:
static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
{
#ifndef __rtems__
ETH_DMADescTypeDef *dmatxdesc;
uint32_t i;
On 28/01/2021 16:45, Robin Müller wrote:
*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bsp_nocache*)))
.bsp_nocache 0x3000 0x18c0
CMakeFiles/fsfw_example.dir/bsp_stm32_rtems/boardconfig/ethernetif.c.obj
0x3000 DMARxDscrTab
0x00
Thanks Sebastian.
The descriptors now appear to have addresses inside the RAM according to
the map file
*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bsp_nocache*)))
.bsp_nocache 0x3000 0x18c0
CMakeFiles/fsfw_example.dir/bsp_stm32_rtems/boardconfig/ethernetif.c.obj
0x0
On 28/01/2021 14:35, Robin Müller wrote:
So far, transferring the code has worked, but there are some specific
sections in the code used for our FreeRTOS example which put the
ethernet DMA descriptors in specific sections:
ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]
__attribute__((secti
Specific addresses shouldn't be in the shared linkcmds.base.
You could define new macro names like the other memory types and addresses
and add those to the generic linkcmds. Then the linkcmds.base would
generically know those sections and your BSP could set the right macros to
place it.
One thou
Some clarification: The linker script used for RTEMS is of course the
default RTEMS linker script, the FreeRTOS example used the linker file
taken from the STM32CubeH7 repository.
Kind Regards
Robin Müller
On Thu, 28 Jan 2021 at 14:35, Robin Müller
wrote:
> Hi,
>
> I am trying to get LwIP worki
Hi,
I am trying to get LwIP working on the STM32H7 because it has a low RAM
usage (at least that's what I heard). We already did this for FreeRTOS, but
we used the LwIP Raw API to not be bound specifically to the OS. I am now
trying to adapt LwIP to RTEMS , but I'm not really a LwIP expert and mos
13 matches
Mail list logo
