2024-01-29 06:09 AM
Hello,
I am using a Nucleo H755ZIQ development board and want to test the network communication with the M4 core in combination with FreeRTOS and LWIP, but I am running into a problem.
For the setup process I have used the network tutorial from "Adam BERLINGER".
The problem is, that i cant build my project and i will always receive the following error message for the M4 project:
../LWIP/Target/ethernetif.c: In function 'HAL_ETH_RxLinkCallback':
../LWIP/Target/ethernetif.c:906:3: warning: implicit declaration of function 'SCB_InvalidateDCache_by_Addr' [-Wimplicit-function-declaration]
../LWIP/Target/ethernetif.c:906: undefined reference to `SCB_InvalidateDCache_by_Addr'
To my knowledge the function is part of the cache handling for M7 processors.
But in my case i am using the M4 core of the H7 which does not have a D-Cache.
Has someone an idea how to solve this issue?
2024-01-29 11:18 PM
The function "SCB_InvalidateDCache_by_Addr" comes via the CMSIS, e.g.: "Drivers/CMSIS/include/cachel1.armv7.h" (the real file used depends on your ARM architecture used/set).
This function is defined often as __STATIC_FORCEINLINE (code comes from a *.h file, as inline function).
Check, if you have CMSIS as part of your project, if the header file (*.h) can be found, if the MCU setting correlates with which H-file is used.
Even you might think to code all for the CM4 core (which does not have DCache, right): possible that you do not use properly a macro (I guess: CORE_CM7 vs. CORE_CM4) to decide for which core the code should be "visible".
I can also imagine that this function is still used/called from code intended to run on CM7, somewhere else (e.g. using UART with DMA).
Also a guess: "cache coherency":
I could imagine, that even a CM4 calls this function, even it does not have DCache. But the CM7 core has. It is needed to invalidate the CM7 core DCache, because the CM4 has updated the memory. It makes sense to me as:
if the CM4 does something and the memory is changed (by CM4) - the CM7 cannot rely anymore its DCache: CM7 has to read again from memory (to update its DCache). So, I could imagine, that even a CM4 calls this function in order to make is "consistent" with a (potentially) running CM7 core (which would miss the updates on memory if not done this call). Even CM4 could fire this function in order to keep CM7 "up-to-date".
Do you see this function called by a CM4 core code?
Do you have this function? (via properly referenced CMSIS)
2024-01-29 11:25 PM
I use often a "grep" tool, e.g. "grepWin": it helps me to see if I have a file with this function in my project.
If not:
Resolving missing functions (as a linker error) is often to check, why a file is not used, why a file was not compiled, why a file was not included...
2024-01-30 03:21 AM
Hello tjaekel,
thanks for your answer.
Let me try to answer as best as i can, since I am new to the development for STM32.
CMSIS ist included unter Drivers/CMSIS, possibly automatically though the activation of FreeRTOS.
I have looked in the header files to finde the function "SCB_InvalidateDCache_by_Addr".
What I have discovered is that the function "SCB_InvalidateDCache_by_Addr" is not present in the core_cm4.h
In the core_cm7.h file the function is present.
This is probably the cause, why i receive the error message for the implicit declaration.
The "SCB_InvalidateDCache_by_Addr" function gets called through in the LWIP "HAL_ETH_RxLinkCallback" function in the ethernetif.c file.
At the moment I dont know how to solve this, since i could not find very much information for LWIP on the M4 core of a H755.
2024-01-30 03:36 AM
Hello,
SCB_InvalidateDCache_by_Add() is part of Cache API related to CM7 core which has a data cache that CM4 doesn't have. Try to comment out this line.
I am new to the development for STM32.
I don't recommend to start with a relatively complex MCU like H755. Start with STM32F4 series instead. H7 series need you have some experience on STM32.
2024-02-15 12:59 AM
Hello,
Thank you for your contributions and for your detailed explanations.
An internal ticket was submitted to the CubeMx team.
(ID : 166295 ) to take a closer look at this issue.
(PS: ID : 166295 is an internal tracking number and is not accessible or usable by customers).
Thanks.
Mahmoud.