Hi
I found the forum very helpful so i might as well try the luck again.
We are using KSDK with FreeRTOS 8.1.2 and LWIP 1.4.1 on a K64.The HW Ethernet solution the same as in the tower solution.
The Ethernet connectetion are currently working without problems, however the TCP/IP messages takes to long time.
Round trip delay might be up to 2000 ms and sometimes messages needs to be resent.
Im not sure if there are messages lost. We are not sending a lot of traffic so we don´t think it will a result of that.
If we use the RTOS to get the CPU usage, it indicates that the IDLE-task uses 98 % of the system.
I have tried the following without result.
- Changed interrupt/ task priorities to see if this affect the timing. ( No result. )
- Changed buffer sizes in the LWIP condiguration ( No result. )
- Turning on the debugging messages in the LWIP-stack ( No result. )
- Measuring the time from where the message is received in the application layer to the time the message is sent: 300 us.
- I have tried to change configuration settings in the IP-stack; for example turning of MEMP_SANITY_CHECK.
- Disabling ALL code without the Ethernet communication. ( No result )
I have attached the LWIP configuration file as well as the FreeRTOS configuration file.
Worth to mention is that the application is ported to a K64 and was working without this problem before the porting.
The configuration files are based upon the old configuration.
Best regards,
/ Anders
Original Attachment has been moved to: FreeRTOSConfig.h.txt.zip
Original Attachment has been moved to: lwipopts.h.txt.zip
Hi Anders,
Looks like you updated FreeRTOS as well as LwIp in KSDK, right? Did you also apply any modification to KSDK driver code?
BTW, which KSDK version was used for your application, please kindly help to clarify.
Thanks and Best Regards,
Kan
Yes, We did that.
Yes, we upgrdaded the FreeRTOS and the LWIP stack We have done some modifications to the drivers, for instance the SPI driver but not anything that will affect the Ethernet communication.
Do you recommend that we do an upgrage/downgrade for some of the libraries?
We are still running with KSDK 1.0 and have not upgraded yet.
/ Anders
Hi Anders,
Thanks for the information! Is it OK to have a review of your porting code for FreeRTOS 8.1.2 and LwIp 1.4.1?
Thanks and Best Regards,
Kan
Hi,
Well, i Might have time to do this.
But our project that are using K64 are put on ice for a few weeks, so i won´t have time to try all suggestions mentioned above for a few weeks.
I do have one question regarding the upgrade though?
I have noticed that the code gets stuck in FreeRTOS in vListInstert function.
This can depend on several possibilities. Is it possible that this can be a result of of a mismatch with KSDK, FreeRTOS and Lwip driver?
Best regards
/ Anders
Hi, Anders
Were you able to try all the suggestions?, Are you still having problems?
Regards
Patricia
Hi,
We have now been able to try some ot the suggestions. The problems was not in the SW but in the HW.
The PHY-circuit was constantly resetting due to a capacitor that was reacharing. Also, the PHY circuit used
was KSZ8081, instead of KSZ8041 as intended, wich caused problems in the TX side as well.
We have to to a HW update to solve this.
Thanks for all help!
/ Anders
Anders,
We are currently using the K64 with a KSZ8081 with no issues. We have never latency that exceeds 10ms. for any Ethernet process. Just be sure your schematic is the same as the demo board.
George
Hi Andres,
I've found this post while searching for some info regarding the Ethernet of the FRDM K64.
I didn't understand one thing... You wrote:
the PHY circuit used
was KSZ8081, instead of KSZ8041 as intended
But, the scheme of the FRDM K64 does use the KSZ8081, and not the KSZ8041.
So I didn't understand what seems to be the problem...
Thx,
Roy
I am seeing the FreeRTOS + LWIP demo (httpserver) getting stuck in vListInsert, compiled straight out of KSDK 1.1 with GCC
Hi Anders
On the K64 you need to either disable cache - old errata e2647 which is actually solved in the K64 but can cause Ethernet problems when the workaround isn't used and Ethernet is - or else work with Tx frame interrupts - see errata e6358.
This errata is not included in the K64 document but allows correct operation when the cache is enabled.
Otherwise other potential difficulties are clock problems in RMII mode - make sure that the clock is from a single 50MHz source to ensure ENET and PHY are synchronised.
If using a design from the FRDM-K64F board without PHY interrupt in RMII mode make sure that you are polling the PHY's status register and synchronising the ENET to the PHY's settings otherwise high data loss can also occur.
In case of difficulties compare with the references in the links below.
Regards
Mark
Kinetis: µTasker Kinetis support
K64: µTasker Kinetis FRDM-K64F support / µTasker Kinetis TWR-K64F120M support
For the complete "out-of-the-box" Kinetis experience and faster time to market
I will try this in a few weeks time.