Ethernet support / FreeRTOS+TCP

[mikewolfram]

Ciao ragazzi,

have been working the last 2-3 days to get FreeRTOS+TCP working on a STM32F7. Created a modm::platform::Eth class as well as the functions required to initialize the interface and receive/send packets. Still pretty early, but for most cases it should be sufficient.

Question is now, how to get it into modm? Copy FreeRTOS+TCP and make it a module like FreeRTOS? Right now I have a modm::platform::Eth class and a separate modm::driver::Lan8720a class for the PHY.

Works/tested on a F765, so should be fine on all F7. Reading the FreeRTOS+TCP STM32 port (HAL based) there seem to be few differences on a F4. I don't have one to test, maybe if somebody wants to help on that?

Greetings from Bella Italia.
Mike

[salkinium]

Copy FreeRTOS+TCP and make it a module like FreeRTOS

Yes, but you'd copy the files via The update.py script into the ext repo: https://github.com/modm-ext/freertos-partial then add a new :freertos:tcp module or something like that.

[salkinium]

You don't have to enable your port for everything, you can limit it to just what you tested.

[mikewolfram]

Is there a reason that the update script is pulling a 2 years old clone of FreeRTOS?

if not Path("freertos_src").exists():
    subprocess.run("git clone https://github.com/cjlano/freertos.git freertos_src", shell=True)

[salkinium]

Yes, it was the only official git clone available at the time. Should be https://github.com/freertos/freertos now.

[mikewolfram]

Do you want me to update it in my upcoming PR or let it have its own?

[salkinium]

You can update it in the same PR.

[mikewolfram]

Continuing on the ETH driver and the FreeRTOS TCP functions I ran into an issue. I have a Microchip I2C EEPROM with 48bit UID. That UID should be used as the MAC address. But I cannot read from I2C before the FreeRTOS scheduler has been started. A read from I2C is hanging forever, when executed in main() before scheduler start. Doing the read from inside a task it works without issues.

I have the impression that IRQs are not executed as expected, any hint what could be the reason?

Also tried to read the UID in a task and then call FreeRTOS_IPInit() from there, but that crashes the app. Maybe a stack issue?

[salkinium]

Possibly an interrupt priority issue, where the I2C IRQ priority is too low? FreeRTOS could also perhaps disable interrupts between task creation and scheduler start?

[salkinium]

There's a number of magic numbers that should probably be verified: https://github.com/modm-io/modm/blob/develop/ext/aws/FreeRTOSConfig.h.in#L123

[mikewolfram]

Also tried to read the UID in a task and then call FreeRTOS_IPInit() from there, but that crashes the app. Maybe a stack issue?

Indeed, had to increase the stack of that task to 1024 (256 words). Well, that solved one problem :-)

[mikewolfram]

FreeRTOS could also perhaps disable interrupts between task creation and scheduler start?

Found it. Yes, when creating a task the IRQ are disabled. The variable uxCriticalNesting is initialized with 0xaaaaaaaa, so when leaving a critical section the IRQ aren't enabled again. The scheduler will reset to 0 when starting a task.

[salkinium]

Is this an initialization error? ie. Should FreeRTOS be initialized somehow before task construction?

There is currently no way to initialize functions after memory/heap init, but before the init_array/static constructors, so perhaps that may need to be added?