160112_FreeRTOS_Labs Porting to IAR EWARM and STM32F469I-EVAL Board

I have ported the FreeRTOSPlusTCPandFATSTM32F4xxx demo in the 160112FreeRTOS_Labs project to build using the latest IAR EWARM 7.70 toolchain. Everything works on both the STM3241G-EVAL board, which contains an STM32F417IGH6 processor. So far, so good… Now I’m trying to get it to run on an STM32469I-EVAL board, which contains an STM32F469NIH6 processor. However, the CMSIS and HAL Driver files in the 160112FreeRTOSLabs project are not new enough to support the STM32F469xx processor. So, I updated my project with all the relevant CMSIS and HAL files from the latest STM32CubeFWF4_V1.13.0 repository and I actually got it to compile. However, now when I use my updated source tree to build for the STM3241G-EVAL board, the build succeeds but it won’t run on the STM3241G-EVAL board. Here is where it seems to be getting stuck: 1. IP-task task is created. 2. SvrWork task is created. 3. IDLE task is created. 4. EMAC task is created. 5. The vDHCPProcess() function sends a proper DHCP Discover packet and my network’s DHCP Server responds with a proper DHCP Offer packet, but the vDHCPProcess() function does not receive the packet. 6. No other tasks are created because of the failure in step 5. Any ideas?

160112_FreeRTOS_Labs Porting to IAR EWARM and STM32F469I-EVAL Board

Hi Damon, I only have a STM3240G-EVAL, as soon as I find time I will upgrade my CMSIS and HAL files and re-test it.

160112_FreeRTOS_Labs Porting to IAR EWARM and STM32F469I-EVAL Board

Hello Hein, That would be great. I should warn you that I had to change 3 of the new HAL files to get it to compile: stm32f4xxhalgpio.h – For some reason, ST decided to change the names of the GPIO speed definitions. So I added the following definitions for backward compatibility:
#define GPIO_SPEED_LOW      GPIO_SPEED_FREQ_LOW
#define GPIO_SPEED_MEDIUM   GPIO_SPEED_FREQ_MEDIUM
#define GPIO_SPEED_FAST     GPIO_SPEED_FREQ_HIGH
#define GPIO_SPEED_HIGH     GPIO_SPEED_FREQ_VERY_HIGH
stm32f4xxhalsd.h – The standard file does not have SD_EventSetupFunctionTypeDef or SD_EventWaitFunctionTypeDef definitions and does not have EventSetupFunction or EventWaitFunction elements in its SD_HandleTypeDef definition. So, I added these by copying them from the same file in the 160112FreeRTOSLabs.zip download. stm32f4xxhalsd.c – In the standard file, the HALSDInit() function unconditionally initializes tmpinit.BusWide to SDIOBUSWIDE_1B. So, I changed this to the following, which I copied from the same file in the 160112FreeRTOSLabs.zip download:
#if( BUS_4BITS != 0 )
{
    tmpinit.BusWide             = SDIO_BUS_WIDE_4B;
}
#else
{
    tmpinit.BusWide             = SDIO_BUS_WIDE_1B;
}
#endif
Thanks, Damon

160112_FreeRTOS_Labs Porting to IAR EWARM and STM32F469I-EVAL Board

Hi Damon, I remember that I made quite a few changes to : ~~~~ STM32F4xxHALDriverSrcstm32f4xxhaleth.c ~~~~ As I also made many style changes, I don’t remember if there were many essential or functional changes. Which version of ‘stm32f4xxhaleth.c’ do you use at this moment? About SDIO (the SD-card), I tried to access the card without DMA but that is impossible. Even optimised instructions like these : ~~~~ *pulFIFO = tempbuff[ 0 ]; *pulFIFO = tempbuff[ 1 ]; *pulFIFO = tempbuff[ 2 ]; … ~~~~ were too slow. I’m afraid that I also have to go through all source code and do some debugging to adopt the latest sources. Regards.

160112_FreeRTOS_Labs Porting to IAR EWARM and STM32F469I-EVAL Board

Hello Hein, I started with stm32f4xx_hal.eth.c V1.3.2, which is dated 26-June-2015. This is the one supplied in the 160112FreeRTOSLabs.zip download and I have not modified it. When I tried to upgrade the HAL drivers to the latest, the new HAL driver files are all V1.5.1 and are dated 01-July 2016. Thanks for working with me on this.

160112_FreeRTOS_Labs Porting to IAR EWARM and STM32F469I-EVAL Board

But can you somehow still use the older ‘stm32f4xxhaleth.c’ that was provided in the Labs release?

160112_FreeRTOS_Labs Porting to IAR EWARM and STM32F469I-EVAL Board

I’ll give it a try and let you know. I’ll configure the project for the STM32F469NI processor and I’ll use the startup_stm32f469xx.s C startup file and the stm32f469xI.icf linker command file. But, I’ll predefine STM32F429xx=1 instead of STM32F469xx=1, because STM32469xx is not supported by HAL V1.3.2 and STM32F429xx appears to be the closest cousin that is supported by HAL V1.3.2.

160112_FreeRTOS_Labs Porting to IAR EWARM and STM32F469I-EVAL Board

Hello Hein, I tried running the FreeRTOSPlusTCPandFAT_STM32F4xxx demo on an STM32469I-EVAL board, with the code configured as described in my last post. The Micro SD card appears to work as the code correctly writes all of the correct fattest and websrc files. However, Ethernet does not work. Any assistance you can provide would be greatly appreciated. Were you involved in the initial development of the FreeRTOSPlusTCPandFAT_STM32F4xxx demo?

160112_FreeRTOS_Labs Porting to IAR EWARM and STM32F469I-EVAL Board

Can you elaborate on “Ethernet does not work” – that covers a whole magnitude of issues, from forgetting to plug the cable in to having a badly configured DHCP server :o) Can the MAC talk to the PHY? Does the network link come up? etc. How far does it get. If it gets as far as attempting to send a DHCP request then please post a Wireshark capture of the DHCP traffic.

160112_FreeRTOS_Labs Porting to IAR EWARM and STM32F469I-EVAL Board

Hi Damon,
However, Ethernet does not work.
… is indeed not giving any useful information. As Richards asks, can the MAC talk to the PHY? Can you read the so-called Link-Status? Is it up? If you enable DHCP, you will see broadcast messages from an IP address 0.0.0.0. Do you see them on the LAN? You can also check if there is any reception of packets? Maybe you have a way of logging text, serially, or through USB? If not, put a break-point on the code-lines that received packets? You can also disable DHCP and do a simple test: wait for the network to be ready and send/broadcast some UDP packets. Debugging an Ethernet driver is never an easy task, I’m afraid

160112_FreeRTOS_Labs Porting to IAR EWARM and STM32F469I-EVAL Board

The MAC does talk to the PHY. Autonegotiation completes and the link status is up, full duplex and 100 MHz. DHCP is enabled, but the DHCP Discover packet does not appear in WireShark. I have the code fully functional on both the STM3241G-EVAL and STM32429I-EVAL1 boards. This was fairly straightforward, since the HAL drivers that are included in the 160112FreeRTOSLabs project support both the STM32F417IGH6 and the STM32F429NIH6 processors. However, the included HAL drivers do not support the STM32F469NIH6 processor on the STM32469I-EVAL board. Are there any plans to update the FreeRTOS Labs project to support the latest (v1.5.1) ST HAL drivers (which do support the STM32F469NIH6 processor)?

160112_FreeRTOS_Labs Porting to IAR EWARM and STM32F469I-EVAL Board

Hi Damon, I’m afraid that I can not find enough time to adopt the v1.5.1 ST HAL drivers into the STM project. If you want, you can email me ( h point tibosch at freertos point org ) with specific driver questions or send me PCAP’s to inspect.