From Christof.Frey at varian.com Tue Jul 1 13:00:36 2008 From: Christof.Frey at varian.com (Christof Frey) Date: Tue, 1 Jul 2008 06:00:36 -0700 Subject: debug library -ldbug on 4.2.-125 Message-ID: Hi, we are using a GCC project that compiles & runs with a alternate toolchain than CodeSourcery Lite (older versions of GCC and GDB) When using Lite Edition 4.2.-125 we are getting a linker error: cannot find -ldbug I noticed that this library is not provided in the Lite distribution and is related to GDB. When I remove it in the linker parameter file it links w/o any unresolved externals. So is the conclusion correct that this lib is not needed at all ? (I've tried with different -g options and the result is the same) thanks, Christof -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at codesourcery.com Tue Jul 1 19:05:30 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Tue, 01 Jul 2008 12:05:30 -0700 Subject: [coldfire-gnu-discuss] debug library -ldbug on 4.2.-125 In-Reply-To: References: Message-ID: <486A7FFA.7090307@codesourcery.com> Christof Frey wrote: > we are using a GCC project that compiles & runs with a alternate > toolchain than CodeSourcery Lite (older versions of GCC and GDB) > When using Lite Edition 4.2.-125 we are getting a linker error: > > cannot find -ldbug I know there is a ColdFire/Freescale boot monitor called "dBug". It might be that this library is related to that, and might have been a way to get the program started or to handle I/O over the serial port. But, that's just a guess. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From Corrin.Meyer at dornerworks.com Tue Jul 1 23:05:49 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Tue, 1 Jul 2008 19:05:49 -0400 Subject: ColdFire Interrupts Message-ID: According to the ColdFire datasheets, on entering of an ISR, the only first instruction is guaranteed to run with interrupts disabled, and therefore should modify the status register. Since on interrupt, the processor creates an exception stack frame in which the status register (SR) is stored, the first instruction in an ISR should load an immediate value into SR. Either that, or use the 'STRLDSR' instruction. However, even with a function marked with "__attribute__((interrupt))" GCC doesn't seem to generate these instructions. I also noticed that none of the CS3 default interrupts do this. Is this the intended functionality? Am I correct in assuming that the only way to write truly correct ISRs is to do so in assembly (or at least use assembly as a wrapper before calling C code)? Corrin J. Meyer DornerWorks, Ltd. Embedded Systems Engineering T: 616.389.8336 F: 616.245.8372 E: corrin.meyer at dornerworks.com 3445 Lake Eastbrook Blvd. SE Grand Rapids, MI 49546 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at codesourcery.com Wed Jul 2 07:39:50 2008 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 02 Jul 2008 08:39:50 +0100 Subject: [coldfire-gnu-discuss] ColdFire Interrupts In-Reply-To: References: Message-ID: <486B30C6.7030808@codesourcery.com> Corrin Meyer wrote: > According to the ColdFire datasheets, on entering of an ISR, the only > first instruction is guaranteed to run with interrupts disabled, and > therefore should modify the status register. Since on interrupt, the > processor creates an exception stack frame in which the status register > (SR) is stored, the first instruction in an ISR should load an immediate > value into SR. Either that, or use the ?STRLDSR? instruction. However, > even with a function marked with ?__attribute__((interrupt))? GCC > doesn?t seem to generate these instructions. I also noticed that none > of the CS3 default interrupts do this. > Is this the intended functionality? Am I correct in assuming that the > only way to write truly correct ISRs is to do so in assembly (or at > least use assembly as a wrapper before calling C code)? The SR interrupt mask is automatically set to the level of the current interrupt, so you only need the functionality you ask for when you want to disable all interrupts from the very start of the interrupt routine. You could of course disable all interrupts later within the routine, but that does mean there is a part of the routine that is preemptable (but not necessarily reentrant) I have filed an internal enhancement request. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery From Corrin.Meyer at dornerworks.com Wed Jul 2 13:11:45 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Wed, 2 Jul 2008 09:11:45 -0400 Subject: [coldfire-gnu-discuss] ColdFire Interrupts In-Reply-To: <486B30C6.7030808@codesourcery.com> References: <486B30C6.7030808@codesourcery.com> Message-ID: >Corrin Meyer wrote: >> According to the ColdFire datasheets, on entering of an ISR, the only >> first instruction is guaranteed to run with interrupts disabled, and >> therefore should modify the status register. Since on interrupt, the >> processor creates an exception stack frame in which the status register >> (SR) is stored, the first instruction in an ISR should load an immediate >> value into SR. Either that, or use the 'STRLDSR' instruction. However, >> even with a function marked with "__attribute__((interrupt))" GCC >> doesn't seem to generate these instructions. I also noticed that none >> of the CS3 default interrupts do this. > >> Is this the intended functionality? Am I correct in assuming that the >> only way to write truly correct ISRs is to do so in assembly (or at >> least use assembly as a wrapper before calling C code)? > >The SR interrupt mask is automatically set to the level of the current >interrupt, so you only need the functionality you ask for when you want to >disable all interrupts from the very start of the interrupt routine. You >could >of course disable all interrupts later within the routine, but that does >mean >there is a part of the routine that is preemptable (but not necessarily >reentrant) > >I have filed an internal enhancement request. > >nathan Thank you for filing an enhancement request. My other question is in regards to the "__attribute__((interrupt))". Should I be using "interrupt" or "interrupt_handler". I saw that there had been some discussion on which name to use, but I never found a resolution. Corrin From nathan at codesourcery.com Wed Jul 2 14:43:23 2008 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 02 Jul 2008 15:43:23 +0100 Subject: [coldfire-gnu-discuss] ColdFire Interrupts In-Reply-To: References: <486B30C6.7030808@codesourcery.com> Message-ID: <486B940B.6060903@codesourcery.com> Corrin Meyer wrote: > Thank you for filing an enhancement request. My other question is in > regards to the "__attribute__((interrupt))". Should I be using > "interrupt" or "interrupt_handler". I saw that there had been some > discussion on which name to use, but I never found a resolution. They are equivalent. Historically some gcc targets used one and some used the other, which is confusing. So gcc was changed to accept both. The canonical one is 'interrupt'. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery From Christof.Frey at varian.com Thu Jul 3 06:56:00 2008 From: Christof.Frey at varian.com (Christof Frey) Date: Wed, 2 Jul 2008 23:56:00 -0700 Subject: zero divide trap when running Debug Sprite Example "Fibo" Message-ID: Hi, when running the example on page 51 of the Getting Started guide on a BCC5235 Coldfire board I am getting a zero divide trap. Is this related to the library used ? (note: the board has still the Freescale dBug monitor application in flash - is there an interference ?) Compile command used is: m68k-elf-gcc -mcpu=5235 -Tm5235evb-ram-hosted.ld fib.c -o fib -g C:\Projects\fibo>m68k-elf-gdb fib GNU gdb (Sourcery G++ Lite 4.2-125) 6.7.50.20080107-cvs Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-mingw32 --target=m68k-elf". For bug reporting instructions, please see: . .. (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 0xdf4 lma 0x0 Loading section .eh_frame, size 0x4 lma 0xdf4 Loading section .rodata, size 0x68 lma 0xdf8 Loading section .data, size 0x400 lma 0xe60 Start address 0xcc4, load size 4704 Transfer rate: 4 KB/sec, 1176 bytes/write. (gdb) break main Breakpoint 1 at 0x608: file fib.c, line 16. (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000d3a in __cs3_isr_divide_by_zero () (gdb) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at codesourcery.com Thu Jul 3 19:06:35 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Thu, 03 Jul 2008 12:06:35 -0700 Subject: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo" In-Reply-To: References: Message-ID: <486D233B.4070502@codesourcery.com> Christof Frey wrote: > when running the example on page 51 of the Getting Started guide on a > BCC5235 Coldfire board I am getting a zero divide trap. I suspect that you're actually getting some other trap; the default trap handlers are all mapped at the same address, so the debugger picks a name somewhat at random. > Is this related to the library used ? (note: the board has still the > Freescale dBug monitor application in flash - is there an interference ?) > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00000d3a in __cs3_isr_divide_by_zero () > (gdb) Nathan, do you have ideas about how to figure out exactly what's going wrong here? -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From nathan at codesourcery.com Fri Jul 4 06:44:12 2008 From: nathan at codesourcery.com (Nathan Sidwell) Date: Fri, 04 Jul 2008 07:44:12 +0100 Subject: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo" In-Reply-To: <486D233B.4070502@codesourcery.com> References: <486D233B.4070502@codesourcery.com> Message-ID: <486DC6BC.4070709@codesourcery.com> Mark Mitchell wrote: > Christof Frey wrote: > >> when running the example on page 51 of the Getting Started guide on a >> BCC5235 Coldfire board I am getting a zero divide trap. > > I suspect that you're actually getting some other trap; the default trap > handlers are all mapped at the same address, so the debugger picks a > name somewhat at random. > >> Is this related to the library used ? (note: the board has still the >> Freescale dBug monitor application in flash - is there an interference ?) > >> Program received signal SIGTRAP, Trace/breakpoint trap. >> 0x00000d3a in __cs3_isr_divide_by_zero () >> (gdb) > > Nathan, do you have ideas about how to figure out exactly what's going > wrong here? you have to examine the call stack. in gdb do (something like) x/8xw $sp you should be able to see the exception information there and the exception address. consult the CFPRM for a description of the exception word. It is unfortunate that gcc doesn't emit sufficient debug information on interrupt functions for this to just look like parameters (we have an internal enhancement issue for that) nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery From rwalsh at lockinspection.co.uk Fri Jul 4 08:03:20 2008 From: rwalsh at lockinspection.co.uk (Rick Walsh) Date: Fri, 4 Jul 2008 09:03:20 +0100 Subject: coldfire 4.2.153 tool chain uClinux Kernel build issue Message-ID: <00b301c8ddac$6c748c70$455da550$@co.uk> Hi I am very green to uClinux building and I am having trouble with the code sourcery toochain. When I try to build the uClinux kernel I get the following error with the zlib library:- which: no m68k-uclinux-20060615-gcc in (/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/rick/bi n:/home/rick/CodeSourcery/Sourcery_G++_Lite/bin:/home/rick/Programming/uCLin ux/uClinux-dist/tools) make[2]: Entering directory `/home/rick/Programming/uCLinux/uClinux-dist/lib' Making symlinks in lib/ make[2]: Leaving directory `/home/rick/Programming/uCLinux/uClinux-dist/lib' [ -z "zlib" ] ||\ make -j1 zlib || exit $? which: no m68k-uclinux-20060615-gcc in (/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/rick/bi n:/home/rick/CodeSourcery/Sourcery_G++_Lite/bin:/home/rick/Programming/uCLin ux/uClinux-dist/tools) make[2]: Entering directory `/home/rick/Programming/uCLinux/uClinux-dist/lib' [ ! -d "zlib" ] || ( touch zlib/.sgbuilt_lib && make -j1 -C zlib ) || exit $? make[3]: Entering directory `/home/rick/Programming/uCLinux/uClinux-dist/lib/zlib' ucfront-gcc m68k-uclinux-gcc -m5307 -DCONFIG_COLDFIRE -O2 -g -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DEMBED -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -fPIC -c -o crc32.o crc32.c In file included from crc32.c:36: /home/rick/Programming/uCLinux/uClinux-dist/uClibc/include/limits.h:124:26: error: limits.h: No such file or directory make[3]: *** [crc32.o] Error 1 make[3]: Leaving directory `/home/rick/Programming/uCLinux/uClinux-dist/lib/zlib' make[2]: *** [zlib] Error 2 make[2]: Leaving directory `/home/rick/Programming/uCLinux/uClinux-dist/lib' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/rick/Programming/uCLinux/uClinux-dist/lib' make: *** [subdirs] Error 1 The distro is uclinux-distr-test-20080627 and I have fully built the kernel with a different tool chain on a separate host machine and had it running boa on a M5329EVB target, with this other tool chain I tried to build a simple hello world which did not run. I built the same simple hello world code with code sourcery tool chain and it worked. This is why i want to build the kernel with this tool chain. I have parsed through to the file and it does exist but it is an include of itself where the problem is:- ____________________________________________________________________________ _____________ . . . /* Get the compiler?s limits.h, which defines almost all the ISO constants. We put this #include_next outside the double inclusion check because It should be possible to include this file more than once and still get The definitions from gcc?s header. */ #if defined __GNUC__ && !defined _GCC_LIMITS_H_ /* ?_GCC_LIMITS_H_? is what GCC?s file defines. */ # include_next . . . ____________________________________________________________________________ _____________ >From the comments it looks like a fudge which may have been corrected in the code sourcery tool chain, if this was the case the world and his wife would be complaining and I have searched the web and found nothing on the subject. Could someone please direct me to my simple mistake that I have missed. Regards Rick No virus found in this outgoing message. Checked by AVG. Version: 7.5.526 / Virus Database: 270.4.4/1532 - Release Date: 03/07/2008 08:32 -------------- next part -------------- An HTML attachment was scrubbed... URL: From braun at stzedn.de Fri Jul 4 14:06:39 2008 From: braun at stzedn.de (Nathan Braun) Date: Fri, 04 Jul 2008 16:06:39 +0200 Subject: Overriding Interrupt vectors Message-ID: <486E2E6F.3080406@stzedn.de> Hello, while trying to override the default interrupt vectors such as __cs3_isr_access_error() as seen in the getting started guide, I get always a "multiple definition" linker error, caused by linking the library "m5208\libcs3coldfire.a". Interestingly this does not happen, when overriding e.g. __cs3_isr_fp_branch_unordered(). Is there a way to override these interrupts or should I just define the vector table myself? I am working with -mcpu=52235 and the Lite 4.2-47. Thanks for any help. Nathan From nathan at codesourcery.com Fri Jul 4 14:21:35 2008 From: nathan at codesourcery.com (Nathan Sidwell) Date: Fri, 04 Jul 2008 15:21:35 +0100 Subject: [coldfire-gnu-discuss] Overriding Interrupt vectors In-Reply-To: <486E2E6F.3080406@stzedn.de> References: <486E2E6F.3080406@stzedn.de> Message-ID: <486E31EF.7060304@codesourcery.com> Nathan Braun wrote: > Hello, > > while trying to override the default interrupt vectors such as > __cs3_isr_access_error() as seen in the getting started guide, I get > always a "multiple definition" linker error, caused by linking the > library "m5208\libcs3coldfire.a". Interestingly this does not happen, > when overriding e.g. __cs3_isr_fp_branch_unordered(). > > Is there a way to override these interrupts or should I just define the > vector table myself? What is the command you are using to link with? nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery From mark at codesourcery.com Sun Jul 6 18:05:43 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Sun, 06 Jul 2008 11:05:43 -0700 Subject: [coldfire-gnu-discuss] coldfire 4.2.153 tool chain uClinux Kernel build issue In-Reply-To: <00b301c8ddac$6c748c70$455da550$@co.uk> References: <00b301c8ddac$6c748c70$455da550$@co.uk> Message-ID: <48710977.9070500@codesourcery.com> Rick Walsh wrote: > ucfront-gcc m68k-uclinux-gcc -m5307 -DCONFIG_COLDFIRE -O2 -g > -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DEMBED > -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -fPIC -c -o > crc32.o crc32.c The header is provided with GCC. My guess would be that ucfront-gcc is passing in some odd options that are causing the compiler not to search the header files supplied with the compiler itself. You might want to add "-v" to that command-line and see if you can work out what it's doing. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From Christof.Frey at varian.com Mon Jul 7 16:59:34 2008 From: Christof.Frey at varian.com (Christof Frey) Date: Mon, 7 Jul 2008 09:59:34 -0700 Subject: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo" In-Reply-To: <486DC6BC.4070709@codesourcery.com> References: <486D233B.4070502@codesourcery.com> <486DC6BC.4070709@codesourcery.com> Message-ID: According to CFPRM the stack frame is two long word: SSP -> 32 Bit control information SSP + 0x4 -> program counter So is the SSP pointing to 0xffffb4 below the frame of interest ? Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000d3a in __cs3_isr_divide_by_zero () (gdb) x/8xw $sp 0xffffb4: 0x000009a0 0x000008de 0x00000000 0x00ffffcc 0xffffc4: 0x00000e20 0x00ffffe0 0x00ffffe0 0xfffffffe (gdb) x $sp 0xffffb4: 0x000009a0 (gdb) -----Original Message----- From: Nathan Sidwell [mailto:nathan at codesourcery.com] Sent: Friday, July 04, 2008 8:44 AM To: Mark Mitchell Cc: Christof Frey; coldfire-gnu-discuss at codesourcery.com Subject: Re: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo" Mark Mitchell wrote: > Christof Frey wrote: > >> when running the example on page 51 of the Getting Started guide on a >> BCC5235 Coldfire board I am getting a zero divide trap. > > I suspect that you're actually getting some other trap; the default > trap handlers are all mapped at the same address, so the debugger > picks a name somewhat at random. > >> Is this related to the library used ? (note: the board has still the >> Freescale dBug monitor application in flash - is there an >> interference ?) > >> Program received signal SIGTRAP, Trace/breakpoint trap. >> 0x00000d3a in __cs3_isr_divide_by_zero () >> (gdb) > > Nathan, do you have ideas about how to figure out exactly what's going > wrong here? you have to examine the call stack. in gdb do (something like) x/8xw $sp you should be able to see the exception information there and the exception address. consult the CFPRM for a description of the exception word. It is unfortunate that gcc doesn't emit sufficient debug information on interrupt functions for this to just look like parameters (we have an internal enhancement issue for that) nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery From nathan at codesourcery.com Tue Jul 8 12:27:45 2008 From: nathan at codesourcery.com (Nathan Sidwell) Date: Tue, 08 Jul 2008 13:27:45 +0100 Subject: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo" In-Reply-To: References: <486D233B.4070502@codesourcery.com> <486DC6BC.4070709@codesourcery.com> Message-ID: <48735D41.6060408@codesourcery.com> Christof Frey wrote: > According to CFPRM the stack frame is two long word: > SSP -> 32 Bit control information > SSP + 0x4 -> program counter > > So is the SSP pointing to 0xffffb4 below the frame of interest ? > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00000d3a in __cs3_isr_divide_by_zero () > (gdb) x/8xw $sp > 0xffffb4: 0x000009a0 0x000008de 0x00000000 0x00ffffcc > 0xffffc4: 0x00000e20 0x00ffffe0 0x00ffffe0 0xfffffffe This is an odd stack frame, as there appears to be no sign of the control information. The control information contains the original PSW and the exception information. I'm wondering if you did arrive here via an exception. The 0x9a0 and 0x8de look like they might be code addresses -- what is at those locations? nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery From Christof.Frey at varian.com Tue Jul 8 15:04:39 2008 From: Christof.Frey at varian.com (Christof Frey) Date: Tue, 8 Jul 2008 08:04:39 -0700 Subject: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo" In-Reply-To: <48735D41.6060408@codesourcery.com> References: <486D233B.4070502@codesourcery.com> <486DC6BC.4070709@codesourcery.com> <48735D41.6060408@codesourcery.com> Message-ID: Well, don't know whether the pgm arrived via an exception / trap there or GDB is lying. Stackframe looked odd to me as well (thus the stupid question where it starts...) Code addresses: .text 0x000008dc 0x16 c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3hosted.a(hosted-_exit.o) 0x000008dc _exit *fill* 0x000008f2 0x2 00 .text 0x000008f4 0x4c c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3hosted.a(hosted-write.o) 0x000008f4 write .text 0x00000940 0x2b2 c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3hosted.a(hosted-gdb.o) 0x00000940 __cs3_hosted_to_gdb_mode_t 0x00000a2a __cs3_hosted_from_gdb_stat 0x00000a04 __cs3_hosted_to_gdb_lseek_flags 0x00000a86 __cs3_hosted_from_gdb_timeval 0x000009be __cs3_hosted_to_gdb_open_flags Command line degugger: .. (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 0xdf4 lma 0x0 Loading section .eh_frame, size 0x4 lma 0xdf4 Loading section .rodata, size 0x68 lma 0xdf8 Loading section .data, size 0x400 lma 0xe60 Start address 0xcc4, load size 4704 Transfer rate: 2 KB/sec, 1176 bytes/write. (gdb) break main Breakpoint 1 at 0x608: file fib.c, line 16. (gdb) continue Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000d3a in __cs3_isr_divide_by_zero () (gdb) x/8xw $sp 0xffffb4: 0x000009a0 0x000008de 0x00000000 0x00ffffcc 0xffffc4: 0x00000e20 0x00ffffe0 0x00ffffe0 0xfffffffe (gdb) Code: (per example) #include // this program uses the debugger for write() function static int Fib (unsigned n, unsigned a, unsigned b) { unsigned count; for (count = 0; count != b; count++) { write (1, ".", 1); } write (1, "\n", 1); if (n) { Fib (n-1, b, a + b); } } int main () { write (1, "Fibonacci\n", 10); Fib (9, 0, 1); return (0); } -----Original Message----- From: Nathan Sidwell [mailto:nathan at codesourcery.com] Sent: Tuesday, July 08, 2008 2:28 PM To: Christof Frey Cc: Mark Mitchell; coldfire-gnu-discuss at codesourcery.com Subject: Re: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo" Christof Frey wrote: > According to CFPRM the stack frame is two long word: > SSP -> 32 Bit control information > SSP + 0x4 -> program counter > > So is the SSP pointing to 0xffffb4 below the frame of interest ? > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00000d3a in __cs3_isr_divide_by_zero () > (gdb) x/8xw $sp > 0xffffb4: 0x000009a0 0x000008de 0x00000000 0x00ffffcc > 0xffffc4: 0x00000e20 0x00ffffe0 0x00ffffe0 0xfffffffe This is an odd stack frame, as there appears to be no sign of the control information. The control information contains the original PSW and the exception information. I'm wondering if you did arrive here via an exception. The 0x9a0 and 0x8de look like they might be code addresses -- what is at those locations? nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery From Corrin.Meyer at dornerworks.com Thu Jul 10 22:09:16 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Thu, 10 Jul 2008 18:09:16 -0400 Subject: Override printf Message-ID: What is the correct way to provide my own implementation of 'printf'? I am trying to use my own 'printf' which is stripped down and to avoid linking in Newlib in its entirety. I am trying to use some combination of '-nodefaultlibs', '-nostdlib', and/or '-nostartfiles' to tell the linker not to link in Newlib, however, I keep getting the following warnings. c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3 unhosted.a(unhosted-close.o): warning: IO function 'close' used c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3 unhosted.a(unhosted-fstat.o): warning: IO function 'fstat' used c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3 unhosted.a(unhosted-isatty.o): warning: IO function 'isatty' used c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3 unhosted.a(unhosted-lseek.o): warning: IO function 'lseek' used c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3 unhosted.a(unhosted-read.o): warning: IO function 'read' used c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3 unhosted.a(unhosted-write.o): warning: IO function 'write' used It looks like this is part of the CS3 library so I am guessing that Newlib is getting linked in which then makes calls to the functions above and that CS3 is complaining that they don't exist since I haven't provided them for my hardware. Is this correct? How can I get rid of these warnings? If Newlib is being linked in (which I think it is because my final binary is MUCH bigger than before), how do I get it not to link in and instead use my provided printf? Corrin J. Meyer DornerWorks, Ltd. Embedded Systems Engineering T: 616.389.8336 F: 616.245.8372 E: corrin.meyer at dornerworks.com 3445 Lake Eastbrook Blvd. SE Grand Rapids, MI 49546 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at codesourcery.com Fri Jul 11 07:08:18 2008 From: nathan at codesourcery.com (Nathan Sidwell) Date: Fri, 11 Jul 2008 08:08:18 +0100 Subject: [coldfire-gnu-discuss] Override printf In-Reply-To: References: Message-ID: <487706E2.6040202@codesourcery.com> Corrin Meyer wrote: > What is the correct way to provide my own implementation of ?printf?? > > > > I am trying to use my own ?printf? which is stripped down and to avoid > linking in Newlib in its entirety. I am trying to use some combination > of ?-nodefaultlibs?, ?-nostdlib?, and/or ?-nostartfiles? to tell the > linker not to link in Newlib, however, I keep getting the following > warnings. > > It looks like this is part of the CS3 library so I am guessing that > Newlib is getting linked in which then makes calls to the functions > above and that CS3 is complaining that they don?t exist since I haven?t > provided them for my hardware. Is this correct? How can I get rid of > these warnings? If Newlib is being linked in (which I think it is > because my final binary is MUCH bigger than before), how do I get it not > to link in and instead use my provided printf? You are most likely correct that newlib is still being linked in. You can track this down by using the -v option on your final link, to see how the linker is being invoked. The -Wl,-Map,a.map option may also be useful to determine what is pulling in newlib. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery From jean-christophe.barriol at rsautomation.com Fri Jul 11 14:12:54 2008 From: jean-christophe.barriol at rsautomation.com (Jean Christophe BARRIOL) Date: Fri, 11 Jul 2008 16:12:54 +0200 Subject: real time problem with MCF5485 Message-ID: <006001c8e360$36974cf0$82bebfc0@RSAI.local> Hi, We notice a strange problem with Coldfire MCF5485 (and also with MCF5234): The treatment time (the time for the CPU to run the code) of an ISR, which has the highest priority level, varies according to the code that run on others ISR or Main task. !!!! We verified that the Real time ISR (the one with the highest priority) is never preempt ! We also use MCF5407. There's no problem with it. Any idea ? ******************************* Jean Christophe BARRIOL ******************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at codesourcery.com Fri Jul 11 14:25:04 2008 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Fri, 11 Jul 2008 10:25:04 -0400 Subject: [coldfire-gnu-discuss] Override printf In-Reply-To: <487706E2.6040202@codesourcery.com> References: <487706E2.6040202@codesourcery.com> Message-ID: <20080711142502.GX11657@caradoc.them.org> On Fri, Jul 11, 2008 at 08:08:18AM +0100, Nathan Sidwell wrote: >> It looks like this is part of the CS3 library so I am guessing that >> Newlib is getting linked in which then makes calls to the functions >> above and that CS3 is complaining that they don?t exist since I haven?t >> provided them for my hardware. Is this correct? How can I get rid of >> these warnings? If Newlib is being linked in (which I think it is >> because my final binary is MUCH bigger than before), how do I get it not >> to link in and instead use my provided printf? > > You are most likely correct that newlib is still being linked in. You can > track this down by using the -v option on your final link, to see how the > linker is being invoked. The -Wl,-Map,a.map option may also be useful to > determine what is pulling in newlib. At a guess, it is referenced by the linker script (the INPUT directive). -- Daniel Jacobowitz CodeSourcery From Corrin.Meyer at dornerworks.com Fri Jul 11 14:48:11 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Fri, 11 Jul 2008 10:48:11 -0400 Subject: [coldfire-gnu-discuss] Override printf In-Reply-To: <20080711142502.GX11657@caradoc.them.org> References: <487706E2.6040202@codesourcery.com> <20080711142502.GX11657@caradoc.them.org> Message-ID: >> It looks like this is part of the CS3 library so I am guessing that >> Newlib is getting linked in which then makes calls to the functions >> above and that CS3 is complaining that they don't exist since I haven't >> provided them for my hardware. Is this correct? How can I get rid of >> these warnings? If Newlib is being linked in (which I think it is >> because my final binary is MUCH bigger than before), how do I get it not >> to link in and instead use my provided printf? > > You are most likely correct that newlib is still being linked in. You can > track this down by using the -v option on your final link, to see how the > linker is being invoked. The -Wl,-Map,a.map option may also be useful to > determine what is pulling in newlib. At a guess, it is referenced by the linker script (the INPUT directive). -- Daniel Jacobowitz CodeSourcery I took a quick look at the linker script. I am using one of the default ones: m52235evb-rom.ld. Our board is modeled after the 52235EVB so it seemed like it would work quite nicely. Looking at this script I don't see any references to Newlib. Also, since when I compile a simple empty main() the resultant image is very small I don't think the linker script is trying to include Newlib be default; only if it thinks it is being referenced. I ran the link step with "-Wl,-v" so that I could see how the linker was being invoked. I got the following. cd /home/CorrinMeyer/versimation/sw/1.1/build/firmware && /usr/bin/cmake.exe -E cmake_link_script CMakeFiles/firmware.elf.dir/link.txt --verbose=1 "/cygdrive/c/Program Files/CodeSourcery/Sourcery G++ Lite/bin/m68k-elf-gcc.exe" -fPIC -nodefaultlibs -Wl,-v,-Map,firmware.map -T m52235evb-ram.ld -mcpu=52235 CMakeFiles/firmware.elf.dir/src/init.c.o CMakeFiles/firmware.elf.dir/src/flash.c.o CMakeFiles/firmware.elf.dir/src/crc.c.o CMakeFiles/firmware.elf.dir/src/irq.c.o CMakeFiles/firmware.elf.dir/src/main.c.o -o firmware.elf ../arch/mcf52235/libarch.a ../libc/libdwc.a ../libio/libio.a ../libdw/libdw.a collect2 version 4.2.3 (68k, Motorola syntax) c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/bin/ld.exe --sysroot=c:\program files\codesourcery\sourcery g++ lite\bin\../m68k-elf -o firmware.elf c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/m5208/crtbegin.o -Lc:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/m5208 -Lc:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208 -Lc:/program files/codesourcery/sourcery g++ lite/bin/../m68k-elf/lib/m5208 -Lc:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3 -Lc:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc -Lc:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib -Lc:/program files/codesourcery/sourcery g++ lite/bin/../m68k-elf/lib -v -Map firmware.map CMakeFiles/firmware.elf.dir/src/init.c.o CMakeFiles/firmware.elf.dir/src/flash.c.o CMakeFiles/firmware.elf.dir/src/crc.c.o CMakeFiles/firmware.elf.dir/src/irq.c.o CMakeFiles/firmware.elf.dir/src/main.c.o ../arch/mcf52235/libarch.a ../libc/libdwc.a ../libio/libio.a ../libdw/libdw.a c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/m5208/crtend.o -T m52235evb-ram.ld GNU ld (Sourcery G++ Lite 4.2-125) 2.18.50.20080215c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3 unhosted.a(unhosted-close.o): warning: IO function 'close' used c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3 unhosted.a(unhosted-fstat.o): warning: IO function 'fstat' used c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3 unhosted.a(unhosted-isatty.o): warning: IO function 'isatty' used c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3 unhosted.a(unhosted-lseek.o): warning: IO function 'lseek' used c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3 unhosted.a(unhosted-read.o): warning: IO function 'read' used c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3 unhosted.a(unhosted-write.o): warning: IO function 'write' used >From this I am seeing that gcc is being invoked as the front end to the linker. I am using CMake to manage the build process and this is just how it does it. I have passed in "-nodefaultlibs". My understanding is that this should stop the C library (Newlib) from being linked in but keep the Startup code (CS3?) which is what I want. Does indeed seem that the C library is not being included (no -lc on the linker command) I also generated a Map file to see what was being included and where. Here is a snippet. c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libc.a (lib_a-fclose.o) c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libc.a (lib_a-findfp.o) (fclose) c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libc.a (lib_a-fstatr.o) c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libc.a (lib_a-makebuf.o) (_fstat_r) c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libc.a (lib_a-isattyr.o) c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libc.a (lib_a-makebuf.o) (_isatty_r) c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libc.a (lib_a-lseekr.o) c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libc.a (lib_a-stdio.o) (_lseek_r) c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libc.a (lib_a-readr.o) c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libc.a (lib_a-stdio.o) (_read_r) So even though the linker is being told not to include the C library (as far as I can tell), it is. Corrin Meyer From dan at codesourcery.com Fri Jul 11 14:59:35 2008 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Fri, 11 Jul 2008 10:59:35 -0400 Subject: [coldfire-gnu-discuss] Override printf In-Reply-To: References: <487706E2.6040202@codesourcery.com> <20080711142502.GX11657@caradoc.them.org> Message-ID: <20080711145933.GA11657@caradoc.them.org> On Fri, Jul 11, 2008 at 10:48:11AM -0400, Corrin Meyer wrote: > I took a quick look at the linker script. I am using one of the default > ones: m52235evb-rom.ld. Our board is modeled after the 52235EVB so it > seemed like it would work quite nicely. Looking at this script I don't > see any references to Newlib. Does it have a GROUP line for -lc? -- Daniel Jacobowitz CodeSourcery From Corrin.Meyer at dornerworks.com Fri Jul 11 15:07:23 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Fri, 11 Jul 2008 11:07:23 -0400 Subject: [coldfire-gnu-discuss] Override printf In-Reply-To: <20080711145933.GA11657@caradoc.them.org> References: <487706E2.6040202@codesourcery.com> <20080711142502.GX11657@caradoc.them.org> <20080711145933.GA11657@caradoc.them.org> Message-ID: >> I took a quick look at the linker script. I am using one of the default >> ones: m52235evb-rom.ld. Our board is modeled after the 52235EVB so it >> seemed like it would work quite nicely. Looking at this script I don't >> see any references to Newlib. > >Does it have a GROUP line for -lc? > >-- >Daniel Jacobowitz >CodeSourcery I just saw that. Yes it does. I made a copy of the linker script and removed the "-lc" from the GROUP command. I also saw "-lgcc" so I am not sure if I should remove that as well; leaving it for the time being. Once I removed "-lc" it seems that Newlib is not longer getting included, but now instead of warnings, I am getting errors: GNU ld (Sourcery G++ Lite 4.2-125) 2.18.50.20080215CMakeFiles/firmware.elf.dir/src/main.c.o: In function `main': /home/CorrinMeyer/versimation/sw/1.1/src/firmware/src/main.c:17: undefined reference to `puts' c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3 .a(start_c.o): In function `__cs3_start_c': start_c.c:(.text+0x6a): undefined reference to `__libc_init_array Now line main.c:17 is actually a printf and it should be calling my printf. Not exactly sure why it is getting labeled as a reference to 'puts'. I have no idea what the undefined "__libc_init_array" is. Is this a list of initialization functions that should be run by the C library on start? Corrin Meyer From dan at codesourcery.com Fri Jul 11 15:11:03 2008 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Fri, 11 Jul 2008 11:11:03 -0400 Subject: [coldfire-gnu-discuss] Override printf In-Reply-To: References: <487706E2.6040202@codesourcery.com> <20080711142502.GX11657@caradoc.them.org> <20080711145933.GA11657@caradoc.them.org> Message-ID: <20080711151101.GC11657@caradoc.them.org> On Fri, Jul 11, 2008 at 11:07:23AM -0400, Corrin Meyer wrote: > Now line main.c:17 is actually a printf and it should be calling my > printf. Not exactly sure why it is getting labeled as a reference to > 'puts'. GCC automatically optimizes printf of a constant string to puts. You can provide puts, or disable the optimization (-fno-builtin-printf should do it, I believe). > I have no idea what the undefined "__libc_init_array" is. Is > this a list of initialization functions that should be run by the C > library on start? The startup code is partly in other places (like crt* files and libcs3.a), but it calls into newlib. __libc_init_array is a function that executes constructors. I recommend you put your printf, and any other overridden functions, in front of newlib rather than removing it. It may be that this wasn't working for you before because of the printf -> puts optimization. -- Daniel Jacobowitz CodeSourcery From Corrin.Meyer at dornerworks.com Fri Jul 11 15:23:46 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Fri, 11 Jul 2008 11:23:46 -0400 Subject: [coldfire-gnu-discuss] Override printf In-Reply-To: <20080711151101.GC11657@caradoc.them.org> References: <487706E2.6040202@codesourcery.com> <20080711142502.GX11657@caradoc.them.org> <20080711145933.GA11657@caradoc.them.org> <20080711151101.GC11657@caradoc.them.org> Message-ID: >GCC automatically optimizes printf of a constant string to puts. You >can provide puts, or disable the optimization (-fno-builtin-printf >should do it, I believe). > >The startup code is partly in other places (like crt* files and >libcs3.a), but it calls into newlib. __libc_init_array is a function >that executes constructors. > >I recommend you put your printf, and any other overridden functions, >in front of newlib rather than removing it. It may be that this >wasn't working for you before because of the printf -> puts optimization. > >-- >Daniel Jacobowitz >CodeSourcery Adding '-fno-builtin-printf' seems to have solved my problems. The built binary is much smaller; on the order of what I expected. Since it seems that Newlib is not being linked in, I have to assume that my C library replacement is being placed in front of it even though I am not sure how to explicitly say so. Is there a way to guarantee that this will always be the case? Corrin Meyer From dan at codesourcery.com Fri Jul 11 15:43:54 2008 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Fri, 11 Jul 2008 11:43:54 -0400 Subject: [coldfire-gnu-discuss] Override printf In-Reply-To: References: <487706E2.6040202@codesourcery.com> <20080711142502.GX11657@caradoc.them.org> <20080711145933.GA11657@caradoc.them.org> <20080711151101.GC11657@caradoc.them.org> Message-ID: <20080711154352.GD11657@caradoc.them.org> On Fri, Jul 11, 2008 at 11:23:46AM -0400, Corrin Meyer wrote: > Adding '-fno-builtin-printf' seems to have solved my problems. The > built binary is much smaller; on the order of what I expected. Since it > seems that Newlib is not being linked in, I have to assume that my C > library replacement is being placed in front of it even though I am not > sure how to explicitly say so. Is there a way to guarantee that this > will always be the case? It's important not to think of Newlib as a single monolithic entity. Your program will include only those bits of Newlib that you need, for instance the __libc_init_array function. You might be able to look at the map file to see which newlib objects are being pulled in, and include just those yourself. This has potential to break as you require more of the library, however. -- Daniel Jacobowitz CodeSourcery From bryan at adapt4.com Fri Jul 11 17:23:44 2008 From: bryan at adapt4.com (Bryan Kattwinkel) Date: Fri, 11 Jul 2008 13:23:44 -0400 Subject: [coldfire-gnu-discuss] Override printf Message-ID: <48779720.4030301@adapt4.com> -nodefaultlibs works for me. in my linker script, the entire STARTUP and GROUP lines are commented out, and there are some comments and lines related to "crt" that I don't understand. in my code, I have: /* The GNU compiler converts printf of a single char into putchar, * and printf of a constant string\n to puts of that string w/o \n. * Since we are not using the C lib, provide these substitues. */ int putchar( int c ) { out_char( c ); return c; } int puts( const char *s ) { return printf( "%s\n", s ); } From Christof.Frey at varian.com Mon Jul 21 14:15:20 2008 From: Christof.Frey at varian.com (Christof Frey) Date: Mon, 21 Jul 2008 07:15:20 -0700 Subject: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo" References: <486D233B.4070502@codesourcery.com> <486DC6BC.4070709@codesourcery.com> <48735D41.6060408@codesourcery.com> Message-ID: is there any more support you can give on the subject or am I completely off track ? (I had a similar behviour with a port of a larger application and thus wanted to start with this mickey - mouse example as outlined in the manuals - just to make sure I am not doing anything completely wrong) Thank, Christof -----Original Message----- From: Christof Frey Sent: Tuesday, July 08, 2008 5:05 PM To: 'Nathan Sidwell' Cc: Mark Mitchell; coldfire-gnu-discuss at codesourcery.com Subject: RE: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo" Well, don't know whether the pgm arrived via an exception / trap there or GDB is lying. Stackframe looked odd to me as well (thus the stupid question where it starts...) Code addresses: .text 0x000008dc 0x16 c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3hosted.a(hosted-_exit.o) 0x000008dc _exit *fill* 0x000008f2 0x2 00 .text 0x000008f4 0x4c c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3hosted.a(hosted-write.o) 0x000008f4 write .text 0x00000940 0x2b2 c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3hosted.a(hosted-gdb.o) 0x00000940 __cs3_hosted_to_gdb_mode_t 0x00000a2a __cs3_hosted_from_gdb_stat 0x00000a04 __cs3_hosted_to_gdb_lseek_flags 0x00000a86 __cs3_hosted_from_gdb_timeval 0x000009be __cs3_hosted_to_gdb_open_flags Command line degugger: .. (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 0xdf4 lma 0x0 Loading section .eh_frame, size 0x4 lma 0xdf4 Loading section .rodata, size 0x68 lma 0xdf8 Loading section .data, size 0x400 lma 0xe60 Start address 0xcc4, load size 4704 Transfer rate: 2 KB/sec, 1176 bytes/write. (gdb) break main Breakpoint 1 at 0x608: file fib.c, line 16. (gdb) continue Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000d3a in __cs3_isr_divide_by_zero () (gdb) x/8xw $sp 0xffffb4: 0x000009a0 0x000008de 0x00000000 0x00ffffcc 0xffffc4: 0x00000e20 0x00ffffe0 0x00ffffe0 0xfffffffe (gdb) Code: (per example) #include // this program uses the debugger for write() function static int Fib (unsigned n, unsigned a, unsigned b) { unsigned count; for (count = 0; count != b; count++) { write (1, ".", 1); } write (1, "\n", 1); if (n) { Fib (n-1, b, a + b); } } int main () { write (1, "Fibonacci\n", 10); Fib (9, 0, 1); return (0); } -----Original Message----- From: Nathan Sidwell [mailto:nathan at codesourcery.com] Sent: Tuesday, July 08, 2008 2:28 PM To: Christof Frey Cc: Mark Mitchell; coldfire-gnu-discuss at codesourcery.com Subject: Re: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo" Christof Frey wrote: > According to CFPRM the stack frame is two long word: > SSP -> 32 Bit control information > SSP + 0x4 -> program counter > > So is the SSP pointing to 0xffffb4 below the frame of interest ? > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00000d3a in __cs3_isr_divide_by_zero () > (gdb) x/8xw $sp > 0xffffb4: 0x000009a0 0x000008de 0x00000000 0x00ffffcc > 0xffffc4: 0x00000e20 0x00ffffe0 0x00ffffe0 0xfffffffe This is an odd stack frame, as there appears to be no sign of the control information. The control information contains the original PSW and the exception information. I'm wondering if you did arrive here via an exception. The 0x9a0 and 0x8de look like they might be code addresses -- what is at those locations? nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery From Christof.Frey at varian.com Thu Jul 24 09:53:38 2008 From: Christof.Frey at varian.com (Christof Frey) Date: Thu, 24 Jul 2008 02:53:38 -0700 Subject: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo" References: <486D233B.4070502@codesourcery.com> <486DC6BC.4070709@codesourcery.com> <48735D41.6060408@codesourcery.com> Message-ID: The problem is in the linker script for MCF5235 provided by the toolchain. - When linking with the script "m5275evb-ram-hosted.ld" the application runs as expected. - when using "m5235evb-ram-hosted.ld" it fails as per subject (zero divide trap) Any plans to fix this? Christof From mark at codesourcery.com Thu Jul 24 16:30:37 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Thu, 24 Jul 2008 09:30:37 -0700 Subject: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo" In-Reply-To: References: <486D233B.4070502@codesourcery.com> <486DC6BC.4070709@codesourcery.com> <48735D41.6060408@codesourcery.com> Message-ID: <4888AE2D.5030805@codesourcery.com> Christof Frey wrote: > The problem is in the linker script for MCF5235 provided by the toolchain. > > - When linking with the script "m5275evb-ram-hosted.ld" the application runs as expected. > - when using "m5235evb-ram-hosted.ld" it fails as per subject (zero divide trap) That's interesting. I see two differences: the length of the ipsbar memory region, and the startup code used. Would you be willing to try editing the M5235 linker script to see which of these is the problem? In particular, if you change: PROVIDE(__cs3_reset_m5235evb = _start); __cs3_reset = __cs3_reset_m5235evb; to use m52755 does that help? What about if you change: ipsbar (rw) : ORIGIN = 0x40000000, LENGTH = 2M to: ipsbar (rw) : ORIGIN = 0x40000000, LENGTH = 0x200000 Finally, what about adding: LONG (0) right before: __cs3_regions_end = .; Thanks, -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From Christof.Frey at varian.com Fri Jul 25 07:07:46 2008 From: Christof.Frey at varian.com (Christof Frey) Date: Fri, 25 Jul 2008 00:07:46 -0700 Subject: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo" In-Reply-To: <4888AE2D.5030805@codesourcery.com> References: <486D233B.4070502@codesourcery.com> <486DC6BC.4070709@codesourcery.com> <48735D41.6060408@codesourcery.com> <4888AE2D.5030805@codesourcery.com> Message-ID: >In particular, if you change: > > PROVIDE(__cs3_reset_m5235evb = _start); > __cs3_reset = __cs3_reset_m5235evb; > >to use m52755 does that help? The following changes in the linker script cure the problem: EXTERN(__cs3_reset_m5275evb) PROVIDE(__cs3_reset_m5275evb = _start); __cs3_reset = __cs3_reset_m5275evb; So it seems the problem is indeed in the startup code for m5235 Christof From maxim at codesourcery.com Fri Jul 25 09:11:12 2008 From: maxim at codesourcery.com (Maxim Kuvyrkov) Date: Fri, 25 Jul 2008 11:11:12 +0200 Subject: [coldfire-gnu-discuss] real time problem with MCF5485 In-Reply-To: <006001c8e360$36974cf0$82bebfc0@RSAI.local> References: <006001c8e360$36974cf0$82bebfc0@RSAI.local> Message-ID: <488998B0.7040608@codesourcery.com> Jean Christophe BARRIOL wrote: > Hi, > > We notice a strange problem with Coldfire MCF5485 (and also with MCF5234): > > The treatment time (the time for the CPU to run the code) of an ISR, > which has the highest priority level, varies according to the code that > run on others ISR or Main task. !!!! > > We verified that the Real time ISR (the one with the highest priority) > is never preempt ! > > We also use MCF5407. There?s no problem with it. > > Any idea ? This doesn't look like a toolchain issue. Have you contacted Freescale about it? -- Maxim From jean-christophe.barriol at rsautomation.com Fri Jul 25 11:18:01 2008 From: jean-christophe.barriol at rsautomation.com (Jean Christophe BARRIOL) Date: Fri, 25 Jul 2008 13:18:01 +0200 Subject: [coldfire-gnu-discuss] real time problem with MCF5485 References: <006001c8e360$36974cf0$82bebfc0@RSAI.local> <488998B0.7040608@codesourcery.com> Message-ID: <002c01c8ee48$1a5ae680$82bebfc0@RSAI.local> > Jean Christophe BARRIOL wrote: >> Hi, >> >> We notice a strange problem with Coldfire MCF5485 (and also with >> MCF5234): >> >> The treatment time (the time for the CPU to run the code) of an ISR, >> which has the highest priority level, varies according to the code that >> run on others ISR or Main task. !!!! >> >> We verified that the Real time ISR (the one with the highest priority) is >> never preempt ! >> >> We also use MCF5407. There?s no problem with it. >> >> Any idea ? > > This doesn't look like a toolchain issue. Have you contacted Freescale > about it? > > Maxim > Yes, They found out that "The cause of the problem is due to code-misalignment in memory. By including the extra interrupt, the code was becoming mis-aligned and thus taking two memory access to retrieve data instead of one. This is what caused the longer execution time." With GCC, we added the option "malign-int". Things are better: with Cache desable, it seams there's no more jitter, but with cache enable, we still have a jitter on the treatment time of the Real time ISR: The treatment time still varies according to the the task that is preempted ! thanks you for help Jean Christophe. From mark at codesourcery.com Fri Jul 25 21:17:48 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Fri, 25 Jul 2008 14:17:48 -0700 Subject: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo" In-Reply-To: References: <486D233B.4070502@codesourcery.com> <486DC6BC.4070709@codesourcery.com> <48735D41.6060408@codesourcery.com> <4888AE2D.5030805@codesourcery.com> Message-ID: <488A42FC.1020808@codesourcery.com> Christof Frey wrote: > EXTERN(__cs3_reset_m5275evb) > > PROVIDE(__cs3_reset_m5275evb = _start); > __cs3_reset = __cs3_reset_m5275evb; > > So it seems the problem is indeed in the startup code for m5235 Thanks, that's helpful. I've filed an issue internally. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713