160112_FreeRTOS_Labs Porting to IAR EWARM and STM32F469I-EVAL Board

Kernel
1

nomad8201 wrote on Monday, August 22, 2016:

I have ported the FreeRTOS_Plus_TCP_and_FAT_STM32F4xxx demo in the 160112_FreeRTOS_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 160112_FreeRTOS_Labs 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 STM32Cube_FW_F4_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?

2

heinbali01 wrote on Tuesday, August 23, 2016:

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.

3

nomad8201 wrote on Tuesday, August 23, 2016:

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:

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

stm32f4xx_hal_sd.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 160112_FreeRTOS_Labs.zip download.

stm32f4xx_hal_sd.c - In the standard file, the HAL_SD_Init() function unconditionally initializes tmpinit.BusWide to SDIO_BUS_WIDE_1B. So, I changed this to the following, which I copied from the same file in the 160112_FreeRTOS_Labs.zip download:

#if( BUS_4BITS != 0 )
{
	tmpinit.BusWide             = SDIO_BUS_WIDE_4B;
}
#else
{
	tmpinit.BusWide             = SDIO_BUS_WIDE_1B;
}
#endif

Thanks,

Damon

4

heinbali01 wrote on Tuesday, August 23, 2016:

Hi Damon,

I remember that I made quite a few changes to :

    STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_eth.c

As I also made many style changes, I don’t remember if there were many essential or functional changes.

Which version of ‘stm32f4xx_hal_eth.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.

5

nomad8201 wrote on Wednesday, August 24, 2016:

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 160112_FreeRTOS_Labs.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.

6

heinbali01 wrote on Wednesday, August 24, 2016:

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

7

nomad8201 wrote on Wednesday, August 24, 2016:

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.

8

nomad8201 wrote on Tuesday, September 13, 2016:

Hello Hein,

I tried running the FreeRTOS_Plus_TCP_and_FAT_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 FreeRTOS_Plus_TCP_and_FAT_STM32F4xxx demo?

9

rtel wrote on Tuesday, September 13, 2016:

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.

10

heinbali01 wrote on Tuesday, September 13, 2016:

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

11

nomad8201 wrote on Tuesday, September 13, 2016:

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 160112_FreeRTOS_Labs 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)?

12

heinbali01 wrote on Thursday, September 15, 2016:

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.