FreeRTOS + TCP, tutorial, STM32F7 questions.

[system]

abeowitz wrote on Saturday, October 06, 2018:

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/FreeRTOS_Plus_TCP/TCP_Networking_Tutorial_Initialising_TCP.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!

[htibosch (Hein Tibosch)]

heinbali01 wrote on Sunday, October 07, 2018:

Hi Abe, you can get around the above problem by changing the declaration in your main.c to:

    const uint8_t ucMACAddress[ 6 ] = { configMAC_ADDR0, configMAC_ADDR1, configMAC_ADDR2, configMAC_ADDR3, configMAC_ADDR4, 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 “STM32Fxx_tcp_driver_7_Oct_2018.7z”. It won’t refer to ucMACAddress[] anymore.
Please unpack the 7-zip in “FreeRTOS-Plus-TCP\source\portable\NetworkInterface”.

When using this driver, you should also include:

    FreeRTOS-Plus-TCP\source\portable\NetworkInterface\Common\phyHandling.c

and add this path to the list of include directories:

    FreeRTOS-Plus-TCP\source\portable\NetworkInterface\include

Please tell me how it works for you.

[system]

abeowitz wrote on Sunday, October 07, 2018:

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/

[system]

abeowitz wrote on Sunday, October 07, 2018:

I’m not seeing your xCheckLoopback() in FreeRTOS_ARP.h/c… As mentioned here: https://www.freertos.org/FreeRTOS_Support_Forum_Archive/February_2018/freertos_FreeRTOS-Plus_TCP_760109c4j.html

(I’m using latest svn)

It’s also failling on undefined reference to xQueueCreateCountingSemaphore in BufferAllocation_2.c, even though I have #define configSUPPORT_DYNAMIC_ALLOCATION 1 in FreeRTOSConfig.h. https://www.freertos.org/CreateCounting.html

Thanks.

[htibosch (Hein Tibosch)]

heinbali01 wrote on Sunday, October 07, 2018:

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:
STM32Fxx_tcp_driver_7_Oct_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 configUSE_COUNTING_SEMAPHORES       1
#define configSUPPORT_DYNAMIC_ALLOCATION    1

[system]

abeowitz wrote on Tuesday, October 09, 2018:

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 HAL_RNG_GetRandomNumber(&hrng), which is uint32_t, but elsewhere unsigned long and elsewhere UBaseType_t. (So many layers of redefinitions!)

Can’t seem to resolve xQueueCreateCountingSemaphore, more layers of nested definitions. I tried adding mpu_wrappers.h to NetworkInterface.c, but it didn’t work.

mpu_prototypes.h
95: QueueHandle_t MPU_xQueueCreateCountingSemaphore( const UBaseType_t uxMaxCount, const UBaseType_t uxInitialCount );  

mpu_wrappers.h
100: #define xQueueCreateCountingSemaphore   MPU_xQueueCreateCountingSemaphore  

queue.h 
1416: QueueHandle_t xQueueCreateCountingSemaphore( const UBaseType_t uxMaxCount, const UBaseType_t uxInitialCount ) PRIVILEGED_FUNCTION;  

semphr.h
998: #define xSemaphoreCreateCounting( uxMaxCount, uxInitialCount ) xQueueCreateCountingSemaphore( ( uxMaxCount ), ( uxInitialCount ) )  

Also, the stm32fxx_hal_eth.h you gave me seems to conflict with stm32_hal_legacy.h.

I tried removing it, but there are a number of other headers that depend on it.

Drivers/STM32F7xx_HAL_Driver/Inc/Legacy/stm32_hal_legacy.h
1001:#define ETH_MAC_TXFIFO_WRITE_ACTIVE                     0x00400000U  /* Tx FIFO write active */

Middlewares/Third_Party/FreeRTOS-Plus-TCP/portable/NetworkInterface/include/stm32fxx_hal_eth.h
1249:#define ETH_MAC_TXFIFO_WRITE_ACTIVE  ((uint32_t)0x00400000)  /* Tx FIFO write active */

[htibosch (Hein Tibosch)]

heinbali01 wrote on Tuesday, October 09, 2018:

Am I using the right SVN repository?

You can use SVN : FreeRTOS Real Time Kernel (RTOS) / Code / [r2837]
or github : GitHub - aws/amazon-freertos: DEPRECATED - See README.md

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 HAL_RNG_GetRandomNumber(&hrng), which is uint32_t,
but elsewhere unsigned long and elsewhere UBaseType_t. (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 configUSE_COUNTING_SEMAPHORES       1
    #define configSUPPORT_DYNAMIC_ALLOCATION    1

already? If so, you get the xQueueCreateCountingSemaphore() from task.c

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

ST’s header file “stm32_hal_legacy.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 ETH_MAC_TXFIFO_WRITE_ACTIVE  ((uint32_t)0x00400000)  /* Tx FIFO write active */

and again later it is defined as:

#define ETH_MAC_TXFIFO_WRITE_ACTIVE  0x00400000U             /* Tx FIFO write active */

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

portable\NetworkInterface\STM32Fxx\stm32_hal_legacy.h

Or you can define __STM32_HAL_LEGACY before stm32f7xx_hal.h gets included.
I mean in “portable\NetworkInterface\STM32Fxx\stm32fxx_hal_eth.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.

[system]

abeowitz wrote on Tuesday, October 09, 2018:

Defining configUSE_COUNTING_SEMAPHORES got it to compile. I’ll see if I can progress now.

Thanks!

[system]

abeowitz wrote on Wednesday, October 10, 2018:

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.

[system]

abeowitz wrote on Thursday, October 11, 2018:

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

[htibosch (Hein Tibosch)]

heinbali01 wrote on Thursday, October 11, 2018:

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.

[system]

abeowitz wrote on Thursday, October 11, 2018:

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…

[htibosch (Hein Tibosch)]

heinbali01 wrote on Thursday, October 11, 2018:

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 __STM32_HAL_LEGACY   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.

[system]

abeowitz wrote on Thursday, October 11, 2018:

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?

[system]

abeowitz wrote on Friday, October 12, 2018:

Here’s a confusing thing. Atollic(Ecllipse) will automatically edit #includes if I rename the files.

#include “stm32f7xx_hal_eth.h”

Now I rename stm32f7xx_hal_eth.h -> stm32f7xx_hal_eth.h.bak

And Atollic edits the file:
#include “stm32f7xx_hal_eth.h.bak”

[system]

abeowitz wrote on Friday, October 12, 2018:

Adding #define STM32_HAL_LEGACY 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 STM32_HAL_LEGACY in main.h, then there are a number of definitions missing. GPIO_SPEED_HIGH, for example, is in stm32_hal_legacy.h.

Seems I need bits and pieces of various headers. And being a newb to the PHY stuff, I’m still confused.

[htibosch (Hein Tibosch)]

heinbali01 wrote on Friday, October 12, 2018:

Here’s a confusing thing. Atollic(Ecllipse) will automatically edit
#includes if I rename the files.

#include “stm32f7xx_hal_eth.h”

Now I rename stm32f7xx_hal_eth.h → stm32f7xx_hal_eth.h.bak

And Atollic edits the file:
#include “stm32f7xx_hal_eth.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.

[htibosch (Hein Tibosch)]

heinbali01 wrote on Friday, October 12, 2018:

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*_hal_eth*” 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 STM32_HAL_LEGACY in main.h, then there are a number of definitions missing.
GPIO_SPEED_HIGH, for example, is in stm32_hal_legacy.h.

In main.c you do not need stm32f7xx_hal_eth.h, so you could define :

	#define __STM32F7xx_HAL_ETH_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().

[system]

abeowitz wrote on Sunday, October 14, 2018:

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…

[htibosch (Hein Tibosch)]

heinbali01 wrote on Sunday, October 14, 2018:

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