Ethernet freertos_tcp on f439zi nucleo not working

[kikass13]

Hello,
I will append my experience here, even though there is an issue for that already:

• Ethernet support / FreeRTOS+TCP #447

Preamble

I got @mikewolfram 's lan8720a phy driver and the corresponding example (using freertos_tcp) working with the f767zi nucleo board after changing some of the PHY pins hardcoded in the example he gave.

Getting There

After that, I tried to get it running on the f439zi but was unable to do so. After some hours of experimenting with the freertos network scheduler (RTOS_IP) and ethernet stack, i finally ended inside the event loop (controlled by freertos ip stack) of the lan8720a (see here) which should eventually handle arp requests coming from another laptop connected to the board via ethernet.

The Problem

The event loop handles events constantly (as expected), but every event is regarded as a NOP modm::platform::eth::Event::None and therefore ignored. Which means that the feeding function, responsible for setting proper events, is not working properly.

As it turns out, the producer function is this ISR

MODM_ISR(ETH)
{
	using modm::platform::eth;
	using modm::ethernet;

	BaseType_t xHigherPriorityTaskWoken = pdFALSE;
	EMAC::InterruptFlags_t irq = EMAC::getInterruptFlags();
	EMAC::acknowledgeInterrupt(irq);

	if (irq & (eth::InterruptFlags::Receive | eth::InterruptFlags::ReceiveBufferUnavailable)) {
		ethernet::isrEvent |= eth::Event::Receive;
		if (ethernet::emacTaskHandle) {
			vTaskNotifyGiveFromISR(ethernet::emacTaskHandle, &xHigherPriorityTaskWoken);
			portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
		}
	}
	if (irq & (eth::InterruptFlags::Transmit)) {
		ethernet::isrEvent |= eth::Event::Transmit;
		if (ethernet::emacTaskHandle) {
			vTaskNotifyGiveFromISR(ethernet::emacTaskHandle, &xHigherPriorityTaskWoken);
			portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
		}
	}

	if (EMAC::getInterruptFlags() & eth::InterruptFlags::AbnormalIrqSummary) {
		// not used yet
	}
}

My test have shown (led blinky, event chain debugging) that this specific ISR is not called properly.
Is there something you guys can tell me about the differences between the interrupt handling (mainly ethernet-DMA interrupts) ?

Other Stuff

• I tried checking registers for interrupts, dma and others to see if any flags have changed but it seems that these chips(f4 & f7) are equal in that matter
• we have an internal issue where this errata was evaluated, but we could not find anything in particular which could be problematic: https://www.st.com/resource/en/errata_sheet/dm00068628-stm32f427437-and-stm32f429439-line-limitations-stmicroelectronics.pdf

End

Thank you for reading, maybe someone can help

[salkinium]

Not a FreeRTOS expert, so I can only say some generic stuff:

• There's a minimum IRQ priority of I think 13 imposed by FreeRTOS, which uses lower priorities for SysTick and PendSV etc. Perhaps we're accidentally setting something wrong, or a lower prio interrupt is blocked by something higher?
• You can try NVIC_SetPending(ETH_IRQn); to test if the IRQ handler is even callable at all.
• There also a ETH_WKUP interrupt? Not sure what it does.
• Maybe there's some error state in the ethernet peripheral that's not being acknowledged, and therefore blocks new events? Maybe the AbnormalIrqSummary requires clearing some register in addition to the clearing flags.

[kikass13]

Not a FreeRTOS expert, so I can only say some generic stuff:

its not a freertos problem, so your answers are helpful.
Im gonna try some of the things you mentioned and get back as soon as possible (could take some days)

[mikewolfram]

The ethernet implementation is an adaption of the code provided in FreeRTOS+TCP for STM32, which uses the STM32 HAL. There seem to be differences between F4 and F7 families. FreeRTOS+TCP includes a modified (hacked?) version of the HAL ETH files for both F4 and F7.

Since I only have access to F7 boards my focus was to get that one working first and asking for help to complete the F4 part. To get started I'd look into the STM32 HAL ETH files in original FreeRTOS+TCP and check for differences.

[kikass13]

@mikewolfram
I am not familiar with cube and where their HAL examples are. Do you mean these (probably not?!):

• https://github.com/STMicroelectronics/STM32CubeF7/blob/master/Drivers/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal_eth.c
• https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_eth.c

because as far as i can tell, these two are identical. Except for one simple function static void ETH_Delay(uint32_t mdelay); which is used for the f4

• there is also a note on top of the f4 driver which says

The PTP protocol and the DMA descriptors ring mode are not supported in this driver

whatever that is worth

[mikewolfram]

It isn't in Cube nor their examples, it's in the FreeRTOS git:
https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/tree/main/portable/NetworkInterface/STM32Fxx

[kikass13]

Sorry i must misunderstood your reply then...

I already looked a these in the past, but
i cant seem to understand where these files could differ except for the chip specific _hal_eth.c files

[mikewolfram]

You are right, there's only one source file but a few headers per chip.

As far as I remember they use quite a few macros, maybe they do something different?

[mikewolfram]

Another question, do you get the link-up event? IRQ aren't enabled before.

[kikass13]

As far as I remember they use quite a few macros, maybe they do something different?

well i did a diff on the HAL_c files and the HAL_h files and they are essentially the same. And there are no further ifdefs in the freertos+tcp.c file you mentioned so i guess there's nothing more board specific?

[kikass13]

Another question, do you get the link-up event? IRQ aren't enabled before.

as far as I remember (i did these test with gdb about two weeks ago) this code (https://github.com/modm-io/modm/blob/develop/ext/aws/modm_lan8720a.cpp#L374-L385) was called properly and the autoNegotiationFailed flag was false, which I figured means that configuration of the PHY was possible.

I can also confirm that

• the stack / driver runs normal and other freertos Tasks can run freely without problems.
• the phy does something because i get a IFUP on my ethernet connection (using the other linux laptop) and the two leds blink whenever something happens on the ethernet rx/tx line
• What happens is that ARP requests (and therefore ICMP packets) are not handled, which means that i do not receive the MAC address of the nucleo (ARP requests are normally handled by FreertosIP stack, but the driver does not forward anything so they never reach the stack).

[mikewolfram]

In the example is a hook vApplicationIPNetworkEventHook, which get's called, when the link is up and everything set up, so it should print the IP etc.

[kikass13]

Yes that part works:

• see my example https://github.com/kikass13/modm_ethernet/tree/f439zi_support (which is your example, but altered a bit )
• and the output from the serial port

============================
Hello world ... 

Ethernet manager initializing ... 
Initialzing ethernet interface ...
Initializing scheduler
  -- Led blink task run()
  -- Network initialization task run()
  -- Http server task run()
   > IP address: 192.168.1.1
   > Netmask   : 255.255.255.0
   > Gateway   : 0.0.0.0
   > DNS       : 0.0.0.0

[rleh]

Maybe the updates FreeRTOS and FreeRTOS+TCP modules (#566) magically solve the problem? Could you test that @kikass13?