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 > Custom SWI handler troubles

#172241 - fincs - Tue Jan 26, 2010 9:43 pm

Hi,
I hate that my first post is something as obscure as this, but I'm having trouble trying to install a custom SWI handler on the DS. I'm using devkitARM r27 and libnds 1.4.0.
The problem is that the custom handler never gets executed. This is how I install it:
Code:
   SystemVectors.swi = (u32) __SWIHandler;
   setVectorBase(0); // clear the high vector bit in the CP15 control register

I then used the no$gba debugger (with the appropiate BIOS ROMs) to see what was wrong with my program. The SWI instruction jumps to 0xFFFF0008 (BIOS) instead of 0x00000008 (libnds vectors) although I cleared the V bit in the CP15. Real hardware (DSi) exposes the same problem, whilst other emulators run my code fine. I've tried everything: hacking the linker script, ds_arm9_crt0.s, vectorbase.s, mpusetup.s, searching this forum, re-reading gbatek, reading the official ARM documentation, nothing. I've been struggling my head for like a week for something that might just be a one-byte problem.

PD: vectorbase.s is wrong although it doesn't affect program execution (FIQs are never fired), here's a fix:
Code:
(..snip..)
   .global      SystemVectors
   
   ldr r15,vec_reset
   ldr r15,vec_undefined
   ldr r15,vec_swi
   ldr r15,vec_prefetch_abort
   ldr r15,vec_data_abort
   .word 0 @ <<-- added line
   ldr r15,vec_irq
   ldr r15,vec_fiq

SystemVectors:
vec_reset:
   .word   0xFFFF0000
vec_undefined:
   .word   0xFFFF0004
vec_swi:
   .word   0xFFFF0008
vec_prefetch_abort:
   .word   0xFFFF000C
vec_data_abort:
   .word   0xFFFF0010
vec_irq:
   .word   0xFFFF0018 @ <<--changed address
vec_fiq:
   .word   0xFFFF001C @ <<--changed address
(..snip..)

#172242 - Dwedit - Tue Jan 26, 2010 10:29 pm

Maybe NO$GBA has bugs here? The ARM reference does indeed say that PC should become 00000008.
I know that the debugger seems to ignore the current memory mapping and protection settings when displaying memory.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#172243 - fincs - Tue Jan 26, 2010 10:33 pm

Real hardware also suffers from this problem.
There's a PU section which covers the 00000000 vectors, so no PU problem.
The code in this thread appears to work in real hardware and use the same trick...

#172263 - fincs - Wed Jan 27, 2010 10:35 pm

Ok, I've decided to include a test project which can be downloaded from here.

#172770 - wintermute - Tue Mar 02, 2010 1:19 pm

Works for me on hardware, both DS & DSi, libnds 1.4.1 & devkitARM r28.

Good catch on the vector stuff, flaming ARM docs don't exactly make that obvious :/ I've just committed that to svn, will be part of libnds 1.4.2, thanks. If you do catch anything else could you submit a patch to the SF patch tracker, things get noticed and fixed much quicker that way.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#172774 - fincs - Tue Mar 02, 2010 3:48 pm

Yeah, I somehow managed to run the wrong version of my code. It now works.
I can confirm no$gba doesn't do custom exception vectors.
Anyway, thanks for your wonderful toolchains and libraries.

#172791 - Exophase - Wed Mar 03, 2010 4:50 pm

fincs wrote:
Yeah, I somehow managed to run the wrong version of my code. It now works.
I can confirm no$gba doesn't do custom exception vectors.
Anyway, thanks for your wonderful toolchains and libraries.


I'm just curious, but what was the problem? Surprising bit about No$..

#172796 - fincs - Wed Mar 03, 2010 9:58 pm

no$gba ignores the V bit in the cp15 control register (that means, it forces 0xFFFF0000 (BIOS) as the exception vector base address).
About the "wrong version of my code", I recall it had some sort of issue with the stack, I can't really remember.