search

mbed-ce / mbed-os

Arm Mbed OS is a platform operating system designed for the internet of things
https://mbed.com
Other
37 stars 12 forks source link

Add emac section #260

Open JojoS62 opened 3 months ago

JojoS62 commented 3 months ago

Summary of changes

This PR adds a section for emac variables. It is necessary to place them into a location that can be specified in the linker script. For devices with cache like the STM32H7 this is essential, the network will fail after a short time when the emac vars are in a cached RAM area.

Example for linker settings:

.emac_section  (NOLOAD) : { *(.DMA_EMAC_section) } >SRAM2

Impact of changes

This modification has no impact when the linker section is not defined. There will be no warning or error thrown when the section does not exist, the linker will place the variables where it wants. So to use this section, check the map file for the correct placement.

Migration actions required

Documentation

Pull request type 

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results 

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

multiplemonomials commented 3 months ago

Should we update the STM32H7 linker scripts to have this section?

JojoS62 commented 3 months ago

There are different RAM areas in the H7 variants, and the setting is only necessary when Ethernet is used. That is why I wanted to have the custom linker scripts, these can handle the different demands better. I would rather add an Ethernet example to the new library repo.

multiplemonomials commented 3 months ago

Eh, but... it's a big issue if Ethernet doesn't work out of the box on STM32H7 boards... like I think this guy was just having trouble last week https://forums.mbed.com/t/mbed-ce-ethernet-nucleo-h723-not-working/22566

JojoS62 commented 3 months ago

ok, I will check it. But I can't test it on the H723. But the error with the missing ping reply could have some other reason.

JohnK1987 commented 3 months ago

I do not understand this issue very well but I am using STM32H743ZI2 as a heart of Tester in my project. The H743ZI2 is connected over Ethernet and communicate via UDP with my PC app. This tester was able to run for few weeks without any issue on Mbed side.

multiplemonomials commented 3 months ago

Yes at USC RPL we have also used ethernet on H743 for some time with no issues... have we just been getting lucky?

JojoS62 commented 3 months ago

I can reproduce the problem very reliable. I have a MQTT client running and it fails after a few minutes. With this fix, it runs also for weeks.

JojoS62 commented 3 months ago

ok, I have double checked. I was confused with H7/F7, there are some H7 targets where the linker script has sections for RxDecripSection/TxDescripSection. E.g. the H743 has this sections, so this target is ok, the H723 doesn't have it.

Also the F769 and F746 don't have the linker script settings and there I have the problems. I must check again, it is also possible that the problems come from bad alignement, the descriptors need to have 32 Byte alignment. Modifying the scripts has an impact on existing software, the RAM is used completely in one block. Changes have an impact on the heap size, specially when Ethernet is not used.

The STM Emac Code has two versions, the H7 uses a different than the others. The correct alignment is only implemented for the Verstion ETH_IP_VERSION_V2 or H7. For the other targets, the alignment is set to 4 Byte and this is not correct for the descriptor table.

multiplemonomials commented 2 days ago

I started digging into this a bit on my end. On NUCLEO_H723ZG, Ethernet does not work reliably. It cannot pass the tests because the tests try to send a data buffer allocated with malloc, and on H723ZG, malloc can allocate from DTCM. The Eth DMA cannot access the DTCM memory, so it dies.

In parallel, there's also a bit of a mess going on with the linker script setup for the Ethernet buffers. It's really not pretty, as it relies on extremely large reserved areas of memory to make things work, and it does so in a very non obvious way.

multiplemonomials commented 2 days ago

I think that one fix we need is, the STM32 EMAC driver needs to be able to reallocate a pbuf from the heap if it receives a Tx buffer that is in an inaccessible memory area.