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.

Announcements And Comments > devkitARM release 21

#143573 - wintermute - Tue Oct 23, 2007 11:13 pm

As the thread title says - devkitARM release 21 is now available. Full details can be found on the website. http://www.devkitpro.org/
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#143583 - tondopie - Wed Oct 24, 2007 2:13 am

were there any register changes at all?

#143596 - simonjhall - Wed Oct 24, 2007 7:50 am

I guess you don't hear this as much as you should, but thanks for working on this toolchain lark!
_________________
Big thanks to everyone who donated for Quake2

#143598 - kusma - Wed Oct 24, 2007 8:41 am

Brilliant, just brilliant! Now I can finally rely on modern GNU Make features. How safe is it to use gcc 4.1.x BTW? Isn't that the "unstable" versions or do I confuse the version-numbering with the Linux kernel or something?

Edit: And I also love that you've added plain GDB! Now I just have to learn how to use Simon's gdb-stub/server! Oh, and get me one of those wifi-dongles first, I guess...

#143638 - Quirky - Wed Oct 24, 2007 10:49 pm

The good: I can now ditch the patches for RTC that I'd taken from devkitpro's CVS. The new ndstool runs on Ubuntu 7.10. And gdb + desmume can step through code:
Code:

$desmume-cli --arm9gdb=55555 file.nds &
$ arm-eabi-gdb file-arm9.elf
(gdb) target remote localhost:55555
Remote debugging using localhost:55556
0x02000000 in _start ()
(gdb) b main
...


The bad: random lock ups, code that no longer works on desmume 0.7.3, black/white screens of death... are there any caveats for using C++ code? At the minute only about 40% of my svn code works when compiled with r21. Seems like things "explode" when allocating/deallocating new class instances, at least when viewing code via gdb and desmume that is the impression I get. It'd be nice to be able to keep moving with the times and not get stuck on r20 forever. FWIW I compiled all libs (fat, nds, dswifi, etc) with r21 too.

The only changes to my code I needed for the new libnds were changing some "unsigned int &" to "unsigned long int &" and including background.h and sprite.h as well as video.h.

#143644 - josath - Thu Oct 25, 2007 12:13 am

Quirky wrote:
The bad: random lock ups, code that no longer works on desmume 0.7.3, black/white screens of death...


Have you tested on a real DS? Likely the new libnds has added a few things that the emulators do not support yet.

#143683 - Quirky - Thu Oct 25, 2007 8:16 am

josath wrote:
Quirky wrote:
The bad: random lock ups, code that no longer works on desmume 0.7.3, black/white screens of death...


Have you tested on a real DS? Likely the new libnds has added a few things that the emulators do not support yet.


I have, yes. The random lock ups and white screens are on hardware. The black screens are on the emulator. I usually don't bother using emulators as they are just so unlike the real thing that it's pointless. They can be handy for checking silly mistakes and to save on flashcard shuffles, of course.

I've got my main bunjalloo.nds file that uses every library under the sun and several smaller test cases for certain aspects of the code - the GUI lib and image viewing for example. The main program goes nowhere with r21 and has never worked on emulators anyway. I'll have to add debugging-to-file stuff probably to narrow down the problem there. The test case (images.nds) for showing images works apparently fine on hardware, does nothing on desmume. It reads in 3 image files from the flash and shows them on screen in mode 5. Nothing too fancy. Seems that the problem here is with libfat on desmume, since commenting out the image loading causes the program to do *something* on the emu, even if it is just to show a red background. The gui test case, also mode 5, works mostly OK on hardware but locks up after a while, I've not spotted a pattern to the lock ups yet. It smells of IRQ problems to me, but could be due to pretty much anything. This case causes desmume to segfault when new-ing an instance of a fairly big class.

All this code worked perfectly (i.e. as intented) with r20 and it also runs on the PC, factoring out the hardware differences into a separate library. It compiles without warnings, does nothing too strange with the NDS hardware, etc, I've valgrinded the PC version to check for memory corruption in the business logic, so assuming that there are no problems in the hardware abstraction library (it is pretty stable and only required minor changes for the new libnds) I'm a bit stumped.

Things that I'm suspecting to have changed that could upset my code are stack size changes, changes to the interrupts (I only use VBLANK in the cases above) or anything else any one can suggest! This is mostly speculation at the moment and any hints on debugging this would be welcome.

#143685 - wintermute - Thu Oct 25, 2007 9:07 am

Does using the libnds exception handler help any?

The only change to the IRQ code was that saving & restoring lr_irq to get nesting working properly. This will use an extra 4 bytes on the stack for an interrupt so I'd expect you would have seen problems before if you were that close to overrunning.

I really wouldn't expect such major problems from a minor upgrade to gcc - we went from 4.1.1 to 4.1.2 but it's certainly a possibility. You could try dropping the optimisation level to see if that helps.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#143734 - Quirky - Thu Oct 25, 2007 6:54 pm

wintermute wrote:
Does using the libnds exception handler help any?

The only change to the IRQ code was that saving & restoring lr_irq to get nesting working properly. This will use an extra 4 bytes on the stack for an interrupt so I'd expect you would have seen problems before if you were that close to overrunning.

I really wouldn't expect such major problems from a minor upgrade to gcc - we went from 4.1.1 to 4.1.2 but it's certainly a possibility. You could try dropping the optimisation level to see if that helps.


I wasn't expecting it either, I've been using DKA since it started and this is the first upgrade that's had me stuck.

I suspect there's some niggling thing that is escaping me - I assume it is my own code that has the problem or everyone would be in the same boat.

The good news is that the exception handler triggers on both my mini-test cases! This is certainly a bonus. The full blown bunjalloo program doesn't trigger it, but I'm sure that I'll get to the bottom of the problem sooner or later.

Code:

Guru Meditation Error!
data abort!
pc:02019338 addr:03000000

Code:

Guru Meditation Error!
data abort!
pc:0200D3C4 addr:03000000


The addr: in both cases is 03000000, which means something is writing or reading there, right? I'll see if I can get gdb to output the code for those pc values too. Thanks for the tip.

EDIT: I've found one of my stupid mistakes! I was writing to a dereferenced VRAM_CR. I have no idea how this has worked before. It is quite literally crap code that can't do what I intended at all. Not everything works, but a _lot_ more does now. I shall keep searching for more of my own incompetence...

#143775 - wintermute - Thu Oct 25, 2007 10:35 pm

Interesting address, you don't have some rogue GBA code in there somewhere do you?

Also, just in case you missed the notes in the exception example

Code:

// The default exception handler displays the exception type - data abort or undefined instruction
// you can relate the exception to your code using arm-eabi-addr2line -e <elf file> <address>
// assuming you built with debug info this will display a source file and a line number
// The address of the instruction is shown as pc, beside the address which faulted
// the rest of the screen is a dump of the registers.

_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#143786 - Quirky - Thu Oct 25, 2007 11:43 pm

I was using gdb and "b *0x0nnnnn", but that's a handy trick.

No GBA stuff. I'm ashamed to show the bug that was causing most crashing really, but it was along the lines of doing this:
Code:

unsigned int * vram = (unsigned int*)VRAM_CR;
*vram = foo;


Casting a *(vuint32*) i.e. a value, to a int* , which is a pointer. How that worked before is anyone's guess. I must have been drunk when I wrote it.

Another problem was being caused by the order of inits of static values, despite using the singleton idiom to mitigate it. Very odd. Here was the change:
Code:

-static const int MAX_SIZE(nds::Canvas::instance().width()-7);
+static const int MAX_SIZE(SCREEN_WIDTH-7);

In the Canvas constructor it sets up the screens (writes to registers and what not). No idea why it suddenly stopped working, just showed a white screen. Had a heck of a time tracking it down. Other errors were just coincidences - null pointers that I had not come across before, for example. That'll teach me for using c++! :-)

Everything is now working as well as with r20, thank goodness, with the added bonuses of being up to date and getting rid of some poor code. Thanks again for the help! Looking forward to r22 now ;-)

#144247 - Lick - Tue Oct 30, 2007 8:08 pm

I was wondering if libfat already uses argv[0] to find the current working directory? If it doesn't should it?
_________________
http://licklick.wordpress.com

#144263 - kusma - Tue Oct 30, 2007 11:51 pm

Lick: no. An application should be able to be launched from a different folder than where the executable reside.