devkitPro

Hello,

I have a homebrew project I have been developing on and off for a few years, and I only recently upgraded to the latest version of libnds. The conversion went smoothly and I continued work using the DeSmuME emulator for testing.

Well, when I finally got around to trying the program out on my actual DS, it started crashing in arbitrary, but reproducible circumstances. I switched emulators to NO$GBA, and it reproduced the same crashes. Needless to say, i am continuing development with NO$GBA.

I was able to track the crashes down to the swiWaitForVBlank() function, with some weird consequences for including some of the old interrupt initialization routines.

If I have this:

int main {
...
irqInit();
irqEnable(IRQ_VBLANK);
...
swiWaitForVBlank();
...
}

then the game does not crash, but the X button does not work. I assume the X button problem is based on the fact that irqInit() is no longer necessary and messes up ARM7 interrupts.

So if I try:

int main {
...
irqEnable(IRQ_VBLANK);
...
swiWaitForVBlank();
...
}

then swiWaitForVBlank() crashes during certain actions.

Trying:

int main {
...
// (none)
...
swiWaitForVBlank();
...
}

crashes in the same way.

For completeness, trying:

int main {
...
irqInit();
...
swiWaitForVBlank();
...
}

results in sprites not being loaded and a general mess.

I realize that you can't help debugging this problem without more code, so I'm not asking for that (unless there is something specific you'd like to see). What I'm hoping for is suggestions on what sort of problem might be causing swiWaitForVBlank() to crash during actions like "attack when facing up" but not during "attack when facing down".

Thanks,
Quazgaa

don't call irqInit, this has already been initialised and the VBLANK IRQ enabled before you hit main. You'll note that none of the example code calls irqInit and haven't since devkitARM release 24 in December 2008.

http://www.devkitpro.org/devkitarm/devk ... -surprise/

OK, thanks. That's what I thought.

Any thoughts on what might cause swiWaitForVBlank() to crash? Again, it crashes in NO$GBA and an actual DS, but not in DeSmuME. It doesn't crash every time, but always under the same circumstances.

Quazgaa wrote:OK, thanks. That's what I thought.

Any thoughts on what might cause swiWaitForVBlank() to crash? Again, it crashes in NO$GBA and an actual DS, but not in DeSmuME. It doesn't crash every time, but always under the same circumstances.

/me steals WinterMute's normal request line:

Please provide a minimal working example that causes swiWaitForVBlank() to crash so that we can attempt to understand the cause of the crash.

I'll see if I can reduce it down to a minimal example. Maybe I will find out more details in the process.

Well, in the process of reducing to a minimal example, I found out what was causing the crash. It was a mistake that boiled down to dereferencing a null pointer.

How it didn't crash the game until swiWaitForVBlank() or got past the DeSmuME emulator I'll never know, but it accounts for all of the cases where the game crashed, and I consider this probelm solved.

Thanks for forcing me to look a little harder.

if you got it boiled down to a minimal enough example I'd like to take a look at it and make desmume repro nocash and the hardware. I did a quick test on the arm9 of dereferencing a null pointer and calling swiWaitForVBlank() and it ran unimpeded in nocash..