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?

[salkinium]

Although looking at the linkerscript by putting an init function into the section modm_section(".init_array.A0000") or similiar it should be placed at the top of the init array.

[salkinium]

Have your issues been solved? Is the integration working better now?

[mikewolfram]

Still learning FreeRTOS, but making good progress. I don't know if FreeRTOS requires extra init/setup but it is really confusing when a modm::rtos::Thread is created before main and then nothing seems to be working in main, because xTaskCreate(), which is called in the constructor, disables all IRQ.

Anyway, working on simple HTTP server for our project, guess we could use it as an example later. Need to get things done until next week, so no time yet to prepare the ethernet files for inclusion in modm.

BTW: modm::rtos::Thread will create the task immediately and it is started right away when the scheduler starts. But I think we should have also Threads to be started later.

[salkinium]

Ah wait I remember locking wasn't part of the malloc wrapper, it was separate therefore not implemented in :platform:heap: I think you need these retarget locks?
https://gist.github.com/thomask77/65591d78070ace68885d3fd05cdebe3a

[mikewolfram]

I added a modm_assert_continue_fail_debug to the tlsf malloc to make sure the pointer is always valid. Guess what? App was running for an hour without issue.
If there wasn't a SECS HSMS connection open, I'd silently restart every time it crashes. :-) Nobody would see it (except the SECS host).

[mikewolfram]

Ah wait I remember locking wasn't part of the malloc wrapper, it was separate therefore not implemented in :platform:heap: I think you need these retarget locks?
https://gist.github.com/thomask77/65591d78070ace68885d3fd05cdebe3a

Thanks, will have a look into it.

[mikewolfram]

Hmm, the retarget locks don't seem to work. Made a simple approach and get an assert. During static init everything is fine, but when the scheduler is not in right state (suspended) later on, it fails.

But tried a different way. vPortMalloc() uses vTaskSuspendAll() and xTaskResumeAll(). So I added it at the right places in heap_tlsf.c and it seems to work. Needs further/longer testing. If that really resolves it, then I would open a PR and modify the file to add the locking if module FreeRTOS is enabled.

[salkinium]

Hmm, the retarget locks don't seem to work.

Could be an issue of Newlib vs Newlib Nano, which is smaller, but has some limitations, like perhaps not using the malloc locks.
The specs are set here: https://github.com/modm-io/modm/blob/develop/ext/gcc/module_c.lb#L58

Unfortunately Newlib is criminally under-documented and short of looking at the raw source code, there's not much more I can help.

[mikewolfram]

I created a static mutex in heap_tlsf.c and that fails. Didn't try newlib, but expect the same issue. Looking into your link he uses vTaskEnterCritical() and vTaskExitCritical() for malloc and free. Looking into vPortMalloc() is saw the suspend and resume calls.

When locking the mutex, xSemaphoreTake() is checking the task status and then it fails, but only after main, static init before is fine. Don't ask me.

[salkinium]

There's also this option in the FreeRTOS config file, that may need to be set to 1 here:

#define configUSE_NEWLIB_REENTRANT              0

[salkinium]

Ah, I'm sorry, we're using heap_3.c, which makes the calls from FreeRTOS threadsafe by wrapping the system provided malloc/free functions.

But I really didn't think this through: All calls from FreeRTOS are thread-safe, but malloc/free itself is not. So every plain C malloc or C++ new is not thread-safe. 🤦

[salkinium]

Now I actually understand what you wrote!!! 🤦 Such an idiot I am…

[salkinium]

I added thread-safe malloc via cb82eec

[mikewolfram]

Thanks. Have a few days off, will test next week.

[mikewolfram]

Well, that thread-safe malloc/free didn't resolve the problem, still getting hard faults. I'm now suspecting the IPTask of FreeRTOS using more stack than they estimated.

[salkinium]

FYI: You can use the :platform:fault module to report a memory dump for post-mortem debugging. That way you don't need a debugger connected all the time.

[mikewolfram]

Haven't been here for quite some time, short update. Turned out, when running without any debugger attached, there are no memory problems. Had it running several days, with an open connection to our SECS host.

But when I run the app in debugger (either STLink or OpenOCD) the app will crash after some time. STLink sooner, OpenOCD sooner or later.

So where to go from here? Finish the implementation and have more people test it?

[salkinium]

We can't help much without some code… I think @strongly-typed is quite interested in Ethernet support in modm.