LwIP/FreeRTOS with KSDK 2.0

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LwIP/FreeRTOS with KSDK 2.0

Jump to solution
3,497 Views
tobiaswellnitz
Contributor II

Hi,

 

I have been trying for the last two days to integrate LwIP with KDSK 2.0. Unfortunately, with doubtful success. I just want to initialise the stack properly and retrieve an IP address via DHCP.

 

Whenever a packet is received (e.g. DHCP response from the router), the program gets stuck in one of the configAsserts(), either in xQueueGenericReceive or vPortEnterCritical().

The example project work perfectly and I can upload and debug them with the Segger OpenSDA v2 firmware. I tried to compare the files from the example projects with my own, but I couldn't find the mistake! I KDSK2 documentation is also pretty vage on how to integrate the lwip stack.

 

Here is the code: GitHub - dh1tw/BasicEthernet-K64F

 

After downloading the KSDK2.0 for my K64F I created a new (minimal + FreeRTOS) Project in KDS 3.1 using the Kinetis SDK 2.x Project Wizard. 

 

I copied the lwip stack manually into the project and included the paths:

../lwip_1.4.1

../lwip_1.4.1/port

../lwip_1.4.1/src

../lwip_1.4.1/src/include

../lwip_1.4.1/src/include/ipv4

../lwip_1.4.1/src/include/ipv4/lwip

../lwip_1.4.1/src/include/lwip

../lwip_1.4.1/src/include/netif

../lwip_1.4.1/src/include/posix

 

My Preprocessor symbols are:

DEBUG

CPU_MK64FN1M0VMD12

USE_RTOS=1

FRDM_K64F

FREEDOM

FSL_RTOS_FREE_RTOS

 

and I use the following compiler flags:

-fno-common  -ffreestanding  -fno-builtin  -mapcs

 

 

I would very much appreciate any help / feedback.

 

Thanks,

Tobias

Labels (1)
Tags (2)
1 Solution
1,688 Views
meilizhou
NXP Employee
NXP Employee

Hi Tobias,

      From your sceenshot and the code, the Ethernet frames are received by the receive interrupt handler. That mean when a Ethernet frame comes, the  ethernet_input->udp_input->dhcp_recv...->mem_alloc ... are all done in an interrupt context. However the sys_mutex_lock called in mem_alloc should not be used in an interrupt context.  Because the sys_mutex_lock will call vPortEnterCritical which will cause a ASSERT if it is called from an interrupt context. See more details in vPortEnterCritical in Port.c in freertos\source\.

Recommended solutions:

1.   Polling the Ethernet  Receive frames instead of calling by receive ISR.  So the receive frame will not be processed in an interrupt context.

changes should be done in ethernetif.c

2. If you prefer the interrupt context to receive the Ethernet frames, the ethernet_input should't be used as the netif input functions. changes must be done in this sentence " netif_add(&fsl_netif0, &fsl_netif0_ipaddr, &fsl_netif0_netmask, &fsl_netif0_gw, NULL, ethernetif_init, ethernet_input)" in main.c.

the tcpip_input (with LWIP_TCPIP_CORE_LOCKING_INPUT defined to 0) is a recommend input.

BTW, There are some issues in the main()

1. There is no tcp ip initialization in the main. the tcp ip init should be done there.

2. The vTaskDelay should not be called before vTaskStartScheduler.

View solution in original post

6 Replies
1,688 Views
FreeRTOS_org
Contributor IV

For future reference - it would be really helpful if you could say *which* configASSERT() was failing, then I would at least be able to tell you what the symptom of the problem was, if not actually what the cause of the problem was.  Many of the asserts will have comments with further information too.  In this case it might simply be an interrupt priority problem, but without knowing which assert it was I can't be sure.

1,688 Views
tobiaswellnitz
Contributor II

Hey Richard,

thanks for your reply! Find attached the debug screenshot where the program gets stuck (I presume in the moment it receives the DHCP response packet).

Screen Shot 2016-02-22 at 23.09.13.png

0 Kudos
1,689 Views
meilizhou
NXP Employee
NXP Employee

Hi Tobias,

      From your sceenshot and the code, the Ethernet frames are received by the receive interrupt handler. That mean when a Ethernet frame comes, the  ethernet_input->udp_input->dhcp_recv...->mem_alloc ... are all done in an interrupt context. However the sys_mutex_lock called in mem_alloc should not be used in an interrupt context.  Because the sys_mutex_lock will call vPortEnterCritical which will cause a ASSERT if it is called from an interrupt context. See more details in vPortEnterCritical in Port.c in freertos\source\.

Recommended solutions:

1.   Polling the Ethernet  Receive frames instead of calling by receive ISR.  So the receive frame will not be processed in an interrupt context.

changes should be done in ethernetif.c

2. If you prefer the interrupt context to receive the Ethernet frames, the ethernet_input should't be used as the netif input functions. changes must be done in this sentence " netif_add(&fsl_netif0, &fsl_netif0_ipaddr, &fsl_netif0_netmask, &fsl_netif0_gw, NULL, ethernetif_init, ethernet_input)" in main.c.

the tcpip_input (with LWIP_TCPIP_CORE_LOCKING_INPUT defined to 0) is a recommend input.

BTW, There are some issues in the main()

1. There is no tcp ip initialization in the main. the tcp ip init should be done there.

2. The vTaskDelay should not be called before vTaskStartScheduler.

1,688 Views
tobiaswellnitz
Contributor II

Thanks a lot for your hints, Meili!

Now everything works as expected!

I very much appreciate your explanations!

Thanks again!

0 Kudos
1,688 Views
DavidS
NXP Employee
NXP Employee

Hi Tobias,

Rather than start from scratch and build up the example, there is already a lwip_httpsrv_freertos_frdmk64f demo available in KSDK_v2 for the Freedom frdm-k64f:

C:\NXP\KSDK_v2\SDK_2.0_FRDM-K64F_KDS\boards\frdmk64f\demo_apps\lwip\lwip_httpsrv\freertos

I used it as starting point to modify the lwip_httpsrv_freertos.c source file to implement DHCP.

Attached is that file.

Also if you got http://nxp.com/ksdk and click the download tab, you can grab the

Kinetis SDK Project Generator Tool (REV 2) .

It can be used to create and/or clone example projects.

Regards,

David

1,688 Views
tobiaswellnitz
Contributor II

Hi David,

thanks a lot for the reply! Yes, I'm using the SDK 2.0 for the K64F from the mentioned links. I can confirm that all the examples compile and run flawless on the K64F board!

However I'm trying to understand the entire build process on the Cortex M4 / Kinetis development platform. That's why I try building this project from scratch.

And yes, I'm still fairly new to 32bit uCs and RTOS. Until recently I was working either on 8bit (Pics/AVRs) or 64bit platforms (Desktop) - hi.

I've also noted that KDS links to the various drivers and middleware files in the SDK folder, rather than copying them into the project folder.

I personally would prefer a KDS project which contains all the necessary files so that I can put the entire project and all its files under version control.

I presume that projects generated with the SDK2 Project Wizard and all the drivers / middleware (like lwip) are pre-configured with best practice parameters, right?

Thanks again for your reply!

Tobias

0 Kudos