gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > dswifilib, DevKitARM and stack... crash boom

#107755 - ttursas - Wed Nov 01, 2006 8:00 pm

Here we go again... I haven't released a new version of Wright Flight because once again
dswifilib crashes the game. I just send one UDP packet and boom. The interesting thing is
that this all worked fine four days ago. After adding some code and data files to the game
the crashes started again (happened before, but the latest dswifilib release fixed that for
a while).

I've been through my code and I've disabled a big part of it, and there doesn't seem to be
anything wrong with it. I've replaced the memory managed in dswifilib, but no help there.
Every time I send one UDP packet the game crashes. The irqs work on ARM9, but the
main and the only thread gets stuck at the end of one function. It doesn't return from there
even though there's nothing blocking it. So it is a stack problem?

Anyway, this got me thinking.

arm9/build/.map says:
Name Origin Length
rom 0x08000000 0x02000000
ewram 0x02000000 0x003ff000
dtcm 0x0b000000 0x00004000
itcm 0x01000000 0x00008000
*default* 0x00000000 0xffffffff

... and...

.stack 0x00080000 0x0
0x00080000 _stack = .
*(.stack)

...

I don't move DTCM myself, but does DevKitARM's stuff move it? Is there any RAM at
0x80000 in NDS? If not, where is my stack!? :)

Any ideas? All help is appriciated...

#107765 - ttursas - Wed Nov 01, 2006 8:59 pm

After cleaning the code and doing small changes here and there the game gets stuck
after connecting to an AP. Previously that worked... Any ideas? I'm using M3-SD...

#107773 - ttursas - Wed Nov 01, 2006 9:59 pm

I cleaned up the code more, and now the following happens: I can connect to an AP and
it's ok, the game continues without crashing. Now, if I send an UDP packet to my PC the
game will crash pretty soon. It doesn't matter if I have my server running on my PC or not.
A crash will follow. But if I send that UDP packet to an IP where I have no PC -> no crash.

I'm doing connectionless UDP, sendto() and recvfrom().

Also, I'm doing C99 stuff. Could this be the culprit? I.e. // comments and I'm allocating
variables on the fly, not at the beginning of the function. And when I've moved the introduction
of those variables to the beginning of the function dswifilib has worked a bit better. ???
Not much, I still have crashes, but less often...

#107779 - ttursas - Wed Nov 01, 2006 11:20 pm

According to this page

http://gcc.gnu.org/gcc-4.1/c99status.html

The two C99 features I'm using, "// comments" and "mixed declaration and code" should
work... Hmm...

#108071 - ttursas - Sun Nov 05, 2006 12:49 am

I got it to work again, by doing the following things (taken from Wright Flight's CHANGELOG):

* Removed TCP code from dswifilib, and changed the two framehdr[] arrays that were
allocated from stack to be larger and allocated from heap apparently fixing the network
play as it works again. Also rewrote memcpy() and strncpy() so that no libg is needed
for them by dswifilib.

...

Don't really know 100% what's going on, but that solved my problems, and it works again!
And if it breaks once more, I'll get back to this. :P

#115284 - ttursas - Sun Jan 14, 2007 5:23 pm

dswifilib seems to eat quite a lot of stack, especially in ARM7 interrupts.
Wifi_ProcessReceivedFrame() is a good example of this. Taking a look at the default
devkitPRO link script output (or whatever it's called), it seems that interrupts have a 256
byte stack. Is this true? Anyway, I'll move all those 512 byte arrays to heap, and release
the stripped version (that can only do UDP) on Wright Flight www-page
( http://www.iki.fi/~vhelin/nintendoDS.html ).