Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

uip demo for gcc: test results

Posted by Rainer on April 26, 2006
ok, i hadn't understood the part about the semaphore initialization etc. and why they were separately declared until your explanation.

about the rmii: i think i told you already that i read on http://www.at91.com/www/phpBB2_mirror/viewtopic.php4?t=1573 that that the errata supposedly say rmii isn't supported any more by atmel because of some bug.

anyways, i tested the uip demo, and it looks good. there's still a couple problems though:
- The stack values do go down:
initial values (shown at first page load):
uIP: 192, IDLE: 122, each LEDx: 118
in the second page load, i already have uIP at 7 (seven!). i have to refresh manually, as the page doesn't have an auto-refresh (i might add one to look). anyways, i tried my wget loop script on /cgi/rtos and after 40000 page hits, IDLE stays at 122, each LEDx settled to an apparently stable 108, uIP is still at 7. damn that looks low! but the thing is, it runs stably anyways (i didn't go beyond 40000, though)

so now for the real problem: /cgi/tcp. when i load that page, i've occasionally seen the uIP stack size drop to 4 before crashing. sometimes it crashes even before displaying the /cgi/tcp page. when i leave plenty times between manual refreshes of that page, i get about 40 or so done before the crash. with a wget loop, it crashes immediately after the first. actually, if i wget /cgi/rtos and then /cgi/tcp inside the same loop, it crashes on the first attempt of getting /cgi/tcp.
unlike the lwip demo, where the leds kept blinking while the tcp stack froze, i'm talking of a real crash with leds freeze here.

so that leaves me with the following questions:
- while the end stack size of 108 (down from 118) for LEDx still looks comfy, the stack size of uIP going down from 192 to 7 seems abnormal (/cgi/rtos still loads correctly though, 40000 times and on). is that a problem? if so, do you have a clue about where it could be?
- there's definitely a problem with the page /cgi/tcp. i can systematically bring all to crash by loading the page quickly (via wget loop) 2 times or reloading it manually 50 or so times at most. in contrast, /cgi/rtos loads fine 40000 times and more even with a uIP stack size of 7.
- did you also have those problems? if not, could you send me your rtosdemo.bin, and maybe one compiled with iar, so as to look if there's a compiler issue?
for reference, here's my wget loop bash script. i guess it should work in cygwin too if you have bash and wget installed and start the script out of a bash shell:
----------------------
#!/bin/sh
while true
do
wget http://10.0.3.204/cgi/tcp
done
----------------------
when i tested, i had -O0 optimizations in though. could that be a prob?

RE: uip demo for gcc: test results

Posted by Rainer on April 26, 2006
with "didn't go beyond 40000" i meant that i stopped the script. there was no crash even at more than 40000.

completely unrelated: i forgot to add an 'all' target in the makefile. some programs expect that (as i recently discovered with eclipse) and it's a good common practice, so i suggest adding
all: rtosdemo.bin
as the very first (!) target in Makefile
(btw, you did it again. in your zip you had it as makefile ;-)


RE: uip demo for gcc: test results

Posted by Richard on April 26, 2006
> about the rmii: i think i told you already that i read on
> http://www.at91.com/www/phpBB2_mirror/viewtopic.php4?t=1573 that that the errata
> supposedly say rmii isn't supported any more by atmel because of some bug.

I got a couple of boards in their original pre-release configuration, which was RMII. I modified one myself to use MII, so I could support both, although as you say RMII is not longer recommended. My MII board is used for the online demo, so generally when testing I use the RMII board. The configuration works for the most part but is not as robust as MII.

> anyways, i tested the uip demo, and it looks good. there's still a couple problems
> though:
> - The stack values do go down:
> initial values (shown at first page load):
> uIP: 192, IDLE: 122, each LEDx: 118
> in the second page load, i already have uIP at 7 (seven!). i have to refresh
> manually, as the page doesn't have an auto-refresh (i might add one to look).
> anyways, i tried my wget loop script on /cgi/rtos and after 40000 page hits,
> IDLE stays at 122, each LEDx settled to an apparently stable 108, uIP is still
> at 7. damn that looks low! but the thing is, it runs stably anyways (i didn't
> go beyond 40000, though)


Wow 7 is too low. The stack used by the uIP task is set at 250 by default I think. This value comes from the IAR demo. GCC uses (much) more stack for library function, and command line GCC even more than the Rowley configuration. This needs to be raised. It is good that it does not shrink further though, which would indicate that it is executing correctly.


> so now for the real problem: /cgi/tcp. when i load that page, i've occasionally
> seen the uIP stack size drop to 4 before crashing. sometimes it crashes even
> before displaying the /cgi/tcp page. when i leave plenty times between manual
> refreshes of that page, i get about 40 or so done before the crash. with a wget
> loop, it crashes immediately after the first. actually, if i wget /cgi/rtos
> and then /cgi/tcp inside the same loop, it crashes on the first attempt of getting
> /cgi/tcp.
> unlike the lwip demo, where the leds kept blinking while the tcp stack froze,
> i'm talking of a real crash with leds freeze here.


Does this also happen with a bigger stack?


>
> so that leaves me with the following questions:
> - while the end stack size of 108 (down from 118) for LEDx still looks comfy,
> the stack size of uIP going down from 192 to 7 seems abnormal (/cgi/rtos still
> loads correctly though, 40000 times and on). is that a problem? if so, do you
> have a clue about where it could be?


The cgi/rtos uses a lot of string handling functions to generate the table of tasks. This under GCC will eat your stack. Also note the comments on the WEB site that this function is good for debug and demonstration, but not good for production code as it leaves interrupts disabled for the entire time the table is being generated which can cause problems for your real time performance, missing interrupts, etc.


> - there's definitely a problem with the page /cgi/tcp. i can systematically
> bring all to crash by loading the page quickly (via wget loop) 2 times or reloading
> it manually 50 or so times at most. in contrast, /cgi/rtos loads fine 40000
> times and more even with a uIP stack size of 7.
> - did you also have those problems? if not, could you send me your rtosdemo.bin,
> and maybe one compiled with iar, so as to look if there's a compiler issue?
> for reference, here's my wget loop bash script. i guess it should work in cygwin
> too if you have bash and wget installed and start the script out of a bash
> shell:

Just try with a larger stack. If you still have the problem I will send over some binaries.

Regards.

RE: uip demo for gcc: test results

Posted by Rainer on April 26, 2006
looks like you're right:
i increased mainUIP_TASK_STACK_SIZE from 250 to 400 and now the uIP stack size settles at an apparently stable 148 (i'm at 20000 page hits, alternating cgi/rtos and cgi/tcp in a script loop). one LEDx went down to 107 (i thought i had it at a stable 108 before, after 40000 hits to cgi/rtos)

at first, i tried to set mainUIP_TASK_STACK_SIZE to 500, but that somehow crashed immediately. must overlap with some other stuff. any idea?

Regards.

RE: uip demo for gcc: test results

Posted by Nobody/Anonymous on April 26, 2006
Most likely cause is that you just ran out of heap space. When you start the scheduler the idle task is created. If there is not enough RAM left in the heap the task cannot be started and the function to start the scheduler just returns.

RE: uip demo for gcc: test results

Posted by Rainer on April 26, 2006
update: i'm at 24000 rtos hits +24000 tcp hits, alternating, so that's 48000 total. stack sizes look stable. everything's looking good (and that's under a quite fast attack by wget requests, actually)

RE: uip demo for gcc: test results

Posted by Rainer on April 26, 2006
62000+ hits, all stable
ok cool. looks like a success.
thanks again, Richard.

I'll do some more automated request bombing and stress tests during the night.

to come thinking of it: maybe in the lwip case it was just a matter of stack size as well. i can't remember trying with an increased stack size for lwip.

Regards.

RE: uip demo for gcc: test results

Posted by Eddie on April 27, 2006
Well we are playing with the lwip stack for some time with the at91sam7x-ek. But we still haven't got it up and running lik we want.

We are working with the rowley demo and the commandline compiler. We added a filesystem to the demo from wich the website is running.

And we encounterd some stack problems, some buffers needed enlargement. And now we are struglling with the netcom_write function in the stack.. So bit more to do there I supose ;).


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists