How to get Ethernet working again after upgrading to firmware FW_H7_V1.4.0 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-05-08 8:03 AM
I had several projects running, created with STM32CubeMX. Among them also the example H743ZI_LwIP_test1. Things were fine with firmware 1.3.0 and 1.3.2 but after upgrading to 1.4.0 , I can no longer connect to the network. No ping, no nothing. Currently I test with the NUCLEO-H743ZI board.
I compared .ioc files and various code source, but couldn't find any
Any help welcome,
thanks in advance
Peter
Solved! Go to Solution.
- Labels:
-
Bug-report
-
Ethernet
-
STM32CubeMX
-
STM32H7 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-10 1:26 AM
This is the real problem - blatant incompetence! ST's employees even not able to understand the problem and what others are talking about...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-10 7:50 PM
Hmm... they don't call SCB_CleanDCache_by_Addr in TX because in the examples they configure the whole
area of LwIP Tx buffers as non-cacheable in MPU.
Cube does not seem to generate this MPU code automatically.
-- pa
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-11 11:12 AM
They do copy buffers on other series, but for H7 they have made a zero-copy driver. On H7 there are no dedicated Tx data buffers at all.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-11 9:46 PM
I mean, here they define MPU region for TX buffers for example. At top of D2 RAM.
-- pa
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-12 12:08 PM
I double-checked both - low_level_output() and HAL_ETH_Transmit(), which the former calls, and they really implement zero-copy principle without data buffer copying. The linker script also doesn't have a section for Tx data buffers and the buffers don't exist. And it's not for Rx data buffers also, because those are located at lower addresses and Rx code uses cache invalidation.
It seems, that this MPU region is a leftover from some other code or earlier version, which now does nothing, except for making some other unrelated memory accesses slower.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-12 2:48 PM
Thank you, Piranha. So, in your TX snippet above:
SCB_CleanDCache_by_Addr(q->payload, q->len);
q-> payload and q-> len need only to be rounded up to the cacheline size, and this specific issue will be ok?
By the way where __SCB_DCACHE_LINE_SIZE is defined? I could not find it in CubeH7 ver 1,5
-- pa
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-12 4:34 PM
> By the way where __SCB_DCACHE_LINE_SIZE is defined? I could not find it in CubeH7 ver 1,5
I use core related files from ARM CMSIS releases. Looks like ST's "fast" developers still haven't updated these files, as they are not allowed to do it to not brake their "tested" non-working HAL... :D
https://github.com/ARM-software/CMSIS_5/issues/282
https://github.com/ARM-software/CMSIS_5/commit/fd248605929c12e359fae9be9b01e1c15a6af077
> need only to be rounded up to the cacheline size, and this specific issue will be ok?
You don't need to do it as the SCB_*_by_Addr() functions do proper rounding (address down, size up) internally. Actually rounding down of the address is done in hardware register by simply ignoring the lower bits.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-12 5:38 PM
Great. And by the way again, they have not defined the TX buffer pool for LwIP in a link script.
In the examples, the absolute address and size is defined in lwipopts.h here. 0x30044000, yep.
-- pa
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-14 8:46 AM
LWIP_RAM_HEAP_POINTER defines address of lwIP's internal heap memory used for various purposes, not only for Tx frames. Buffers of Tx frames can be from different memories - internal heap, pbuf pool, flash, user provided specific locations and even "returned" Rx input buffers. The provided solution works in all cases.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-21 2:59 PM
This was reported with a proper fix almost two years ago:
https://community.st.com/s/question/0D50X00009XkXUWSA3/stm32h7-lwip-cache-bug-fix
