[coldfire-gnu-discuss] Unexpected zero divide trap whilst running fib.c demo app

[Nathan Sidwell]

Christof Frey wrote:
> Hi all,
>  
> I followed the getting started guide for 4.2-47 chapter 3.2 and 
> implemented the fib.c accordingly to validate correct installation of 
> the whole toolchain.
> The command line I used is:
> m68k-elf-gcc -mcpu=5235 -Tm5235evb-ram-hosted.ld fib.c -o fib -g
> When trying to debug the application I get the following output in GDB:
>  
> (gdb) target remote | m68k-elf-sprite pe://ParallelPortCable m5235evb
> Remote debugging using | m68k-elf-sprite pe://ParallelPortCable m5235evb
> m68k-elf-sprite: Opening P&E ParallelPortCable port 1 (LPT1 : Parallel 
> Port 1 (A
> ddress $0378))
> m68k-elf-sprite: Target reset
> 0x00000000 in __cs3_interrupt_vector_coldfire ()
> (gdb) load
> Loading section .text, size 0xe58 lma 0x0
> Loading section .data, size 0x400 lma 0xe58
> Start address 0x9ac, load size 4696
> Transfer rate: 2 KB/sec, 2348 bytes/write.
> (gdb) break main
> Breakpoint 1 at 0x60c: file fib.c, line 16.
> (gdb) continue
> Continuing.
>  
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00000d32 in __cs3_isr_divide_by_zero ()
> (gdb)
>  
> I must admit that I had to change line 55 in file m5235evb.xml in order 
> to get the initialization working:
> original:
>     <write-memory address="0x80000048" value="0x2308"/>
> changed to:
>     <write-memory address="0x40000048" value="0x2308"/>
> since 0x800000xx is not in the address space. I guess this was a bug (?)

Yes, thanks, that was a typo in the configuration file.

> A wonder why the application gets a zero divide trap ? (I think it is 
> caused by write() function)

Are you able to generate a stack trace and determine the location of the trap?

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery