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 > Runs in Desmume but not from M3i Zero

#174138 - JackUzi - Thu May 20, 2010 12:35 am

Hi

I've been working on porting a program to the DS for a while now and it is now running very well on Desmume. Unfortunately though, when I put it on my M3i Zero/ DSi XL it hangs at a certain point. I put a whole lot of debugging statements in and I see one displayed just before calling a function but not the one at the top of the function being called. Well, when I say the top it is the first line of code below the local variable declarations. It's not highly recursive so I don't think it is a stack overflow.

This function gets called several times successfully before the hang. The code itself is about 15 years old and has been running without trouble on many other systems so I am reasonably confident that it isn't a bug in the code itself, although I can see how sometimes bugs can lay dormant until the code is run on an unusual system.

I've read that the M3i Zero doesn't have great homebrew compatibility, so I guess I'm trying to find out if this is the likely cause and if so, is there anything that can be done about it. I see there is an M3 specific version of DSOrganize. Does anyone know what types of things get changed to make card-specific versions like that beyond the usual DLDI patch? Any other of tricks, techniques or tools for debugging this type of hang on the hardware DS only???

Thanks in advance for any advice,
Stuart

#174139 - elhobbs - Thu May 20, 2010 2:20 am

Did you install the defaultexceptionhandler? Does it crash or just hang? If it fails entering a function that leads me to think it is stack related. The ds only has 16k of stack by default - very easy to run out.

#174140 - JackUzi - Thu May 20, 2010 2:46 am

No, I didn't know about the defaultexceptionhandler. I'm very new to DS development, I'll do some searches and read up on it. Thanks for making me aware of it.

EDIT: I just add the call to defaultExceptionHandler() and nothing has changed, it just hangs at a certain point. I'm 99.999% sure it isn't an endless loop, so is is possible for an app to just hang without throwing an exception?

Hmmm, a 16K stack is very small. As this app came from the desktop environment it isn't very economical with a lot of resources. I will have a look at where I can make things a bit leaner, but is there a way to bump this up beyond the default?

EDIT: You're a life saver. I just reduced the size of the local character array defined at the top of that function and it is working now. I really do need the size though so I either need to bump the stack up or malloc from the heap I guess. THANK YOU!!!

Thanks again for you help,
Stuart

#174142 - JackUzi - Thu May 20, 2010 8:02 am

Okay, so the joy was a bit short lived. It is definitely better, but still hanging in certain places without any obvious reason. I don't think I'm using more that 16K of stack, but perhaps I'm having some sort of memory alignment issues. I've changed all the char arrays to be multiples of four, but things don't seem to have improved. Seems this porting to ARM isn't as easy as I hoped. ;)

Stuart

#174143 - elhobbs - Thu May 20, 2010 9:16 am

char arrays do not need to be aligned except if you use dma or need to flush or invalidate parts of the cache. Shorts and ints do need to be aligned though. The template makefile will handle this for you. However you can run into problems if you use struct packing or casting. Another thing that has caused me problems is assuming that enums are 4 byte ints.

It is possible to increase the stack size but it is not trivial and it has a serious performance impact as it requires moving the stack from a very fast memory region to main memory. Usually you are far better off reducing the stack requirements.

One way to test if something is crashed or an infinite loop is to close the screen. If the screen shuts off just before the lid closes then it is probably in a loop. If it does not turn off then it is probably crashed.

#174170 - JackUzi - Fri May 21, 2010 11:08 am

Just a quick note to say that I now have it working, and thank you for all your helpful pointers and tolerance of my noobishness. In the end I just kept whittling down the amount of local variables I used until it finally ran all the way through. I also made the handful of short ints that I used into ints just to avoid any potential problems there.

Thanks again,
Stuart