I’m trying to build a TCP/IP application using FreeRTOS 10 + TCP/IP on an STM32F767ZI-Nucleo-144 board.

1. Starting with CubeMX and FreeRTOS 9. Got LED’s and printf’s working on UART 3.
2. I then replaced the FreeRTOS 9 files with version 10 files from their official SVN repository. This worked.
3. I started following the tutorial, copied the IP files over, created a config file, and am stuck at this step: https://www.freertos.org/FreeRTOS-Plus/FreeRTOSPlusTCP/TCPNetworkingTutorialInitialisingTCP.html

Of the many errors, the first is: undefined reference to ucMACAddress in NetworkInterface.c The tutorial defines it as a global in main.c: ~~~ static uint8_t ucMACAddress[6] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 }; ~~~ but NetworkInterface.c references it this way: ~~~ /* ucMACAddress as it appears in main.c */ extern const uint8_t ucMACAddress[ 6 ]; ~~~ I’ve tried various combinations to get around this, like removing const, as that clearly is wrong, (plus global header file, main.h, commenting out, etc.) but am unable to figure out how to get these variables (and other errors) cleaned up so I can proceed in the tutorial. I’m an intermediate C programmer, but I get lost when trying to merge these libraries with disparate header files and global variables. Any guidance would be appreciated. Thanks!

Hi Abe, you can get around the above problem by changing the declaration in your main.c to: ~~~ const uint8t ucMACAddress[ 6 ] = { configMACADDR0, configMACADDR1, configMACADDR2, configMACADDR3, configMACADDR4, configMAC_ADDR5 }; ~~~ Here is a post about the recent STM32Fxx driver: https://sourceforge.net/p/freertos/discussion/382005/thread/e6c5bd5f/?limit=250#fbd7 It needs one of these defines: STM32F7xx, STM32F4xx or STM32F2xx to indicate the type of CPU. I haven’t tested it on a STM32F2 my self, but it seems to work. I will attach the latest version here below as “STM32Fxxtcpdriver7Oct_2018.7z”. It won’t refer to ucMACAddress[] anymore. Please unpack the 7-zip in “FreeRTOS-Plus-TCPsourceportableNetworkInterface”. When using this driver, you should also include: ~~~ FreeRTOS-Plus-TCPsourceportableNetworkInterfaceCommonphyHandling.c ~~~ and add this path to the list of include directories: ~~~ FreeRTOS-Plus-TCPsourceportableNetworkInterfaceinclude ~~~ Please tell me how it works for you.

OK, thanks for the info and files. 🙂 I added STM32F7xx to Atollic’s (Eclipse) project symbol list, which solved some of the problems. I had to remove all the eventLog lines from phyHandling.c (no sign of eventLogging.h anywhere.) And I also need to paste in a ulApplicationGetNextSequenceNumber function, as found here: https://sourceforge.net/p/freertos/discussion/382005/thread/86b911fb/

I’m not seeing your xCheckLoopback() in FreeRTOSARP.h/c… As mentioned here: https://www.freertos.org/FreeRTOSSupportForumArchive/February2018/freertosFreeRTOS-PlusTCP760109c4j.html (I’m using latest svn) It’s also failling on undefined reference to xQueueCreateCountingSemaphore in BufferAllocation2.c, even though I have #define configSUPPORTDYNAMIC_ALLOCATION 1 in FreeRTOSConfig.h. https://www.freertos.org/CreateCounting.html Thanks. 🙂

Hi, thanks for the feedback.

I had to remove all the eventLog lines from phyHandling.c (no sign of eventLogging.h anywhere.)

I think that you used and older file and not the one that I attached yesterday as: STM32Fxxtcpdriver7Oct_2018.7z eventLog() is my own thing: it saves strings in a circular buffer, used for “real-time” debugging.

I’m not seeing your xCheckLoopback() in FreeRTOS_ARP.h/c You can find it in this earlier post

But you can also comment it out. I hope that the changes for the loop-back interface can be merged with the FreeRTOS/AWS release. At the same time, the drivers under NetworkInterface must be updated / merged. I think that in order to get xQueueCreateCountingSemaphore() compiled, you need these two defines: ~~~

define configUSECOUNTINGSEMAPHORES 1

define configSUPPORTDYNAMICALLOCATION 1

~~~

Thanks, Hein, I appreciate your time. I’m still totally confused on bringing in these libraries… :/ Am I using the right SVN repository? The eventlogging was from my list of compile errors to track down. It was in the SVN. I created a uxRand() that calls HALRNGGetRandomNumber(&hrng), which is uint32t, but elsewhere unsigned long and elsewhere UBaseTypet. (So many layers of redefinitions!) Can’t seem to resolve xQueueCreateCountingSemaphore, more layers of nested definitions. I tried adding mpuwrappers.h to NetworkInterface.c, but it didn’t work. ~~~ mpuprototypes.h 95: QueueHandlet MPUxQueueCreateCountingSemaphore( const UBaseTypet uxMaxCount, const UBaseTypet uxInitialCount ); mpuwrappers.h 100: #define xQueueCreateCountingSemaphore MPUxQueueCreateCountingSemaphore queue.h 1416: QueueHandlet xQueueCreateCountingSemaphore( const UBaseTypet uxMaxCount, const UBaseTypet uxInitialCount ) PRIVILEGEDFUNCTION; semphr.h 998: #define xSemaphoreCreateCounting( uxMaxCount, uxInitialCount ) xQueueCreateCountingSemaphore( ( uxMaxCount ), ( uxInitialCount ) ) ~~~ Also, the stm32fxxhaleth.h you gave me seems to conflict with stm32hallegacy.h. I tried removing it, but there are a number of other headers that depend on it. ~~~ Drivers/STM32F7xxHALDriver/Inc/Legacy/stm32hallegacy.h 1001:#define ETHMACTXFIFOWRITEACTIVE 0x00400000U /* Tx FIFO write active */ Middlewares/ThirdParty/FreeRTOS-Plus-TCP/portable/NetworkInterface/include/stm32fxxhaleth.h 1249:#define ETHMACTXFIFOWRITEACTIVE ((uint32t)0x00400000) /* Tx FIFO write active */ ~~~

Am I using the right SVN repository?

You can use SVN : https://sourceforge.net/p/freertos/code/HEAD/tree/ or github : https://github.com/aws/amazon-freertos

The eventlogging was from my list of compile errors to track down. It was in the SVN.

It could be that some sources file in the SVN still contained a reference to “eventlogging”. Sorry for that.

I created a uxRand() that calls HALRNGGetRandomNumber(&hrng), which is uint32t, but elsewhere unsigned long and elsewhere UBaseTypet. (So many layers of redefinitions!)

uxRand() came up a bit /ad hoc/, while the demo sources were being created. It is part of the demo’s, not part of a FreeRTOS library. I’d vote to make it uint32_t.

Can’t seem to resolve xQueueCreateCountingSemaphore, more layers of nested definitions. Confusing.

Have you defined these: ~~~ #define configUSECOUNTINGSEMAPHORES 1 #define configSUPPORTDYNAMICALLOCATION 1 ~~~ already? If so, you get the xQueueCreateCountingSemaphore() from task.c

Also, the stm32fxxhaleth.h you gave me seems to conflict with stm32hallegacy.h. I tried removing it, but there are a number of other headers that depend on it.

ST’s header file “stm32hallegacy.h” has also gone through a series of changes. In the older versions, it did not define ETH_MAC_TXFIFO_WRITE_ACTIVE. In later versions it was defined as: ~~~

define ETHMACTXFIFOWRITEACTIVE ((uint32_t)0x00400000) /* Tx FIFO write active */

~~~ and again later it is defined as: ~~~

define ETHMACTXFIFOWRITEACTIVE 0x00400000U /* Tx FIFO write active */

~~~ I don’t know how to handle this. You could put an empty file:

portableNetworkInterfaceSTM32Fxxstm32_hal_legacy.h

Or you can define __STM32_HAL_LEGACY before stm32f7xx_hal.h gets included. I mean in “portableNetworkInterfaceSTM32Fxxstm32fxxhaleth.c” : ~~~ /* Includes ——————————————————————*/ +#define __STM32_HAL_LEGACY 1 #if defined(STM32F7xx) #include “stm32f7xx_hal.h” #include “stm32f7xx_hal_def.h” #define stm_is_F7 1 #elif defined(STM32F407xx) || defined(STM32F417xx) || defined(STM32F427xx) || defined(STM32F437xx) || defined(STM32F429xx) || defined(STM32F439xx) #include “stm32f4xx_hal.h” #include “stm32f4xx_hal_def.h” #define stm_is_F4 1 ~~~ The NetworkInterface drivers always depend on chip libraries. We had to make some changes to them and therefor we also provided a stm32fxx_hal_eth.h. I hope that you can find an easy solutuion to this.

Defining configUSECOUNTINGSEMAPHORES got it to compile. I’ll see if I can progress now. Thanks! 🙂

I went back to the original SVN code, edited NetworkInterface.c and got rid of all the duplicate definitions. Much simpler for me to stick to the default CMSIS/HAL setup from ST. Still, thanks for your insight and feedback. I’ve gotten further in the tutorial, (had to account for a few variable name changes since the tutorial), and hopefully, tomorrow, talk to my echo server.

I’ve set FreeRTOSIPconfig.h to DHCP and set printf (through UART) for debug and ipconfig output. Says Link Status still low regardless of cable inserted or not. The cable lights are on and occasionally blink off. I know this cable works. Any suggestions? Thanks. prvIPTask started prvEthernetUpdateConfig: LS mask 00 Force 1 Network buffers: 56 lowest 56 Link Status still low Link Status still low Link Status still low Link Status still low Link Status still low Link Status still low Link Status still low Network buffers: 55 lowest 55 Link Status still low Link Status still low Link Status still low Link Status still low Link Status still low Link Status still low

Hi Abe, have you checked two other things: whether the choice for RMII versus MII is made correctly? And also ( related ) if you have configured all Ethernet pins in a correct way?

I went back to the original SVN code, edited NetworkInterface.c and got rid of all the duplicate definitions. Much simpler for me to stick to the default CMSIS/HAL setup from ST.

You’re reporting a problem with a driver ( from SVN ) that is outdated. We had good reasons to make changes to that driver. I tested the most recent STM32Fxx driver on my STM32F7 disco board. It would be handy if you can use the latest driver. If you want, tell me which HAL version you’re using and I will try compile it.

Hein, Thanks, I pushed what I have here: https://gitlab.com/abeowitz/netapp I’m using the HAL drivers from STM32CubeMX (F7 v 1.12), and I’m configured for RMII. The FreeRTOS-IP ones are renamed *.h.bak. I’ll try the new driver again, but all these different HAL drivers, dependencies and duplicate declarations are a nightmare…

Thanks for uploading your project. I comiled the latest NetworkInterface along with your HAL library, and it really helps to add this patch: ~~~ #include “phyHandling.h” +#define __STM32HALLEGACY 1 /* ST includes. */ #if defined( STM32F7xx ) #include “stm32f7xx_hal.h” ~~~ When __STM32_HAL_LEGACY is defined, stm32_hal_legacy.h will not be included anymore. And that saves a lot of conflicts.

Wow, thanks! I’ll check this out tonight. (Off to doctor appt.) I also need to check the docs, as STM32CubeMX hinted that I may need TIM2 connected with TRIG1… Is your STM32F7 Disco project available online?

Here’s a confusing thing. Atollic(Ecllipse) will automatically edit #includes if I rename the files. #include “stm32f7xxhaleth.h” Now I rename stm32f7xxhaleth.h -> stm32f7xxhaleth.h.bak And Atollic edits the file: #include “stm32f7xxhaleth.h.bak”

Adding #define STM32HALLEGACY 1 in NetworkInterface.c with your new driver allows me to compile, but nothing works. No interrupts, printf’s, anything. Debugger shows it’s wandering around HAL code. And I still get a bunch of redefined warnings. If I define STM32HALLEGACY in main.h, then there are a number of definitions missing. GPIOSPEEDHIGH, for example, is in stm32hallegacy.h. Seems I need bits and pieces of various headers. And being a newb to the PHY stuff, I’m still confused. :/

Here’s a confusing thing. Atollic(Ecllipse) will automatically edit #includes if I rename the files. #include “stm32f7xxhaleth.h” Now I rename stm32f7xxhaleth.h -> stm32f7xxhaleth.h.bak And Atollic edits the file: #include “stm32f7xxhaleth.h.bak”

I think that all Eclipse IDE’s will do that, if… you let the IDE maintain your project. Can you go to the properties of the header file and tick: “exclude resource from build”? I always use “Makefile” projects and import those into Eclipse. A Makefile project can easily be maintained and compiled outside an IDE.

Adding #define STM32_HAL_LEGACY 1 in NetworkInterface.c with your new driver allows me to compile

Great, one step further In your project, there is still stm32f7xx_hal_eth.c, can you also exclude that from being built? In TrueStudio, see its properties, tab “C/C++ build”, tick “Exclude resource from build”. And also any existing stm32f7xx_hal_eth.h should be removed or become invisible for the compiler. The FreeRTOS+TCP driver wants to replace all “stm32f*haleth*” files.

but nothing works. No interrupts, printf’s, anything. Debugger shows it’s wandering around HAL code.

Patience, you’ll get that working. I don’t know about the printfs because we did not implement them.

And I still get a bunch of redefined warnings. If I define STM32HALLEGACY in main.h, then there are a number of definitions missing. GPIOSPEEDHIGH, for example, is in stm32hallegacy.h.

In main.c you do not need stm32f7xx_hal_eth.h, so you could define : ~~~ #define __STM32F7xxHALETH_H 1 ~~~ To avoid inclusion of that header file, and do not define __STM32_HAL_LEGACY in your main.c. I have an STM32F746G DISCO board, which has the same Ethernet connections as your STM32F767ZI-Nucleo-144. Have you checked ST’s document en.DM00244518.pdf already? It describes the switches that you must set in order to make Ethernet working. Your board also uses the Reduced Media-Independent Interface, so your `freeRTOSIPConfig.h must define: ~~~ #define ipconfigUSE_RMII 1 ~~~ The pins are initialised by HAL_ETH_MspInit(), which will be called from stm32fxx_hal_eth.c. Debugging: could you put a breakpoint within vMACBProbePhy()? And if it doesn’t get called, please check how far it comes in the function HAL_ETH_Init().

I also have an STM32F7 DISCO board… Would it be too much trouble to ask you to make a simple starter build for me? If so, please start with STM32CubeMX, add FreeRTOS 10 + TCP/IP and generate it for Atollic TrueStudio and just bring it up to FreeRTOS_IPInit() with DHCP. If I have a working project on the DISCO, I can build my STM32F767ZI project, do a side-by-side comparison, and learn how to put all the pieces together…

Hi Abe, can we connect through email: “hein [at] htibosch [dot] net”? That will be easier to share projects and code. Thanks,

OK, I will, thanks.

Hello stm32f7 friends, i think i’m having the same problems. After getting everything up (as i thought). I got many multiple definition errors when compiling: these are for: HALETHDMATxDescListInit, HALETHDMARxDescListInit and others in MiddlewaresThirdPartyFreeRTOS-PlusFreeRTOS-Plus-TCPportableNetworkInterfaceSTM32F7xx/stm32f7xxhaleth.c and DriversSTM32F7xxHALDriverSrc/stm32f7xxhal_eth.c How can I get rid of this? Philipp PS: also in atollic true studio of course. Setting up with cubeMX as described on the freeRTOS website

Hi Philipp, in this same post you will see references to the latest STM32Fxx driver. That was an informal (personal) release. As you see, it includes a source file called “stm32fxxhaleth.c”. That version was adapted to enable zero-copy transmission and reception of packets. It look like your Atollic True Studio has included 2 times “stm32fxxhaleth.c”. Please go to the properties of DriversSTM32F7xx_HAL_DriverSrc/stm32f7xx_hal_eth.c and indicate that it should be excluded from building cq. compilation. That should solve your problem. Also please make sure that your project has defined:

#define STM32F7xx       1

Hein

Hello Hein, thank you for the fast response 🙂 i took the files from your link and deleted the ethernet HAL files generated by cubeMX and got the redefinitions error away. But now i got: phyHandling.c:193: undefined reference to ‘vLoggingPrintf’ But it could also that i missed configuring something. Perhaps, but i dont thinks so, that my FreeRTOSIPconfig.h is not correct. Do you have a sample IPconfig for the f7? I would adapt it for my use… I would also try to uncomment these loggings… But i’m a little bit confused now. Which files should one use when bgeinning with the FreeRTOS + TCP with a stm32F7xx. The files from the amazon FreeRTOS github page, the ones from the svn linked on the FreeRTOS website or this one you linked? And should i enable the ETH connection in cubeMX in RMII model (which seems to generate the duplicated ethernet HAL files but perhaps its important for other things)? Philipp

Hello again, so with commenting the vLoggingPrintf’s in the pyHandling i got everything compiled 🙂 I will try pinging the board tomorow 🙂 Philipp

If you’re interesting in the logging, you can replace vLoggingPrintf() with FreeRTOS_printf(()). Please note the double parentheses around the parameter list. FreeRTOS_printf(()) should be defined in your FreeRTOSIPConfig.h.

Hello Hein, thanks for you time again. I have 2 other questions / problems: I. (not so bad) When I set ipconfigHASPRINTF in FreeRTOSIPconfig.h to 1 my application hangs. It stucks inside HardFaultHandler in stm32f7xxit.c while loop and blocks other tasks. ipconfigHASDEBUG_PRINTF with 1 works just fine. I use for both prints (debug and non debuging messages) an SWV the function: void FreeRTOSTCPSWOdebug(const char *s) { while (*s!=’’) { ITMSendChar(*s++); } } II. (worse porblem) After calling FreeRTOSIPInit(…) with a static IP Adresse vApplicationIPNetworkEventHook is called every ~2 seconds. If I connect the stm32 with the router the eNetworkEvent is recognized as eNetworkUp. But the vApplicationIPNetworkEventHook is not called again after x secs or also (as described in the API) when the cable disconnects. Also no call when reconnecting the cable. The Router also dont recognize the device and I cant ping it. If I use the ipconfigUSEDHCP 1 the debugger says vDHCPprocess: discover. But the stm doesnt connect. The only thing i can see is an ARP with wireshark: 44952 3664.979352 Cimsys_33:44:55 Broadcast ARP 60 Gratuitous ARP for 192.168.55.149 (Request) . (static stm ip is 192.168.55.149). Do you have any Idea what could causes this problem? regards philipp

Hello again, i m sorry to bother you again Hein. The problem that the application hangs is definitley a problem with the debugging funktion. I fighted the whole day with the problem but without any luck. I also tried UART but same Problem there (HardFault). I read in the FreeRTOSIPConfigDefaults.h: / * The FreeRTOSprintf() must be thread-safe but does not have to be interrupt-safe */ Could writing a seperate task, and pass the logging-stuff with a queue solve the problem ? I think it would be important to get the logging/printing work for debugging? In the Demo Application “demologging.c” there were many Windows specific types used so i could not implement that. Or do you know any other sources / threads were i can find information about these problems? Philipp

The IP-task doesn’t run ISR code. Most Network Interface’s are defining an EMAC interrupt. That ISR should not produce any logging. It is called when a packet has been received or when it has been sent. The Windows project indeed has a separate (Windows) thread that prints a queue of logging lines. That has to do with the fact that a FreeRTOS task may not call any Windows System API’s like printf() and fflush(). Here below a simple version of vLoggingPrintf() that is task-safe. I haven’t tested this code yet: ~~~ static SemaphoreHandle_t xLoggingSemaphore = NULL; static BaseTypet xLoggingEnter( void ) { BaseTypet xResult;

if( xTaskGetSchedulerState() == taskSCHEDULER_NOT_STARTED )
{
    xResult = pdTRUE;
}
else
{
    if( xLoggingSemaphore == NULL )
    {
        /* Create a mutex. */
        xLoggingSemaphore = xSemaphoreCreateMutex();
    }

    if( xLoggingSemaphore != NULL )
    {
    /* Never wait longer than e.g. 100 ms. */
    TickType_t xTicksToWait = pdMS_TO_TICKS( 100 );

        xResult = xSemaphoreTake( xLoggingSemaphore, xTicksToWait );
    }
    else
    {
        xResult = pdFALSE;
    }
}
return xResult;

} static void vLoggingExit( void ) { /* Code below has confirmed that the semaphore has been created and that it has been taken by vLoggingPrintf(). Now release it. */ xSemaphoreGive( xLoggingSemaphore ); } void vLoggingPrintf( const char pcFormat, … ) { if( xLoggingEnter() != pdFALSE ) { va_list xArgs; / Watch out with small stacks. */ char pcBuffer[ 129 ]; BaseType xLength;

    va_start( xArgs, pcFormat );
    xLength = vsnprintf( pcBuffer, sizeof pcBuffer, pcFormat, xArgs );
    uart_send( pcBuffer, xLength );
    va_end( xArgs );

    vLoggingExit();
}

} ~~~

WOW! thanks Hein, its working like charm. You are the best :-). Perfect. Logging is now also with SWV possible. There was a spelling mistake in xRestult instead of xResult but…. But the Board is not listed in the Routers list of ips… If i do an “arp -a” I can see the ip + mac of the board. Also a strange behaviout: the vApplicationIPNetworkEventHook is only called when I connect the board the first time, as i wrote before. Do you have any idea? I put the log down here (i connected the ethernet cable after a few secs when the scheduler started…) Will be launching FreeRTOS… prvIPTask started PHY ID 7C130 xPhyReset: phyBMCRRESET 0 ready +TCP: advertise: 01E1 config 3100 prvEthernetUpdateConfig: LS mask 00 Force 1 xPhyReset: phyBMCRRESET timed out ( done 0x00 ) Network buffers: 56 lowest 56 Link Status still low Link Status still low Link Status still low Link Status still low xPhyCheckLinkStatus: PHY LS now 01 prvEthernetUpdateConfig: LS mask 01 Force 0

Autonego ready: 00000004: full duplex 100 mbit high status Link Status is high Network buffers: 55 lowest 55 Network buffers: 54 lowest 54 TX DMA buffers: lowest 2 Network buffers: 53 lowest 53 TX DMA buffers: lowest 1 Network buffers: 52 lowest 52 TX DMA buffers: lowest 0 Network buffers: 51 lowest 51

I will also try to continue with the tutorial creating a socket, but i thought that now the stm should be visible to the Router…. Thanks again!!!! Hein the master 🙂 Greetings Philipp

Hello Hein, Thank you again for the earlier replies. Unfortunately the driver is still not working 🙁 I think there is something corrupt with the xARPCache. As I said before: I connect the uC. These function are called: ~~~ prvHandleEternetPackage -> prvProcessEthernetPacket -> eARPProcessPacket: ulTargetProtocolAddress != *ipLOCAL_IP_ADDRESS_POINTER ->break ~~~ wait a few secs ~~~ FreeRTOS_OutputARPRequest -> vARPGenerateRequestPacket -> xNetworkInterfaceOutput -> iptraceNETWORK_INTERFACE_TRANSMIT() ~~~ wireshark: source:”STM_MAC”: “Gratuitous ARP for (Request)” broadcast Seems ok, but nothing is in the xARPCache. If i do a ping, the the Cache is filled with one entry, the Pings destinations IP, but no MAC. I also tried: – arpGRATUITOUSARPPERIOD ( pdMSTOTICKS( 20000 ) ) – bigger buffer allocation – polling and interrupt receving – arptable size changed So do you have any idea. Any help would be great. I just dont know what to do. Kind regards Philipp

prvHandleEternetPackage -> prvProcessEthernetPacket -> eARPProcessPacket: ulTargetProtocolAddress != *ipLOCALIPADDRESS_POINTER ->break

That’s good, it receives a packet. Can you lookup or log both ulTargetProtocolAddress and *ipLOCAL_IP_ADDRESS_POINTER? Do you use a fixed IP-address or use DHCP? The fixed IP-address would be defined in FreeRTOSConfig.h, as configIP_ADDR[0..3]

FreeRTOSOutputARPRequest -> vARPGenerateRequestPacket -> xNetworkInterfaceOutput -> iptraceNETWORKINTERFACE_TRANSMIT() wireshark: source:”STM_MAC”: “Gratuitous ARP for (Request)” broadcast. Seems ok, but nothing is in the xARPCache.

No, the gratuitous ARP request ( see wiki ) is an outgoing broadcast packet and it won’t create an ARP entry. ARP entries are created for incoming packets that have the device as a target.

If i do a ping, the the Cache is filled with one entry, the Pings destinations IP, but no MAC.

Are you talking about a ping to or from the STM?

I also tried: – arpGRATUITOUSARPPERIOD ( pdMSTOTICKS( 20000 ) ) – bigger buffer allocation – polling and interrupt receving – arptable size changed

If you want, attach your latest FreeRTOSIPConfig.h to your post. Regards.

Hello Hain, thanks for your reply. And sorry for the unprecise statment. without a Router, direct to (192.168.100.2, PC) and static IP (192.168.100.66, stm32), the – ulTargetProtocolAddress: Adresse of my PC: 0x264a8c0 “192.168.100.2” (0x264a8c0) – ipLOCALIPADDRESSPOINTER: static IP of the STM32F7: “192.168.100.66” (0xC0A86442) And I meant a ping from the stm to the PC. When pinging the STM i got nothing back. even with: ipconfigREPLYTOINCOMINGPINGS 1 and ipconfigREPLYTOINCOMING_PINGS and a vApplicationPingReplyHook() I will atach the FreeRTOSIPConfig.h and the FreeRTOSConfig.h. Strange thing is, I also tried to connect the stm (192.168.55.66) to the router (192.168.55.1), but then the ulTargetProtocolAddress stays “192.168.100.2” and the ipLOCALIPADDRESS_POINTER changes to the “192.168.55.66” of the stm. But i think that is another story. So i will atach the FreeRTOSIPConfig.h and the FreeRTOSConfig.h. Thanks for you time!!!! Regards Philipp

i also created a log. After the eNetworkUp event, I print out the arp table every 5 secs and ping every 20secs to my PC from the STM: ~~~ Will be launching FreeRTOS… prvIPTask started PHY ID 7C130 xPhyReset: phyBMCR_RESET 0 ready +TCP: advertise: 01E1 config 3100 prvEthernetUpdateConfig: LS mask 00 Force 1

Autonego ready: 00000004: full duplex 100 mbit high status Network buffers: 56 lowest 56 Link Status is high Network buffers: 55 lowest 55 Network buffers: 55 lowest 54 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 608 eARPProcessPacket(): ulTargetProtocollAddress: 0x 264a8c0, ipLOCALIPADDRESS_POINTER: 0x4264a8c0 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 Arp has 0 entries prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 Arp has 0 entries prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 Arp has 0 entries prvProcessEthernetPacket(): pxEthernetHeader->usFrameType: 0x 8 Arp has 0 entries i send ping to 192.168.100.2 (0x264a8c0) Arp 0: 10 – 264a8c0ip : 00:00:00 : 00:00:00 Arp has 1 entries Arp 0: 9 – 264a8c0ip : 00:00:00 : 00:00:00 Arp has 1 entries Arp 0: 9 – 264a8c0ip : 00:00:00 : 00:00:00 Arp has 1 entries Arp 0: 8 – 264a8c0ip : 00:00:00 : 00:00:00 Arp has 1 entries i send ping to 192.168.100.2 (0x264a8c0) Arp 0: 8 – 264a8c0ip : 00:00:00 : 00:00:00 Arp has 1 entries Arp 0: 7 – 264a8c0ip : 00:00:00 : 00:00:00 Arp has 1 entries Arp 0: 7 – 264a8c0ip : 00:00:00 : 00:00:00 Arp has 1 entries Arp 0: 6 – 264a8c0ip : 00:00:00 : 00:00:00 Arp has 1 entries i send ping to 192.168.100.2 (0x264a8c0) Arp 0: 6 – 264a8c0ip : 00:00:00 : 00:00:00 Arp has 1 entries Arp 0: 5 – 264a8c0ip : 00:00:00 : 00:00:00 Arp has 1 entries ~~~ Seems like the stmf7 is receiving ARPFrames and IPFrames. But he doesnt know what to do with them… ? Thanks again!!! Philipp

A few remarks about your FreeRTOSIPConfig.h :

/* USE_WIN: Let TCP use windowing mechanism. */ #define ipconfigUSE_TCP_WIN ( 0 )

Not important yet, but I recommend using the sliding TCP windows

#define ipconfigTCP_WIN_SEG_COUNT 240

I recommend a lower number. This defines the maximum number of outstanding TCP segments at any time.

#define ipconfigTCP_RX_BUFFER_LENGTH ( 1000 ) /* Define the size of Tx buffer for TCP sockets. */ #define ipconfigTCP_TX_BUFFER_LENGTH ( 1000 )

1000 bytes is very little. Normally this would be defined as minimal: ~~~

define ipconfigTCPRXBUFFERLENGTH ( 4 * ipconfigTCPMSS )

define ipconfigTCPTXBUFFERLENGTH ( 2 * ipconfigTCPMSS )

~~~ In the above case, the buffers are defined as a multiple of ipconfigTCP_MSS, which depends on ipconfigNETWORK_MTU, or up to 1460 bytes.

#define ipconfigREPLY_TO_INCOMING_PINGS 1

That is OK, but it is defined 2 times.

static uint8_t ucMACAddress[ 6 ] = { configMAC_ADDR0, configMAC_ADDR1, configMAC_ADDR2, configMAC_ADDR3, configMAC_ADDR4, configMAC_ADDR5 };

You are defining static variables/arrays in a header file. I think that all these declarations should be placed in your main.c. Especially ucMACAddress : are you sure it must be accessible in all modules that include FreeRTOSIPConfig.h? If you change ucMACAddress in e.g. main.c, it will not change in other modules. Normally FreeRTOS_GetMACAddress() is used to read the 6-byte MAC-address. Can you see where (in what modules) ucMACAddress[] is being used?

hey hein, i followed your instructions. With the following instruction in the FreeRTOSIPConfig.h ~~~ #define ipconfigDRIVERINCLUDEDTXIPCHECKSUM 1 ~~~ i am now able to ping the board from my Windows PC sometimes. A zero in the ipconfigDRIVER_INCLUDED_TX_IP_CHECKSUM calculates a wrong checksum. I moved the ucMACAddress[] and the other declarations to the main.c. The ucMACAddress[] was also used in the NetworkInterace.c line 251. I used the files you linked in an earlier post. I solved this like you described earlier. I also changed the linker you described in another post for the stm32f7 with the .first_data section (https://www.freertos.org/FreeRTOSSupportForumArchive/June2017/freertosFreeRTOSTCPandFATdriversSTM32F4andSTM32F7_8ddf9629j.html) from the 26 Juni. I dont know it seems to depend everything on the arptable. When this is filled correctly everything works find, but that happens not very often… 🙁 Perhaps you have another idea?
I will try more things out…. Philipp

hey hein, are there any other settings you changed on he freeRTOS? Or do you have a working example for the stm32f7 in atollic? Its an university project (diploma thesis) and it would be so great to use the +TCP package…. Philipp

Hi Philipp, if you drop an email to me on hein[at]htibosch[dot]net, I will send you a working example for stm32f7. It won’t be specifally for Atollic but a generic Makefile project. Cheers

Solved. I wrote Philipp a detailed email about his Atollic project. Here below a summary: The biggest problem that I found was the small heap, only 15 KB. That is possible, but then you’d have to reconfigure the whole project to get a smaller usage of RAM. The STM32F767 has a lot of RAM, so why not make use of it. I attach an example of vInitHeap() that uses heap_5.c. The STM32F7 has checsum offloading, meaning the the IP-task doesn’t have to waste time on calculating checksums of incoming and outgoing packets. Therefore FreeRTOSIPConfig.h should define: ~~~ #define ipconfigDRIVERINCLUDEDRXIPCHECKSUM 1 #define ipconfigDRIVERINCLUDEDTXIPCHECKSUM 1 ~~~ After making these changes, the +TCP project worked well.

Hi Hein, I followed all of the above steps to solve most of the common problems mentioned above. ANd im able to compile project. Although my device doesnt get connected. While debugging, I found out that i’m not receiving “MACMIIAR” value in “HALETHReadPHYRegister” function of stm32fxxhaleth.c I’m using IAR IDE and initial code for freertos and ethernet was generated using STM32CubeMX. Can you please help me?

Hello Pavan, are you using one of the latest version of NetworkInterface for STM? The drivers on Github/AWS still run behind. On the FreeRTOS SVN you will find the latest versions The driver in STM32Fxx works for both STM32F4 and STM32F7. You will also have to include Common/phyHandler.c into your project, and ad a -I for this include directory: source/portable/NetworkInterface/include The module phyHandler.c will try all PHY addresses to look for a connected PHY. If you have logging, you can see what happens. Otherwise you can also set breaks in the code and inspect variables. So in xPhyDiscover() you should see that your PHY will answer. Make sure you have ipconfigUSE_RMII defined to 1 in case the connection is RMII. Define it as 0 if you have a MII. The next step will be to see if the Link Status becomes high. You see that reflected in the variable xPhyObject.ulLinkStatusMask. While you are debugging it is maybe easier to disable DHCP: ~~~

define ipconfigUSE_DHCP 0

~~~ When you see that the PHY status is high, you will see so-called gratuitous ARP requests coming from your device.

Hello Hein,

are you using one of the latest version of NetworkInterface for STM?

I used the one attached in your previous discussion. I will try with the latest one as well.

The driver in STM32Fxx works for both STM32F4 and STM32F7. You will also have to include Common/phyHandler.c into your project, and ad a -I for this include directory: source/portable/NetworkInterface/include

Yes i have defined STM32f7xx, and I’m including phyHandler.c and have also included the said directory. And code compiles fine.

Make sure you have ipconfigUSE_RMII defined to 1 in case the connection is RMII. Define it as 0 if you have a MII.

Yes i’m using RMII and this setting is done in my FreeRTOSIPConfig.h So I think my code is getting stuck when I Initialise the ETH module. This doesnt happen when I’m using the ETH file supplied with STM HAL files. I assume some problem with GPIO init?? With similar GPIO init I have got LWIP working. I will try using the latest files mentioned by you and update you.

One question, does the code hang in stm32fxx_hal_eth.c in HAL_ETH_Init() ? ~~~c /* Wait for software reset / while ((heth->Instance->DMABMR & ETH_DMABMR_SR) != (uint32_t)RESET) { / If your program hangs here, please check the value of ‘ipconfigUSE_RMII’. */ } ~~~

Yes i’m using RMII and this setting is done in my FreeRTOSIPConfig.h

And so ipconfigUSE_RMII is defined as 1 ?

With similar GPIO init I have got LWIP working.

This happens with a call-back from the function HAL_ETH_Init() ~~~c /* Init the low level hardware : GPIO, CLOCK, NVIC. */ HAL_ETH_MspInit( heth ); ~~~ Can you confirm that your implementation of HAL_ETH_MspInit() is being called?