I found an issue with the latest STR9 demo and lwip library. ( I am using IAR 5.40 if that makes any difference.. ). I thought this kind of performance is simply wrong and started investigating, I saw alarming things on wireshark ethernet analyzer( previous segment lost, duplicate ack, tcp retransmission etc ). After that I thought it has had to work at some point, otherwise it wouldn’t be included as official demo. After that I tried several versions to trace down where it stopped working. freeRTOS 4.72 works fine( instantaneus page load, no failures on wireshark ). With 4.80 I have exactly same issues as with the new release. Then I looked into subversion for changes between these versions, it turns out that if I use queue.c before rev255 it works fine. ( this revision was supposed to be more efficient re-implementation of queue ). I didn’t try to see what exactly caused the issue on queue.c as the change was almost complete re-implementation. Would it be safe to use the old rev 222 queue.c with the new 5.4 freeRTOS ? Does anyone have ideas how it caused this kind of complication for this demo? ( I believe that the problem is very confined and has not been widely known because of that ). I saw one post on this forum complaining about this demo after the change was made back in 2008 https://sourceforge.net/forum/message.php?msg_id=5023157 Any help with this would be highly appreciated. -- teemu

Hi teemu, the observed behavior is very strange. I agree with you that the used compiler make not difference, so I use Eclipse (my preferred IDE ;-) to check the demo. It seems to work fine, and I have observed any problem with ethereal. Before all let me note that the demo included in FreeRTOS 5.4.2 uses old version of lwIP and ST Library. I made my test with: - ST Library v2.0 - lwIP v1.3.1 - FreeRTOS v5.4.2 Have you tested the demo using the latest version of lwIP? For sure I know that it is not easy for Richard to maintain all ports and demos updated and fully tested, but FreeRTOS, as it is, is time saving and a great starting point! :-) Regards, Stefano

I just tried…. IAR Embedded Workbench for ARM V5.40 FreeRTOS V5.4.2 ARM – lwIP – D configuration IP address 192.168.0.201 on a point to point cable …. and everything seems to be working well.  I did not experience any problems. Regards.

Thanks guys for quick answers.. Stefano, do you have any pointers what changes did you have to make to merge new lwip library, new ST library and the new freeRTOS together? I have been planning to do that too, but I was hoping to start from from something that works… Richard, on surface it looks like you tried with the same setup as me. I had different IP address and ethernet switch between the computer/board. Still I can reproduce this problem 100% with any freeRTOS version that is newer than 4.72. ( loading the web page looks to take about 30seconds ) and it works 100% with <=4.72 freeRTOS. If I use queue.c from 4.72 on 4.80  it works perfectly, that seems a bit odd… Richard, can you send me the binary you compiled? teemu at embeddeddevelopment co uk I am using IAR demo board not the ST one, however it has the same ethernet portion and same micro. It works perfectly with versions <4.72  ( it doesn’t have LCD but it seems harmless for the board ) I also tried it with all but ethernet tasks disabled( comment out task create )  On my setup I have ethernet switch between board and computer( tried to swap switch and cables too ). And I used ip address 192.168.0.100 besides the ip address, there are no other changes in code. For now I have been working on my application with the old kernel version and old libraries. I am hoping that everything will be fine when I upgrade libraries as stefano… If I figure out what is wrong with this, I will post my findings back here in case someone else will run into this.

Just sent binaries as requested. Regards.

Actually it is strange that it works with the queue implementation from 4.x as the API was changed slightly between the 4.x and 5.x code (hence the major version number change).  This is a section of the upgrade instructions: "The parameters to the functions xQueueSendFromISR(), xQueueSendToFrontFromISR(), xQueueSendToBackFromISR() and xSemaphoreGiveFromISR() have changed.  You must update all calls to these functions to use the new calling convention!  Your compiler might not issue any type mismatch warnings!" See: http://www.FreeRTOS.org/upgrading.html Regards.

Richard Thanks for the binaries. I get same issues with your compiled binary. ( same issue as any STR9 lwip demo I compiled with IAR 5.40, from freeRTOS sources 4.80 to date ) To clarify, when I used the old queue.c I used it with 4.80 freeRTOS before the change in API. I can reproduce the problem with 4.80, however that version is fine if copy just the queue.c from 4.72 or rev 222 from version control. Today I also tried to use freeRTOS 5.42 code with queue.c, semphr.h and queue.h from 4.72 ( to accommodate old queue on new code I also changed to xSemaphoreGiveFromISR calls on the interrupt handler of the demo ). This combination works perfectly. I didn’t find root cause why the new queue.c is allergic to my dev board. However I know that symptom developed with subversion change list 255( re-implementation of queue send receive functions ), that is between 4.72 and 4.80.  When the issue happens, page loading is very slow it seems like ethernet task is missing out sometimes on receive interrupts or the received data is lost. Then download continues only when the client re-sends ack. I assume this is as much as the lwip can send without getting ack from client, on ethernet analyzer it looks like it sends a few segments and then suddenly stops until client resends the acknowledge. I also tried to see if the issue could be due different rev microcontrollers, anything on ST errata didn’t really catch my eye. Text on my chip is STR912FA  W44X6 HPADZ V6 if someone is interested on comparing that to theirs.. Well, I should be happy that I get it working when using old queue… but it is alarming that I cant find why it is not working with the new version. Makes me wonder why it happens to me, as I would assume it has worked fine for most people. ( or maybe most people are just using the uip demo ). Anyway it worked for Richard….

Richard Thanks for the binaries. I get same issues with your compiled binary. ( same issue as any STR9 lwip demo I compiled with IAR 5.40, from freeRTOS sources 4.80 to date ) To clarify, when I used the old queue.c I used it with 4.80 freeRTOS before the change in API. I can reproduce the problem with 4.80, however that version is fine if copy just the queue.c from 4.72 or rev 222 from version control. Today I also tried to use freeRTOS 5.42 code with queue.c, semphr.h and queue.h from 4.72 ( to accommodate old queue on new code I also changed to xSemaphoreGiveFromISR calls on the interrupt handler of the demo ). This combination works perfectly. I didn’t find root cause why the new queue.c is allergic to my dev board. However I know that symptom developed with subversion change list 255( re-implementation of queue send receive functions ), that is between 4.72 and 4.80.  When the issue happens, page loading is very slow it seems like ethernet task is missing out sometimes on receive interrupts or the received data is lost. Then download continues only when the client re-sends ack. I assume this is as much as the lwip can send without getting ack from client, on ethernet analyzer it looks like it sends a few segments and then suddenly stops until client resends the acknowledge. I also tried to see if the issue could be due different rev microcontrollers, anything on ST errata didn’t really catch my eye. Text on my chip is STR912FA  W44X6 HPADZ V6 if someone is interested on comparing that to theirs.. Well, I should be happy that I get it working when using old queue… but it is alarming that I cant find why it is not working with the new version. Makes me wonder why it happens to me, as I would assume it has worked fine for most people. ( or maybe most people are just using the uip demo ). Anyway it worked for Richard….

Richard Thanks for the binaries. I get same issues with your compiled binary. ( same issue as any STR9 lwip demo I compiled with IAR 5.40, from freeRTOS sources 4.80 to date ) To clarify, when I used the old queue.c I used it with 4.80 freeRTOS before the change in API. I can reproduce the problem with 4.80, however that version is fine if copy just the queue.c from 4.72 or rev 222 from version control. Today I also tried to use freeRTOS 5.42 code with queue.c, semphr.h and queue.h from 4.72 ( to accommodate old queue on new code I also changed to xSemaphoreGiveFromISR calls on the interrupt handler of the demo ). This combination works perfectly. I didn’t find root cause why the new queue.c is allergic to my dev board. However I know that symptom developed with subversion change list 255( re-implementation of queue send receive functions ), that is between 4.72 and 4.80.  When the issue happens, page loading is very slow it seems like ethernet task is missing out sometimes on receive interrupts or the received data is lost. Then download continues only when the client re-sends ack. I assume this is as much as the lwip can send without getting ack from client, on ethernet analyzer it looks like it sends a few segments and then suddenly stops until client resends the acknowledge. I also tried to see if the issue could be due different rev microcontrollers, anything on ST errata didn’t really catch my eye. Text on my chip is STR912FA  W44X6 HPADZ V6 if someone is interested on comparing that to theirs.. Well, I should be happy that I get it working when using old queue… but it is alarming that I cant find why it is not working with the new version. Makes me wonder why it happens to me, as I would assume it has worked fine for most people. ( or maybe most people are just using the uip demo ). Anyway it worked for Richard….

Richard Thanks for the binaries. I get same issues with your compiled binary. ( same issue as any STR9 lwip demo I compiled with IAR 5.40, from freeRTOS sources 4.80 to date ) To clarify, when I used the old queue.c I used it with 4.80 freeRTOS before the change in API. I can reproduce the problem with 4.80, however that version is fine if copy just the queue.c from 4.72 or rev 222 from version control. Today I also tried to use freeRTOS 5.42 code with queue.c, semphr.h and queue.h from 4.72 ( to accommodate old queue on new code I also changed to xSemaphoreGiveFromISR calls on the interrupt handler of the demo ). This combination works perfectly. I didn’t find root cause why the new queue.c is allergic to my dev board. However I know that symptom developed with subversion change list 255( re-implementation of queue send receive functions ), that is between 4.72 and 4.80.  When the issue happens, page loading is very slow it seems like ethernet task is missing out sometimes on receive interrupts or the received data is lost. Then download continues only when the client re-sends ack. I assume this is as much as the lwip can send without getting ack from client, on ethernet analyzer it looks like it sends a few segments and then suddenly stops until client resends the acknowledge. I also tried to see if the issue could be due different rev microcontrollers, anything on ST errata didn’t really catch my eye. Text on my chip is STR912FA  W44X6 HPADZ V6 if someone is interested on comparing that to theirs.. Well, I should be happy that I get it working when using old queue… but it is alarming that I cant find why it is not working with the new version. Makes me wonder why it happens to me, as I would assume it has worked fine for most people. ( or maybe most people are just using the uip demo ). Anyway it worked for Richard….

Same binary but different hardware.  Maybe there is something marginal in the timing which my (probably older) board is happy with while yours is not.  The new queue implementation is a bit faster than the old. Probably clutching at straws now. Regards.

Richard Thanks for the binaries. I get same issues with your compiled binary. ( same issue as any STR9 lwip demo I compiled with IAR 5.40, from freeRTOS sources 4.80 to date ) To clarify, when I used the old queue.c I used it with 4.80 freeRTOS before the change in API. I can reproduce the problem with 4.80, however that version is fine if copy just the queue.c from 4.72 or rev 222 from version control. Today I also tried to use freeRTOS 5.42 code with queue.c, semphr.h and queue.h from 4.72 ( to accommodate old queue on new code I also changed to xSemaphoreGiveFromISR calls on the interrupt handler of the demo ). This combination works perfectly. I didn’t find root cause why the new queue.c is allergic to my dev board. However I know that symptom developed with subversion change list 255( re-implementation of queue send receive functions ), that is between 4.72 and 4.80.  When the issue happens, page loading is very slow it seems like ethernet task is missing out sometimes on receive interrupts or the received data is lost. Then download continues only when the client re-sends ack. I assume this is as much as the lwip can send without getting ack from client, on ethernet analyzer it looks like it sends a few segments and then suddenly stops until client resends the acknowledge. I also tried to see if the issue could be due different rev microcontrollers, anything on ST errata didn’t really catch my eye. Text on my chip is STR912FA  W44X6 HPADZ V6 if someone is interested on comparing that to theirs.. Well, I should be happy that I get it working when using old queue… but it is alarming that I cant find why it is not working with the new version. Makes me wonder why it happens to me, as I would assume it has worked fine for most people. ( or maybe most people are just using the uip demo ). Anyway it worked for Richard….

Hi teemu, you can find the demo at the following link http://developers.stf12.net/just-another-eclipse-demo-str91x#TOC-Download. Please note that version uses lwIP v1.3.1-RC2. I will upload the lwIP v1.3.1 STABLE in the next days. Just a consideration: I’m sorry if this could seems stupid, but have you tried the demo using the board directly connected to the PC (without the switch)? This is in order to have a test environment as similar as possible, and to try to reduce the variables of this strange behavior. Regards, Stefano

somehow my post last time duplicated here, sorry for that.. Richard, I agree that it has something to do with marginal timings. I gave up on trying to find out the root cause and upgraded to ST’s new libraries as it is better starting point. After using ST library 2.1 and 2.0 ( separate library for MCU and ethernet ), I got rid of this issue.  This was with everything else the same as original STR9 demo on freeRTOS 5.4.3 With new ST library I can run the demo 24hours on autorefresh no problem. Before when I thought that the old queue fixed problem, that wasn’t 100% the case. After an hour or so on continous refresh the page started to get timeout issues( although it was still faster than new queue version and no other errors than timeout on wireshark ). Stefano, thanks for providing your port. It is better starting point for people looking into using STR9 with freeRTOS as it has new versions of everything, meaning probably less bugs and better support.. Richard, it would be nice to have a link to here.

>Richard, it would be nice to have a link to here. I think there are some links on the "Contributed Ports" page, and maybe others too. Regards.

Hi teemu, please note that in the "Contributed Ports" page there already is a link to my demo ;-) I only try to keep together some pieces of the puzzle… the big work is to build those pieces like FreeRTOS. I hope to give my contribution to the embedded world with my work on Eclipse (ODeV)… if it ever ends! :-) Just a note about the ST library and the Ethernet library particularly: it is very time consuming to adjust the Ethernet library for the FreeRTOS demo due to the library delay management and others architectural choices that enforce a code review. If you have adjusted Ethernet lib 2.0, could you kindly send it to me so I will update my demo sources? Regards, Stefano