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 > No ARM7 breakpoint instruction?

#154189 - simonjhall - Sat Apr 12, 2008 7:09 pm

I'm extending my debugger (again) in order for it to work on the ARM7, as well as the ARM9.

However, reading through the instruction set manual for the ARM7TDMI there doesn't seem to be a 'bkpt' instruction, like there is on the ARM9. Does anyone know the preferred way of getting the CPU into abort mode or whatever it takes to get the handler at 0x380FFDC to fire? I know I CAN get the handler to execute, I just want to know how you're meant to be doing it!
_________________
Big thanks to everyone who donated for Quake2

#154197 - Dwedit - Sat Apr 12, 2008 8:03 pm

NO$GBA uses mov r11,r11 into the breakpoint instruction.
If you're not an emulator, then anything goes for triggering a breakpoint.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#154204 - silent_code - Sat Apr 12, 2008 9:48 pm

i am sure simon is *NOT* an emulator! ;^p

#154206 - simonjhall - Sat Apr 12, 2008 9:59 pm

silent_code wrote:
i am sure simon is *NOT* an emulator! ;^p
THAT DOES NOT COMPUTE.
_________________
Big thanks to everyone who donated for Quake2

#154207 - silent_code - Sat Apr 12, 2008 10:06 pm

<OT>what is meaning of words "THAT DOES NOT COMPUTE."? !(understand human information transmission). need: reloading speeeech module. short on memory.... please wait...

FATAL ERROR: Program terminated and returned status -3Λ07.


did you develop a debugger that get's compiled into the rom? like a memory leak debugger or something? i'm quite interested on what ppl are doing in that area. my own (memory) "debugging" code is quite simple, it's really just the usual redefinition of new and delete etc.

... [moved to offtopic]

sorry for being totally offtopic. my head is going insane today! </OT>

ps: i really don't understand your expression, but i'd like to. ;^)


EDIT: thanks! actually, that's funny! :^)
ah, now i remember - the wifi debugger! sorry, that i'm not much of a help.
also, thanks for the response. i was thinking about testing the code with VS, but i hate switching habbits (for obvious reasons, i might add) as much as i hate switching compilers. going away from my long term favorite ide very recently was a pain (although c::b is really cool!) - moving back to VS (used it in the old 6.0 days) so short after that would mean total system shutdown. ;^)
i was hoping i could get some hints that went in another direction. never mind.
i guess i'll have this post moved into a more general (coding) section and try it there.

Last edited by silent_code on Sat Apr 12, 2008 11:26 pm; edited 2 times in total

#154213 - simonjhall - Sat Apr 12, 2008 10:38 pm

Haha!
I'm actually shocked that there's a wikipedia page on this: http://en.wikipedia.org/wiki/Does_not_compute
Quote:
Does not compute, and variations on it, was a phrase often spoken by computers, robots and other artificial intelligences in science fiction works of the 1960s to 1980s. The phrase indicated cognitive dissonance on the part of the device, conventionally leading to its self-destruction.
and
Quote:
It was then popularised in Lost In Space (1965), along with "Affirmative!", "Warning! Warning!" and, of course, "Danger, Will Robinson!"

Anyway with your problem I have no idea. Sounds like an MT problem to me! If you think it's compiler/toolchain related, you could always try recompiling with Visual Studio instead?

Back on-topic :-)
Having an anything-goes way of forcing an abort seems a bit of a crap design - what did the designers of the chip expect people to do when debugging their code? Undefined instructions? Data aborts?
I'm rewriting the DS-side of the wireless debugger I wrote back in '06 to support all the things I never got round to doing and I'm happy-ish with the ARM9 side; I'm just expanding it to support ARM7. Should be a lot harder to do as it's gonna need some IPC just to do printf!

One thing I don't like with the existing thing I've written though is that there doesn't seem to be a good way of capturing the machine state upon an abort. Since the link register and stack pointer are banked (as we're in abort mode) you've got to return to user mode to recapture these. But then once you're in user mode you can't get back into abort mode (to handle the event) without abort-ing again (as user mode is unprivileged).

I really hate ARM assembler.
_________________
Big thanks to everyone who donated for Quake2

#154218 - Dwedit - Sat Apr 12, 2008 11:20 pm

Forget that user mode exists, and go straight to system mode.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#154219 - simonjhall - Sat Apr 12, 2008 11:22 pm

Is that the mode that your average program runs in?
_________________
Big thanks to everyone who donated for Quake2

#154221 - Cydrak - Sat Apr 12, 2008 11:57 pm

FIQ, Aborts, and Undefined all lead to the same BIOS trap and to 0x380FFDC, right?

ARM's manual explicitly calls out Undef as a way to add "extra" instructions (or emulation of missing ones). So if you want a breakpoint, that would seem to be the sanctioned one. How were you doing it? Is there even a way to trigger real aborts on the ARM7 side?

There are two ways around the banking, actually. First is to switch modes--that's what System (0x1F) is for, it's privileged but it shares the User (0x10) bank. Or rather, you could say they're both un-banked.

The other is LDM/STM Rn, {...}^ (no writeback, and no R15). ARM has this to say:
Quote:
... the User bank registers are transferred rather than the register bank corresponding to the current mode. This is useful for saving the user state on process switches. Base write-back should not be used ... [and] ... care must be taken not to read from a banked register during the following cycle ... .

In fact I'm not sure the BIOS (nor devkitARM) even use User mode. Don't they leave you in System anyway? That would make privilege a non-issue.

That's if I understand all this, of course. Still, I love my ARM; the only fun thing about x86 is all that SIMD stuff, if you ask me. :>