Crash when calling __udivsi3 on LPC2103. Bad gcclib?

Development Boards MicroMod
1

I’m recycling my old post since I got that problem fixed by just copying everything to a new project in Eclipse. I have no clue what was wrong. Anyway…

I’m using an Olimex LPC-P2103 and my program is based on the “lpc_p2103_UART” example that appeared in the Eclipse project list after installing the Olimex package. (Apparently using Yagarto toolchain)

I am now having the problem that any division I make is crashing.

I suspect it has to do with the fact that I am linking libgcc ( to get rid of undefined reference to ‘__udivsi3’) but it’s not the right lib.

There are 21 different search hits on “libgcc.a” under “C:\gccfd” where it installed, most of them in a subfolder of “C:\gccfd\yagarto\lib\gcc\arm-elf\4.2.2”

This is the last step before I lose control of the program.

http://img44.imageshack.us/img44/5200/n … rashes.gif

As you can see in the C-source it’s not a division-by-zero, and the next line to be called in the instruction list is the branch to __udivsi3.

Once I do that I lose the debugger and the program enters running state. When I interrupt it I find the program locked in this loop:

void UNDEF_Routine (void) {
	while (1) ;
}

I see this function in crt.s

Reset_Addr:     .word   Reset_Handler		/* defined in this module below  */
Undef_Addr:     .word   UNDEF_Routine		/* defined in main.c  */
SWI_Addr:       .word   SWI_Routine			/* defined in main.c  */
PAbt_Addr:      .word   UNDEF_Routine		/* defined in main.c  */
DAbt_Addr:      .word   UNDEF_Routine		/* defined in main.c  */

I suspect the division causes a “data abort” or something similar and that triggers a jump to the UNDEF_Routine, and I think it’s because I’m linking the wrong library.

What do you think?

I read there is a problem with the LPC2000’s because there’s no floating point unit and the division call in the library won’t work properly. It was possible to build your own version of libgcc though.

There has to be a readily available library that can do this, right?

I am using Windows and wasn’t really planning on installing and building my own toolchain just for this and I am dreading there will be more problems just to get that done.

So, do you think it’s the library that causes the division to crash and is there a libgcc.a that will solve it?

2

Edited my original post to a new problem to not create a new thread. Hope that’s ok.

3

Undef is not a data abort, but an undefined instruction.

Did you pass the -mcpu=arm7tdmi option to both the compiler and linker? If not, the compiler might generate a division instruction, which does not exist in your processor.

4

Thanks for your reply but I think the code is generated ok. I mean the code I get is a branch to udivsi3 in the disassembly. Problem is when I jump there the code is only andeq 0 something. Just zeros. I get that problem both for divisions and for malloc() calls, different libs, different addresses.

I spent a week trying to get it to work but it felt hopeless. So, I downloaded CrossWorks and am now using it on trial. I just might go ahead and buy it. Of course free tools would be nice but if they don’t work they’re worthless.

I can’t believe it should be so hard to get this working and I bet thousands have done this before me and it’s not readily available.

I keep reading about people who build their own toolchains and libraries and all that. Come one! Isn’t it enough that one person does it and then it can be downloaded? It’s silly.

$150 for CrossWorks is silly and desperate too but I am doing this as a hobby and for fun and I don’t want to waste my free time with ****.

I’m not mad at you inventore123, just at the whole way it works (or doesn’t work hehe).

Thanks for trying to help anyway :slight_smile:

5

Look at codesourcery. They provide a GCC compiled and tested.

6

It’s working now. I posted a bit about it here if you are interested in reading:

viewtopic.php?t=13469&start=31

Thanks for caring anyway :slight_smile:

/Peter