ARM9: data abort (0205F998)


the pointer at 020DD088 is NULL.

it is supposed to be initialized by another thread before the data-aborting code runs, but for whatever reason it's not happening.


BASIC FLOW of how things go, and why it shits itself


* function at 02008C28 initializes shit


first call, 0200C060, eventually starts the thread at 02011348 (thread that leads to the faulty memory access). at this point, the thread is started, but not run yet, but it's marked as ready to run.


second call, 0205EB1C, initializes the object whose pointer is stored at 020DD088. except:

it first allocates the memory for that object (0xF0 bytes)

then it calls the function at 0205EB5C, that does a lot of things

then it stores the allocated pointer to 020DD088 (after 0205EB5C is done).


* 0205EB5C

does a bunch of shit

eventually calls 020EFF64, which sends a request to the ARM7 to see whether headphones are connected. that function interacts with some thread sync/messaging objects. it eventually waits for a message indicating completion of the request (ie when the ARM7 responds), which triggers a reschedule.

WHICH IS WHEN THINGS GO WRONG.

basically, the thread at 02011348 runs, because it's ready to run and none of the higher-priority threads are ready to run.

that thread also tries sending a request to the ARM7, but that doesn't happen because there's already a request underway.

then it calls 02011308.

02011308 tries to use the pointer stored at 020DD088, except at this time it's not initialized yet, so it reads from NULL+xx, which crashes.


--


so, possible ways to avoid the crash on real hardware:

1. the ARM7 answers the IPC request so quick that, on the ARM9, the response wait returns immediately and doesn't trigger a reschedule
2. the reschedule happens, but another thread with higher priority is ready to run at that time, and runs instead of the 'wrong' thread


so: plans

hook code at 0205EC48, to inspect the thread list, see which thread is the first to be ready to run at that point, output that information somehow

see if it's different on hardware

THREAD LIST: linked list, pointer to list head at 020EC2A0, pointer to current thread at 020EC284

thread entry:
0x40: inited to entrypoint+4, perhaps current thread PC
0x64: status: 1=ready to run
0x68: pointer to next thread
0x70: priority, lower value=higher prio, but the linked list is already sorted to have higher-prio threads first

ARM7 thread entry:
0x48: status
0x4C: pointer to next thread
0x54: priority

ARM7 thread list head pointer at 037FFBDC.

THREAD LIST AT THE AFOREMENTIONED POINT, BEFORE THE RESCHEDULE:


the problematic thread is the one with PRIO=19 (ie #5 here).

RESULT ON HARDWARE:

at that point, the next thread that will be able to run is the one with prio=19, ie. same as on melonDS. so we can rule out hypothesis 2.

which means this is a timing issue of some sort.


FIFO traffic before the crash:


first one is the 'read headphone status' request sent to the ARM7

you can see that other crap is sent in the meantime, and the ARM7 is taking a while to answer the first request



THREAD LIST ON ARM7 before the first RTC command is passed to the RTC thread:


so, what's happening on the ARM7 side:

* the IPC-18 request is received (the one to get the headphone-connected status)
* while it is being dealt with, the IPC-5 request (RTC) is received
* once these two are dealt with, it first runs the RTC thread, because it has priority
* (another IRQ is triggered, which seems spurious)
* then it goes to the sound thread, but at this point it has already received another IPC request from the ARM9, and that takes priority
* etc

so basically the ARM9 is sending its requests too fast

setting kCodeCacheTiming to 9 or more fixes the issue. (or it can be set to 8 if kDataCacheTiming is 8 for example... data plays a role in this, but code is the most important)

____________________
Kuribo64