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 > HELP! filesystem problem while using interruption handler

#154376 - gorgull - Tue Apr 15, 2008 12:09 pm

Hello,

I'm the ProteinDS author: http://gorgull.googlepages.com/protein
and I'm actually stuck on a very very annoying problem, which I guess is related to the Fat library.

Basically, in arm9 processor, I'm using a fifo interruption handler triggered by an arm7 timer, as an audio callback system. As my program streams audio data from cartridge, fread is called every single audio frame (even several times during each audio frame, when several tracks play at the same time) - no problem with that, it works perfectly well.

The problem happened when started to call fopen out of the audio callback: sometimes fopen failed (or even crashed); it took me a few days to think fopen call may be interrupted by audio callback, so may be messed up then (am I right?).

So I decided to do every filesystem calls in the audio interrupt, in order to avoid fopen to be interrupted during its execution; my guess seemed good: no more fopen failure, but another problem happened: depending on the current processing and the size of the file I want to open, fopen call locks the audio fifo interrupt handling - arm7 timer still goes on, but arm9 side interruption is totally locked (the more processing during the audio frame and the more sized file I want to open, the more chance I got a failure) :-/

Do I need to push then pop some special registers before every filesystem calls or something like that?

As I'm more a computer developer, I can't really figure out what's behind filesystem calls on DS hardware.

Does anyone have an idea about what I could do about this?

Thx in advance :-)

#154380 - simonjhall - Tue Apr 15, 2008 1:23 pm

Hang on, so when are you doing the fopen?

It's okay to do file access in interrupt handlers, as far as I can tell. The interrupts are not nested, y'see. However you need to ensure that file access is not done from multiple threads so don't do file stuff in the main thread as well as interrupt handlers, or if you do make sure you put some kind of locking around all file-related functions.
_________________
Big thanks to everyone who donated for Quake2

#154382 - gorgull - Tue Apr 15, 2008 1:35 pm

Quote:
Hang on, so when are you doing the fopen?


At first, I was doing fopen calls in the "main" execution thread (the VBlank one), and fread calls in the audio interruption thread --> because interrupt has absolute priority, fread had no problem, but fopen sometimes failed.

Then I tried to put fopen in the same thread as fread, but when the files are big (several tens MB), interruption is locked after the fopen call (which succeeds anyway).

Quote:
It's okay to do file access in interrupt handlers, as far as I can tell. The interrupts are not nested, y'see. However you need to ensure that file access is not done from multiple threads so don't do file stuff in the main thread as well as interrupt handlers, or if you do make sure you put some kind of locking around all file-related functions.


I think the best and easiest for me is to keep fopen calls in main thread, but how to make sure interrupt won't happen in the middle of fopen call then?
If it's not possible, why does fopen lock the fifo execution when called in interruption thread?

#154383 - simonjhall - Tue Apr 15, 2008 1:55 pm

The only thread that can be interrupted (ie stopped mid-execution) with the current set-up is the main thread. So if you put anything file-related in there, make sure you put some atomic locks around those calls.
_________________
Big thanks to everyone who donated for Quake2

#154384 - gorgull - Tue Apr 15, 2008 2:17 pm

Quote:
The only thread that can be interrupted (ie stopped mid-execution) with the current set-up is the main thread.


I got it - that's what my fopen failed in the first place.

Quote:
you put some atomic locks


How can I use an atomic lock, as I don't know when an audio callback will happen?

#154387 - thoduv - Tue Apr 15, 2008 4:05 pm

gorgull wrote:

Quote:
you put some atomic locks


How can I use an atomic lock, as I don't know when an audio callback will happen?

Lock:
Code:
u32 lock = REG_IME;
REG_IME = 0;

Unlock:
Code:
REG_IME = lock;

That way, you can be sure the code between lock/unlock won't be paused by an interruption of any kind.

#154524 - gorgull - Thu Apr 17, 2008 12:47 pm

Ok, thanks for the answer.

I just tested this lock around fopen, which is called in the main thread.

Unfortunately, the result is the same as if I call fopen in the audio thread : the interrupt locks just after the fopen call.