uip demo for gcc: test results

rainer32 wrote on Wednesday, 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?

rainer32 wrote on Wednesday, 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

rtel wrote on Wednesday, 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.

rainer32 wrote on Wednesday, 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.

nobody wrote on Wednesday, 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.

rainer32 wrote on Wednesday, 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)

rainer32 wrote on Wednesday, 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.

wacko_eddie wrote on Thursday, 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 ;).