From haluongvn at gmail.com Thu Feb 1 10:37:42 2007 From: haluongvn at gmail.com (Ha Luong) Date: Thu, 1 Feb 2007 04:37:42 -0600 Subject: save value at 0x1000090C with board 5485 Message-ID: <61577c8f0702010237o2b076bcif5b5673cd37d959@mail.gmail.com> I run code #define SLT_SSR0 (*(unsigned long *)(void*)(0x1000090C)) int main (void) { int i=0; SLT_SSR0=i; i=1; SLT_SSR0=i; printf("%lu",SLT_SSR0); i=2; SLT_SSR0=i; printf("%lu",SLT_SSR0); i=3; SLT_SSR0=i; printf("%lu",SLT_SSR0); i=4; SLT_SSR0=i; printf("%lu",SLT_SSR0); return 0; } and receive 0034 . I don't know why 2 first values didn't receive 1,2 . Thanks for your help -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.mcconkey at cambridgeimaging.co.uk Thu Feb 1 10:52:47 2007 From: paul.mcconkey at cambridgeimaging.co.uk (Paul McConkey) Date: Thu, 1 Feb 2007 10:52:47 -0000 Subject: [coldfire-gnu-discuss] save value at 0x1000090C with board 5485 In-Reply-To: <61577c8f0702010237o2b076bcif5b5673cd37d959@mail.gmail.com> References: <61577c8f0702010237o2b076bcif5b5673cd37d959@mail.gmail.com> Message-ID: <59789F6B85725F4CAD78243CDDBA4C6631AA26@SERVA.grange.local> Hi, Maybe the compiler optimisations that you have set mean that some of the code is being removed. It is a good idea to make memory locations like this volatile, you could try: #define SLT_SSR0 (*(volatile unsigned long *)(void*)(0x1000090C)) If this doesn't work, please post the commands you use to compile this. Cheers, Paul. ________________________________ From: Ha Luong [mailto:haluongvn at gmail.com] Sent: 01 February 2007 10:38 To: coldfire-gnu-discuss at codesourcery.com Subject: [coldfire-gnu-discuss] save value at 0x1000090C with board 5485 I run code int main (void) { int i=0; SLT_SSR0=i; i=1; SLT_SSR0=i; printf("%lu",SLT_SSR0); i=2; SLT_SSR0=i; printf("%lu",SLT_SSR0); i=3; SLT_SSR0=i; printf("%lu",SLT_SSR0); i=4; SLT_SSR0=i; printf("%lu",SLT_SSR0); return 0; } and receive 0034 . I don't know why 2 first values didn't receive 1,2 . Thanks for your help From aejdeling at nordic.imaje.com Thu Feb 1 13:59:59 2007 From: aejdeling at nordic.imaje.com (Anders Ejdeling) Date: Thu, 1 Feb 2007 14:59:59 +0100 Subject: Problem with m68k-elf-ar and absolute Cygwin paths Message-ID: <8D46EA12A35CED4D960D92AB4E19F4EB01FAC213@GOTSRVEXCH.nordic.imaje.intra> I am using Sourcery G++ Lite from within the Cygwin shell to build eCos. I have followed the instructions in the Getting Started guide to set the CYGPATH variable. Everything works fine except for calling m68k-elf-ar with an absolute path to the target. ar creates a temporary file but fails to rename it to the proper target name. $ m68k-elf-ar -r /m68k-elf-ar_test/test.a m68k-elf-ar_test/testobj.o c:\IB\gcc\m68k-elf-gcc-4.1-32\bin\m68k-elf-ar.exe: creating /m68k-elf-ar_test/test.a c:\IB\gcc\m68k-elf-gcc-4.1-32\bin\m68k-elf-ar.exe: unable to rename '/m68k-elf-ar_test/test.a' reason: No such file or directory Left in the directory 'm68k-elf-ar_test' is test.a (contains only an 8 byte header) and sta11296 (the temporary lib file). Absolute paths works fine with m68k-elf-gcc and other Sourcery G++ Lite tools. Tested with Sourcery G++ 4.1-32 for Coldfire ELF. -- Anders Ejdeling Imaje AB ********************************************************************** IMAJE: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. They may contain confidential or legally privileged information. If you have received this email by mistake please notify Imaje immediately by responding to this e-mail and then delete it from your system without producing, distributing or retaining copies hereof. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. From nathan at codesourcery.com Thu Feb 1 14:27:55 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Thu, 01 Feb 2007 14:27:55 +0000 Subject: [coldfire-gnu-discuss] Problem with m68k-elf-ar and absolute Cygwin paths In-Reply-To: <8D46EA12A35CED4D960D92AB4E19F4EB01FAC213@GOTSRVEXCH.nordic.imaje.intra> References: <8D46EA12A35CED4D960D92AB4E19F4EB01FAC213@GOTSRVEXCH.nordic.imaje.intra> Message-ID: <45C1F8EB.2070606@codesourcery.com> Anders Ejdeling wrote: > I am using Sourcery G++ Lite from within the Cygwin shell to build eCos. I have followed the instructions in the Getting Started guide to set the CYGPATH variable. > > Everything works fine except for calling m68k-elf-ar with an absolute path to the target. ar creates a temporary file but fails to rename it to the proper target name. > > $ m68k-elf-ar -r /m68k-elf-ar_test/test.a m68k-elf-ar_test/testobj.o > c:\IB\gcc\m68k-elf-gcc-4.1-32\bin\m68k-elf-ar.exe: creating /m68k-elf-ar_test/test.a > c:\IB\gcc\m68k-elf-gcc-4.1-32\bin\m68k-elf-ar.exe: unable to rename '/m68k-elf-ar_test/test.a' reason: No such file or directory > > Left in the directory 'm68k-elf-ar_test' is test.a (contains only an 8 byte header) and sta11296 (the temporary lib file). > > Absolute paths works fine with m68k-elf-gcc and other Sourcery G++ Lite tools. Thank you for this bug report. We are investigating. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From okalex at gmail.com Thu Feb 1 14:26:52 2007 From: okalex at gmail.com (Alex Parkinson) Date: Thu, 1 Feb 2007 09:26:52 -0500 Subject: Port access with gcc Message-ID: <1ec5776b0702010626l58f3acc8x6794e268fcb6cdaf@mail.gmail.com> Hi, I've run through the getting started guide and have gotten the tools working with my M52233DEMO board. I'm now trying to write a simple LED blinkey program, but I have so far been unable to find any information on setting up and writing a port. I'm new to gcc, so the best help someone could provide is to let me know where I can find such information on my own, as I'm sure many more questions will pop up as I go along. Thanks in advance, Alex Parkinson -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at codesourcery.com Thu Feb 1 14:54:39 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Thu, 01 Feb 2007 14:54:39 +0000 Subject: [coldfire-gnu-discuss] Port access with gcc In-Reply-To: <1ec5776b0702010626l58f3acc8x6794e268fcb6cdaf@mail.gmail.com> References: <1ec5776b0702010626l58f3acc8x6794e268fcb6cdaf@mail.gmail.com> Message-ID: <45C1FF2F.4070204@codesourcery.com> Alex Parkinson wrote: > Hi, > > I've run through the getting started guide and have gotten the tools > working with my M52233DEMO board. I'm now trying to write a simple LED > blinkey program, but I have so far been unable to find any information > on setting up and writing a port. I'm new to gcc, so the best help > someone could provide is to let me know where I can find such > information on my own, as I'm sure many more questions will pop up as I > go along. The port will be a memory mapped address. You can access it from C with something like #define my_port (*(volatile int)NNNNN) where NNNNN is the address of the port. If the port is not 32 bits wide, use short or char as appropriate. int Foo () { myport = 0; myport = 1; return myport; } nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From okalex at gmail.com Thu Feb 1 15:35:49 2007 From: okalex at gmail.com (Alex Parkinson) Date: Thu, 1 Feb 2007 10:35:49 -0500 Subject: [coldfire-gnu-discuss] Port access with gcc In-Reply-To: <45C1FF2F.4070204@codesourcery.com> References: <1ec5776b0702010626l58f3acc8x6794e268fcb6cdaf@mail.gmail.com> <45C1FF2F.4070204@codesourcery.com> Message-ID: <1ec5776b0702010735s42099d90l6162b55e2b9595e9@mail.gmail.com> On 2/1/07, Nathan Sidwell wrote: > The port will be a memory mapped address. You can access it from C with > something like > > #define my_port (*(volatile int)NNNNN) > > where NNNNN is the address of the port. If the port is not 32 bits wide, > use > short or char as appropriate. > > int Foo () > { > myport = 0; > myport = 1; > return myport; > } > Thanks, Nathan. At first this was generating a compiler error, but it turns out that the port definition should actually be #define my_port (*(volatile int *)NNNNN) Notice the extra '*'. Without this, the code was generating the error, "error: invalid type argument of 'unary *'". All is working now. Cheers, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos at codesourcery.com Thu Feb 1 17:43:27 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Thu, 1 Feb 2007 12:43:27 -0500 Subject: [coldfire-gnu-discuss] save value at 0x1000090C with board 5485 In-Reply-To: <61577c8f0702010237o2b076bcif5b5673cd37d959@mail.gmail.com> References: <61577c8f0702010237o2b076bcif5b5673cd37d959@mail.gmail.com> Message-ID: <20070201174322.GB15617@lios> On Thu, Feb 01, 2007 at 04:37:42AM -0600, Ha Luong wrote: > #define SLT_SSR0 (*(unsigned long *)(void*)(0x1000090C)) > int main (void) > { > int i=0; > SLT_SSR0=i; > i=1; > SLT_SSR0=i; > printf("%lu",SLT_SSR0); > i=2; > SLT_SSR0=i; > printf("%lu",SLT_SSR0); > i=3; > SLT_SSR0=i; > printf("%lu",SLT_SSR0); > i=4; > SLT_SSR0=i; > printf("%lu",SLT_SSR0); > > return 0; > } > > and receive 0034 . I don't know why 2 first values didn't receive 1,2 . Thank you for using Sourcery G++! At the highest optimization I get "1234" when I run this on real hardware. The assembly output from the compiler looks correct. As another poster has mentioned, if you expect SLT_SSR0 to change unexpectedly then you should mark the data or accesses as "volatile." In order to recreate the problem on our end we need you to provide us with the following information: 1. The compiler command line that causes the failure. e.g. g++ -O2 -g -o test.o test.cc 2. The output of running the compiler but with "-v" added. e.g. g++ -v -O2 -g -o test.o test.cc > compiler.log 3. The pre-processed source output by the compiler. This is done by adding '-save-temps' to the compiler command line. This produces a ".ii" file that you can attach to an email. e.g. g++ -save-temps -v -O2 -g -o test.o test.cc Please attach the "compiler.log" and the "*.ii" file to an email. Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From haluongvn at gmail.com Fri Feb 2 08:22:46 2007 From: haluongvn at gmail.com (Ha Luong) Date: Fri, 2 Feb 2007 02:22:46 -0600 Subject: cannot use movec instruction Message-ID: <61577c8f0702020022o1d87fd11u7f467a75946e1962@mail.gmail.com> Dear all, I can't use movec instruction when compile and link with mcpu=5485. The error is C:\DOCUME~1\haluong\LOCALS~1\Temp/ccsbbaaa.s: Assembler messages: C:\DOCUME~1\haluong\LOCALS~1\Temp/ccsbbaaa.s:10: Error: operands mismatch -- sta tement `movec %d0,%ACR0' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccsbbaaa.s:10: Error: operands mismatch -- sta tement `movec %d0,%ACR1' ignored My code is: __asm__("move.l #0x01040100,%d0"); __asm__("movec %d0,%CACR"); But I can use movec instruction with mcpu=5282. I don't know I have any mistake. Thanks for your help Ha Luong -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at codesourcery.com Fri Feb 2 09:18:33 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Fri, 02 Feb 2007 09:18:33 +0000 Subject: [coldfire-gnu-discuss] cannot use movec instruction In-Reply-To: <61577c8f0702020022o1d87fd11u7f467a75946e1962@mail.gmail.com> References: <61577c8f0702020022o1d87fd11u7f467a75946e1962@mail.gmail.com> Message-ID: <45C301E9.8010807@codesourcery.com> Ha Luong wrote: > Dear all, > I can't use movec instruction when compile and link with mcpu=5485. The > error is > C:\DOCUME~1\haluong\LOCALS~1\Temp/ccsbbaaa.s: Assembler messages: > C:\DOCUME~1\haluong\LOCALS~1\Temp/ccsbbaaa.s:10: Error: operands > mismatch -- sta > tement `movec %d0,%ACR0' ignored > C:\DOCUME~1\haluong\LOCALS~1\Temp/ccsbbaaa.s:10: Error: operands > mismatch -- sta > tement `movec %d0,%ACR1' ignored > My code is: > __asm__("move.l #0x01040100,%d0"); > __asm__("movec %d0,%CACR"); > But I can use movec instruction with mcpu=5282. I don't know I have any > mistake. The error messages you provide mention ACR0 and ACR1. The source code you provided mentions CACR. I've tried the source you provide, and it compiles without error. however, I do see that the assembler does not think the m5485 cpu has ACR0 and ACR1. This will be fixed in a later release. Thank you for reporting the problem. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From update at yourfreemortgageguide.com Fri Feb 2 13:04:05 2007 From: update at yourfreemortgageguide.com (FreeMortgageGuide) Date: Fri, 02 Feb 2007 13:04:05 Subject: " Is now a good time to review your mortgage deal ? " for coldfire-gnu-discuss@codesourcery.com on Fri, 02 Feb 2007 13:04:05 Message-ID: <20070202130405.28087.qmail@yourfreemortgageguide.com> Dear Business Professional, We would like to introduce a brand new web site designed especially for busy business professionals; www.YourFreeMortgageGuide.com YourFreeMortgageGuide.com provides access to a national alliance of mortgage advisers throughout the UK who are all professionally qualified to help you choose the right mortgage or re-mortgage for you. If you would like to speak to a qualified mortgage adviser, free of charge and with no obligation, please go to www.YourFreeMortgageGuide.com and complete a short on-line form. Kind regards, The YourFreeMortgageGuide.com team PS With over 8,000 mortgage deals available, it pays to talk to an expert. To stop receiving these mailings go to http://www.YourFreeMortgageGuide.com/emailcancel.htm?email=coldfire-gnu-discuss at codesourcery.com C Copyright YourFreeMortgageGuide.com. 2007. All rights reserved -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos at codesourcery.com Fri Feb 2 16:48:47 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Fri, 2 Feb 2007 11:48:47 -0500 Subject: [coldfire-gnu-discuss] save value at 0x1000090C with board 5485 In-Reply-To: <61577c8f0702011912x36be87c0y598b216f4e1fb955@mail.gmail.com> References: <61577c8f0702010237o2b076bcif5b5673cd37d959@mail.gmail.com> <20070201174322.GB15617@lios> <61577c8f0702011912x36be87c0y598b216f4e1fb955@mail.gmail.com> Message-ID: <20070202164847.GK15617@lios> On Thu, Feb 01, 2007 at 09:12:22PM -0600, Ha Luong wrote: > c:/codesourcery/sourcerygpp/bin/../lib/gcc/m68k-elf/4.1.1/../../../../m68k-elf/bin/as.exe > -mcpu=5485 -o main.o main.s Ha, Please add the following two lines to the start of your program to provide a definition for printf(): #include #include Could you provide the final link step to produce the output binary that you run on your target hardware? I only see the intermediate step used to build main.o. Have you written your own version of printf()? Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From publicjoke at mail.ru Sat Feb 10 14:16:57 2007 From: publicjoke at mail.ru (=?koi8-r?Q?=E9=C7=CF=D2=D8?=) Date: Sat, 10 Feb 2007 17:16:57 +0300 Subject: =?koi8-r?Q?How_to_relocate_GLOBAL=5FOFFSET=5FTABLE_from_RAM_into_ROM?= Message-ID: I use MCF5213 with 32Kb of SRAM and i was very surprised that function addresses table linked into SRAM. If i understand correctly, this behaviour may be changed by modifying the linker script, i.e. by move the string "*(.got.plt) *(.got)" from .data into .text. But when i do it, i have many overlap errors. Can someone provide any suggestions? From nathan at codesourcery.com Sat Feb 10 17:17:51 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Sat, 10 Feb 2007 17:17:51 +0000 Subject: [coldfire-gnu-discuss] How to relocate GLOBAL_OFFSET_TABLE from RAM into ROM In-Reply-To: References: Message-ID: <45CDFE3F.4080501@codesourcery.com> ????? wrote: > I use MCF5213 with 32Kb of SRAM and i was very surprised that function addresses table linked into SRAM. If i understand correctly, this behaviour may be changed by modifying the linker script, i.e. by move the string "*(.got.plt) *(.got)" from .data into .text. But when i do it, i have many overlap errors. Can someone provide any suggestions? You need to change the contents of the MEMORY section of the file. set the ram address to something else. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From csylvain at electro-technica.com Tue Feb 13 20:08:26 2007 From: csylvain at electro-technica.com (Claude Sylvain) Date: Tue, 13 Feb 2007 15:08:26 -0500 Subject: Getting started when firmware is located in ColdFire internal FLASH. Message-ID: <7.0.1.0.2.20070213150724.02306188@electro-technica.com> Hello, I currently do evaluation using a M52235EVB (Evaluation Board). Since the beginning of my evaluation of Sourcery G++ for the ColdFire processors, I only load/run the firmware using the internal ColdFire SRAM, and all is going fine. After searching a while, I have not found any documentation that tell how to get the internal ColdeFire FLASH programmed, and how to debug the firmware from the FLASH. Is m68k-elf-sprite is able to program the internal FLASH of a ColdFire, or do I have to use another utility ? Claude Sylvain Electro-Technica inc. From mark at codesourcery.com Tue Feb 13 22:45:26 2007 From: mark at codesourcery.com (Mark Mitchell) Date: Tue, 13 Feb 2007 14:45:26 -0800 Subject: [coldfire-gnu-discuss] Getting started when firmware is located in ColdFire internal FLASH. In-Reply-To: <7.0.1.0.2.20070213150724.02306188@electro-technica.com> References: <7.0.1.0.2.20070213150724.02306188@electro-technica.com> Message-ID: <45D23F86.9080908@codesourcery.com> Claude Sylvain wrote: > Is m68k-elf-sprite is able to program the internal FLASH of a ColdFire, > or do I have to use another utility ? We are currently working on adding flash support for a variety of chips directly to Sourcery G++. Our initial targets are chips that implement the Intel and AMD flash protocols. (That is not related to the x86 instruction set; it's a protocol used for programming the flash chips.) Do you happen to know if the internal flash in the ColdFire chips supports that? Nathan, do you know if the current versions of the sprite, as provided with the Professional Edition, support the internal flash on the M52235EVB boards? If not, the CFFLASHER utility from Freescale: http://www.freescale.com/files/soft_dev_tools/software/programmers/CFFLASHER.zip?fsrch=1 should be able to program the flash on these parts? Thanks, -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From csylvain at electro-technica.com Wed Feb 14 03:11:50 2007 From: csylvain at electro-technica.com (Claude Sylvain) Date: Tue, 13 Feb 2007 22:11:50 -0500 Subject: [coldfire-gnu-discuss] Getting started when firmware is located in ColdFire internal FLASH. Message-ID: <7.0.1.0.2.20070213221039.026cb018@sympatico.ca> Hello Mark, > > Mark Mitchell wrote: > > > We are currently working on adding flash support for a variety of chips > directly to Sourcery G++. Our initial targets are chips that implement > the Intel and AMD flash protocols. (That is not related to the x86 > instruction set; it's a protocol used for programming the flash chips.) > Do you happen to know if the internal flash in the ColdFire chips > supports that? I don't know what protocol the ColdFire internal FLASH use. Regards, Claude Sylvain Electro-Technica inc. From nathan at codesourcery.com Wed Feb 14 06:58:53 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 14 Feb 2007 06:58:53 +0000 Subject: [coldfire-gnu-discuss] Getting started when firmware is located in ColdFire internal FLASH. In-Reply-To: <7.0.1.0.2.20070213150724.02306188@electro-technica.com> References: <7.0.1.0.2.20070213150724.02306188@electro-technica.com> Message-ID: <45D2B32D.3050203@codesourcery.com> Claude Sylvain wrote: > Hello, > > I currently do evaluation using a M52235EVB (Evaluation Board). > > Since the beginning of my evaluation of Sourcery G++ for the ColdFire > processors, I only load/run the firmware using the internal ColdFire > SRAM, and all is going fine. > > After searching a while, I have not found any documentation that tell > how to get the internal ColdeFire FLASH programmed, and how to debug the > firmware from the FLASH. > > Is m68k-elf-sprite is able to program the internal FLASH of a ColdFire, > or do I have to use another utility ? The current sprite is unable to program flash. flash programming will be in our next release, scheduled for the end of March. Debugging a program from flash already works -- the debugger will use hardware breakpoints rather than patched breakpoints. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From nathan at codesourcery.com Wed Feb 14 07:06:28 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 14 Feb 2007 07:06:28 +0000 Subject: [coldfire-gnu-discuss] Getting started when firmware is located in ColdFire internal FLASH. In-Reply-To: <45D23F86.9080908@codesourcery.com> References: <7.0.1.0.2.20070213150724.02306188@electro-technica.com> <45D23F86.9080908@codesourcery.com> Message-ID: <45D2B4F4.2050707@codesourcery.com> Mark Mitchell wrote: > We are currently working on adding flash support for a variety of chips > directly to Sourcery G++. Our initial targets are chips that implement > the Intel and AMD flash protocols. (That is not related to the x86 > instruction set; it's a protocol used for programming the flash chips.) > Do you happen to know if the internal flash in the ColdFire chips > supports that? At least one CF chip (m5485) uses the Intel protocol for its internal flash. I have not checked the other cpus yet. > Nathan, do you know if the current versions of the sprite, as provided > with the Professional Edition, support the internal flash on the > M52235EVB boards? No. It will be supported with the flash update you mentioned. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From csylvain at electro-technica.com Wed Feb 14 15:06:57 2007 From: csylvain at electro-technica.com (Claude Sylvain) Date: Wed, 14 Feb 2007 10:06:57 -0500 Subject: [coldfire-gnu-discuss] Getting started when firmware is located in ColdFire internal FLASH. Message-ID: <7.0.1.0.2.20070214100445.022f9088@electro-technica.com> Hello Nathan, > > nathan wrote: > > > The current sprite is unable to program flash. flash programming will > be in our next release, scheduled for the end of March. Debugging a > program from flash already works -- the debugger will use hardware > breakpoints rather than patched breakpoints. > Great! So, I have only to find out a tool to program the internal Flash of the M52235 MCU, and all will be up and running. As a programing tool, I have already tryed CFFLASHER. Sadly, this tool seems to not work at all on some Windows XP machine !? So, I will use the "Flash Programmer" tool included inside the CodeWarrior IDE :-/ It is more complex to use, but work on all machines (I know), and it can be configured to match custom emmbedded system. I have 1 question... In the past, I have been able to use Insight (for Windows) with mspgcc (GCC for the TI MSP430 MCUs). I had just to configure Insight to communicate with the "gdbproxy" utility, and all was working fine. Is it possible to do the same with Sourcery G++ ? Regards, Claude Sylvain Electro-Technica inc. From nathan at codesourcery.com Wed Feb 14 15:15:37 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 14 Feb 2007 15:15:37 +0000 Subject: [coldfire-gnu-discuss] Getting started when firmware is located in ColdFire internal FLASH. In-Reply-To: <7.0.1.0.2.20070214100445.022f9088@electro-technica.com> References: <7.0.1.0.2.20070214100445.022f9088@electro-technica.com> Message-ID: <45D32799.9090306@codesourcery.com> Claude Sylvain wrote: > In the past, I have been able to use Insight (for Windows) with mspgcc > (GCC for the TI MSP430 MCUs). I had just to configure Insight to > communicate with the "gdbproxy" utility, and all was working fine. > > Is it possible to do the same with Sourcery G++ ? I do not know. The subscription versions of Sourcery G++ are integrated with Eclipse. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From david at westcontrol.com Wed Feb 14 16:58:53 2007 From: david at westcontrol.com (David Brown) Date: Wed, 14 Feb 2007 17:58:53 +0100 Subject: [coldfire-gnu-discuss] Getting started when firmware is located in ColdFire internal FLASH. In-Reply-To: <7.0.1.0.2.20070214100445.022f9088@electro-technica.com> References: <7.0.1.0.2.20070214100445.022f9088@electro-technica.com> Message-ID: <45D33FCD.7050703@westcontrol.com> Claude Sylvain wrote: > Hello Nathan, > > > > > > nathan wrote: > > > > > > The current sprite is unable to program flash. flash programming will > > be in our next release, scheduled for the end of March. Debugging a > > program from flash already works -- the debugger will use hardware > > breakpoints rather than patched breakpoints. > > > > Great! So, I have only to find out a tool to program the internal > Flash of the M52235 MCU, and all will be up and running. > As a programing tool, I have already tryed CFFLASHER. Sadly, this > tool seems to not work at all on some Windows XP machine !? > So, I will use the "Flash Programmer" tool included inside the CodeWarrior > IDE :-/ It is more complex to use, but work on all machines (I know), > and it can be configured to match custom emmbedded system. > > > I have 1 question... > > In the past, I have been able to use Insight (for Windows) with mspgcc > (GCC for the TI MSP430 MCUs). I had just to configure Insight to > communicate with the "gdbproxy" utility, and all was working fine. > > Is it possible to do the same with Sourcery G++ ? > Insight is a little different from other gdb frontends, in that it is combined with the gdb backend. Thus (I think) you'd need to build gdb for the ColdFire with Insight support. It should be possible, but it might be a little scary if you haven't done it before. There are other front ends available for gdb that can work easily with any backend. I've used gvd with a number of gdb's for different targets, and ddd works too (although it's a bit alien on windows) - Eclipse works basically in this way, although Code Sourcery have added a bit more integration. From csylvain at electro-technica.com Wed Feb 14 18:25:50 2007 From: csylvain at electro-technica.com (Claude Sylvain) Date: Wed, 14 Feb 2007 13:25:50 -0500 Subject: [coldfire-gnu-discuss] Getting started when firmware is located in ColdFire internal FLASH. Message-ID: <7.0.1.0.2.20070214132427.02288810@electro-technica.com> Hello David, > > David Brown wrote: > > > > Insight is a little different from other gdb frontends, in that it is > combined with the gdb backend. Thus (I think) you'd need to build gdb > for the ColdFire with Insight support. It should be possible, but it > might be a little scary if you haven't done it before. > I take a look back to the mspgcc tools set, and you're right. The Insight program that come with mspgcc is build together with GDB in one single file that is named "msp430-gdb.exe". Claude Sylvain Electro-Technica inc. From david at westcontrol.com Wed Feb 14 19:07:06 2007 From: david at westcontrol.com (David Brown) Date: Wed, 14 Feb 2007 20:07:06 +0100 Subject: [coldfire-gnu-discuss] Getting started when firmware is located in ColdFire internal FLASH. In-Reply-To: <7.0.1.0.2.20070214132427.02288810@electro-technica.com> References: <7.0.1.0.2.20070214132427.02288810@electro-technica.com> Message-ID: <45D35DDA.2090404@westcontrol.com> Claude Sylvain wrote: > Hello David, > > > > > > David Brown wrote: > > > > > > > > Insight is a little different from other gdb frontends, in that it is > > combined with the gdb backend. Thus (I think) you'd need to build gdb > > for the ColdFire with Insight support. It should be possible, but it > > might be a little scary if you haven't done it before. > > > > I take a look back to the mspgcc tools set, and you're right. The > Insight program that come with mspgcc is build together with GDB in > one single file that is named "msp430-gdb.exe". > If you are looking for something "lighter" than Eclipse, try The GNAT Programming Studio ( https://libre.adacore.com/gps/ ). I have not used gps much, but the debugger gvd is quite good when you want a simple gui on top of gdb, and it works with any gdb (including msp430-gdb). It has a bit of a bias towards Ada rather than C/C++, but works fine for them too. From csylvain at electro-technica.com Wed Feb 14 23:26:01 2007 From: csylvain at electro-technica.com (Claude Sylvain) Date: Wed, 14 Feb 2007 18:26:01 -0500 Subject: Debugging/Running program in internal Flash. Message-ID: <7.0.1.0.2.20070214182428.02289a78@electro-technica.com> Hello, I finally get the M52235 MCU internal FLASH programmed, using Flash Programmer tool. Before programming the FLASH, I checked that the program was running well in the M52235 MCU internal SRAM. I compiled again the same program using "m52235evb-rom.ld" instead of "m52235evb-ram.ld" as the linker script file. This is the only change I made to the make file. I called GDB using the same command sequence, except for the "load" command that is no more necessary (I think). From that point, the program fail to start, and GDB display the following message: ---------- .. m68k-elf-sprite:Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF Rev C (PE60123 45)) m68k-elf-sprite:Target reset 0x00000000 in __interrupt_vector () Breakpoint 1 at 0x512: file ./src/main.c, line 172. Note: automatically using hardware breakpoints for read-only addresses. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000004 in __interrupt_vector () (gdb) ---------- Later, I unplugged the USB Multilink from the target, and try to start it without the debugger by doing a POR (Power On Reset), without success. Since the program is running well in internal SRAM, it seems to me that something is wrong in the startup code. Furthermore ... Using the disassemble command of GDB, I take a look at the reset entry point (defined as __reset) and found something that looks like an endless loop. See the GDB output below: ---------- (gdb) disassemble 0xcf0 Dump of assembler code for function __reset: 0x00000cf0 <__reset+0>: linkw %fp,#0 0x00000cf4 <__reset+4>: halt 0x00000cf6 <__reset+6>: halt 0x00000cf8 <__reset+8>: bras 0xcf4 <__reset+4> End of assembler dump. (gdb) ---------- Am I missing something, or there is really something wrong in the startup code ? Claude Sylvain Electro-Technica inc. From david at westcontrol.com Thu Feb 15 07:36:24 2007 From: david at westcontrol.com (David Brown) Date: Thu, 15 Feb 2007 08:36:24 +0100 Subject: [coldfire-gnu-discuss] Debugging/Running program in internal Flash. In-Reply-To: <7.0.1.0.2.20070214182428.02289a78@electro-technica.com> References: <7.0.1.0.2.20070214182428.02289a78@electro-technica.com> Message-ID: <45D40D78.5030709@westcontrol.com> Claude Sylvain wrote: > Hello, > > I finally get the M52235 MCU internal FLASH programmed, using Flash > Programmer tool. > > Before programming the FLASH, I checked that the program was running > well in the M52235 MCU internal SRAM. > > I compiled again the same program using "m52235evb-rom.ld" instead of > "m52235evb-ram.ld" as the linker script file. This is the only > change I made to the make file. > > I called GDB using the same command sequence, except for the "load" > command that is no more necessary (I think). > > From that point, the program fail to start, and GDB display the following > message: > > > ---------- > > .. > m68k-elf-sprite:Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF Rev C > (PE60123 > 45)) > m68k-elf-sprite:Target reset > 0x00000000 in __interrupt_vector () > Breakpoint 1 at 0x512: file ./src/main.c, line 172. > Note: automatically using hardware breakpoints for read-only addresses. > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00000004 in __interrupt_vector () > (gdb) > > ---------- > > Later, I unplugged the USB Multilink from the target, and try to start it > without the debugger by doing a POR (Power On Reset), without success. > > Since the program is running well in internal SRAM, it seems to me that > something is wrong in the startup code. > > Furthermore ... > > Using the disassemble command of GDB, I take a look at the reset entry > point (defined as __reset) and found something that looks like an > endless loop. See the GDB output below: > > > ---------- > > (gdb) disassemble 0xcf0 > Dump of assembler code for function __reset: > 0x00000cf0 <__reset+0>: linkw %fp,#0 > 0x00000cf4 <__reset+4>: halt > 0x00000cf6 <__reset+6>: halt > 0x00000cf8 <__reset+8>: bras 0xcf4 <__reset+4> > End of assembler dump. > (gdb) > > ---------- > > Am I missing something, or there is really something wrong in the > startup code ? > > > Claude Sylvain > Electro-Technica inc. > > It looks to me that you are linking with CodeSourcery's bdm semi-hosting library. This can be very handy when you have the debugger connected - your code can access files on the host, for example. But if the debugger is not attached, the program will fail at the first semi-hosting access, as there is no debugger to talk to after a halt, so when making flash versions, make sure you use the non-bdm version of the library. From nathan at codesourcery.com Thu Feb 15 07:28:37 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Thu, 15 Feb 2007 07:28:37 +0000 Subject: [coldfire-gnu-discuss] Debugging/Running program in internal Flash. In-Reply-To: <7.0.1.0.2.20070214182428.02289a78@electro-technica.com> References: <7.0.1.0.2.20070214182428.02289a78@electro-technica.com> Message-ID: <45D40BA5.5010609@codesourcery.com> Claude Sylvain wrote: > .. > m68k-elf-sprite:Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF Rev C > (PE60123 > 45)) > m68k-elf-sprite:Target reset > 0x00000000 in __interrupt_vector () > Breakpoint 1 at 0x512: file ./src/main.c, line 172. > Note: automatically using hardware breakpoints for read-only addresses. > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00000004 in __interrupt_vector () > (gdb) Because you've not loaded the program, GDB has not initialized $pc. you need to set it manually p/x $pc = __reset However ... > Using the disassemble command of GDB, I take a look at the reset entry > point (defined as __reset) and found something that looks like an > endless loop. See the GDB output below: This is an error in the rom linker script. You can work around it by jumping directly to __start p/x $pc = __start nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From csylvain at electro-technica.com Thu Feb 15 15:09:17 2007 From: csylvain at electro-technica.com (Claude Sylvain) Date: Thu, 15 Feb 2007 10:09:17 -0500 Subject: [coldfire-gnu-discuss] Debugging/Running program in internal Flash. Message-ID: <7.0.1.0.2.20070215100754.022e7848@electro-technica.com> Hello David, > > David Brown wrote: > > > It looks to me that you are linking with CodeSourcery's bdm semi-hosting > library. This can be very handy when you have the debugger connected - > your code can access files on the host, for example. But if the debugger > is not attached, the program will fail at the first semi-hosting access, > as there is no debugger to talk to after a halt, so when making flash > versions, make sure you use the non-bdm version of the library. > As stated in the previous mail, I actually use the "m52235evb-rom.ld" linker script . The "m52235evb-rom.ld" refere to the startup code named "cf-unhosted-crt0.o". Here is the first lines of that file: ---------- STARTUP(cf-unhosted-crt0.o) OUTPUT_ARCH(m68k) ENTRY(__start) SEARCH_DIR(.) GROUP(-lc -lunhosted -lcf) __DYNAMIC = 0; ---------- Refering the the above text, we can also see that one of the library is named "unhosted", so I suppose that all is ok here too. So, all seems to be Ok (no use of hosted things). Is it possible that the "cf-unhosted-crt0.o" is not the startup code for the unhosted target !? Is the source code of "cf-unhosted-crt0.o" is available, so I can modify it, and get rid of that problem ? Claude Sylvain Electro-Technica inc. From csylvain at electro-technica.com Thu Feb 15 15:40:36 2007 From: csylvain at electro-technica.com (Claude Sylvain) Date: Thu, 15 Feb 2007 10:40:36 -0500 Subject: [coldfire-gnu-discuss] Debugging/Running program in internal Flash. Message-ID: <7.0.1.0.2.20070215103948.022e90d0@electro-technica.com> Hello Nathan, > > Nathan Sidwell wrote: > >> >> Claude Sylvain wrote: >> >> .. >> m68k-elf-sprite:Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF Rev C >> (PE6012345)) >> m68k-elf-sprite:Target reset >> 0x00000000 in __interrupt_vector () >> Breakpoint 1 at 0x512: file ./src/main.c, line 172. >> Note: automatically using hardware breakpoints for read-only addresses. >> Program received signal SIGTRAP, Trace/breakpoint trap. >> 0x00000004 in __interrupt_vector () >> (gdb) >> > > Because you've not loaded the program, GDB has not initialized $pc. > you need to set it manually > p/x $pc = __reset > >> >> Using the disassemble command of GDB, I take a look at the reset entry >> point (defined as __reset) and found something that looks like an >> endless loop. See the GDB output below: >> > > This is an error in the rom linker script. You can work around it > by jumping directly to __start > p/x $pc = __start > This seems to not work. I am not able to figure out what is going wrong. Here is what GDB says: ---------- .. m68k-elf-sprite:Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF Rev C (PE60123 45)) m68k-elf-sprite:Target reset 0x00000000 in __interrupt_vector () (gdb) break main Breakpoint 1 at 0x512: file ./src/main.c, line 172. (gdb) p/x $pc = __start $1 = 0x400 (gdb) p/x $pc $2 = 0x400 (gdb) continue Continuing. Note: automatically using hardware breakpoints for read-only addresses. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000404 in __start () (gdb) disassemble 0x400 0x420 Dump of assembler code from 0x400 to 0x420: 0x00000400 <__start+0>: moveal #536903680,%sp 0x00000406 <__start+6>: moveal #0,%fp 0x0000040c <__start+12>: movel #0,%d1 0x00000412 <__start+18>: movel %d1,%sp at - 0x00000414 <__start+20>: movel %fp,%sp at - 0x00000416 <__start+22>: jmp 0xc48 <__start1> 0x0000041c <__do_global_dtors_aux+0>: linkw %fp,#0 End of assembler dump. (gdb) stepi 0x00000404 in __start () (gdb) stepi 0x00000404 in __start () (gdb) stepi 0x00000404 in __start () (gdb) stepi 0x00000404 in __start () (gdb) stepi 0x00000404 in __start () (gdb) ---------- Regards, Claude Sylvain Electro-Technica inc. From nathan at codesourcery.com Fri Feb 16 08:19:08 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Fri, 16 Feb 2007 08:19:08 +0000 Subject: [coldfire-gnu-discuss] Debugging/Running program in internal Flash. In-Reply-To: <7.0.1.0.2.20070215103948.022e90d0@electro-technica.com> References: <7.0.1.0.2.20070215103948.022e90d0@electro-technica.com> Message-ID: <45D568FC.6090006@codesourcery.com> Claude Sylvain wrote: > Hello Nathan, > (gdb) p/x $pc > $2 = 0x400 > (gdb) continue > Continuing. > Note: automatically using hardware breakpoints for read-only addresses. > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00000404 in __start () > (gdb) disassemble 0x400 0x420 > Dump of assembler code from 0x400 to 0x420: > 0x00000400 <__start+0>: moveal #536903680,%sp > 0x00000406 <__start+6>: moveal #0,%fp > 0x0000040c <__start+12>: movel #0,%d1 > 0x00000412 <__start+18>: movel %d1,%sp at - > 0x00000414 <__start+20>: movel %fp,%sp at - > 0x00000416 <__start+22>: jmp 0xc48 <__start1> > 0x0000041c <__do_global_dtors_aux+0>: linkw %fp,#0 Looking at the way the PC is behaving I think there's a cache problem. The Icache has not been flushed and has something stale in it. That would explain why the pc has landed at 404, which is not an instruction boundary. I'm not sure how that's happened. IIUC you're using the m52235evb config, right? That does tell the sprite that there is a cache. Here are some suggestions: *) Reset or powercycle the board (the sprite should be resetting the board on first connection though) *) Force a write to RAM from gdb. this will cause the sprite to flush the Icache. p/x *(int *)__data_start = 0x1234567 then reset the pc to 0x400 as you have been doing, and try again. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From csylvain at electro-technica.com Fri Feb 16 16:02:21 2007 From: csylvain at electro-technica.com (Claude Sylvain) Date: Fri, 16 Feb 2007 11:02:21 -0500 Subject: [coldfire-gnu-discuss] Debugging/Running program in internal Flash. Message-ID: <7.0.1.0.2.20070216110121.022f2ae0@electro-technica.com> Hello Nathan, > > Nathan Sidwell wrote: > > > Looking at the way the PC is behaving I think there's a cache problem. > The Icache has not been flushed and has something stale in it. That > would explain why the pc has landed at 404, which is not an instruction > boundary. > > I'm not sure how that's happened. IIUC you're using the m52235evb config, > right? > That does tell the sprite that there is a cache. The target I use is the M52235EVB. Sprite is launched using the following command: target remote | m68k-elf-sprite pe://USBMultilink m52235evb I suppose that the command line parameter "m52235evb" refer to the file "m52235evb.xml", located in "CodeSourcery\Sourcery G++\m68k-elf\lib\boards\". This file seems to be the configuration file you talk about and seems to include something related to the cache. See below the header of that file: ---------- ---------- > > Here are some suggestions: > > *) Reset or powercycle the board (the sprite should be resetting the > board on first connection though) > > > *) Force a write to RAM from gdb. this will cause the sprite to flush > the Icache. > p/x *(int *)__data_start = 0x1234567 > > then reset the pc to 0x400 as you have been doing, and try again. > It is really strange, the symbol "__data_start" seems to not be the start of the internal SRAM !? Its value is 0xb5b88126 instead 0x20000000 (as defined in the linker script "m52235evb-rom.ld"). GDB can not write at such an address. See the GDB output below: ---------- .. m68k-elf-sprite:Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF Rev C (PE60123 45)) m68k-elf-sprite:Target reset 0x00000000 in __interrupt_vector () (gdb) p/x *(int *)__data_start = 0x1234567 m68k-elf-sprite:Memory write verification failed; config file error? Cannot access memory at address 0xb5b88126 (gdb) print (unsigned int *) __data_start $1 = (unsigned int *) 0xb5b88126 (gdb) ---------- I don't know a lot about GCC linker script file, but something seems to be strange to me. The section that define __data_start in "m52235evb-rom.ld" linker script file is as follow: ---------- .data : { __data_load = LOADADDR (.data); __data_start = .; *(.got.plt) *(.got) *(.shdata) *(.data .data.*) *(.gnu.linkonce.d.*) . = ALIGN (4); _edata = .; } >ram AT>rom ---------- What is the purpose of "AT>rom" ? Maybe the problem is related to that instruction !? Regards, Claude Sylvain Electro-Technica inc. From dan at codesourcery.com Fri Feb 16 16:10:08 2007 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Fri, 16 Feb 2007 11:10:08 -0500 Subject: [coldfire-gnu-discuss] Debugging/Running program in internal Flash. In-Reply-To: <7.0.1.0.2.20070216110121.022f2ae0@electro-technica.com> References: <7.0.1.0.2.20070216110121.022f2ae0@electro-technica.com> Message-ID: <20070216161007.GO29232@caradoc.them.org> On Fri, Feb 16, 2007 at 11:02:21AM -0500, Claude Sylvain wrote: > > *) Force a write to RAM from gdb. this will cause the sprite to flush > > the Icache. > > p/x *(int *)__data_start = 0x1234567 > > > > then reset the pc to 0x400 as you have been doing, and try again. > > > > It is really strange, the symbol "__data_start" seems to not be > the start of the internal SRAM !? > Its value is 0xb5b88126 instead 0x20000000 (as defined in the linker > script "m52235evb-rom.ld"). > > GDB can not write at such an address. There was a typo in Nathan's suggestion; could you try *(int *)&__data_start instead? __data_start is assigned an address at the start of RAM, which is different from pointing to the start of RAM; 0xb5b88126 is probably the first word in SRAM. -- Daniel Jacobowitz CodeSourcery From csylvain at electro-technica.com Fri Feb 16 16:44:40 2007 From: csylvain at electro-technica.com (Claude Sylvain) Date: Fri, 16 Feb 2007 11:44:40 -0500 Subject: [coldfire-gnu-discuss] Debugging/Running program in internal Flash. Message-ID: <7.0.1.0.2.20070216114355.022f0570@electro-technica.com> Hello Daniel, > > Daniel Jacobowitz wrote: > > > > There was a typo in Nathan's suggestion; could you try *(int > *)&__data_start instead? __data_start is assigned an address at > the start of RAM, which is different from pointing to the start > of RAM; 0xb5b88126 is probably the first word in SRAM. > You're right. There is a typo error. I tryed again without the typo error. The problem seems to be still there. Here is the GDB output: ---------- .. m68k-elf-sprite:Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF Rev C (PE60123 45)) m68k-elf-sprite:Target reset 0x00000000 in __interrupt_vector () (gdb) break main Breakpoint 1 at 0x512: file ./src/main.c, line 172. (gdb) print (unsigned int *)&__data_start $1 = (unsigned int *) 0x20000000 (gdb) print *(unsigned int *)&__data_start $2 = 3031990562 (gdb) p/x *(int *)&__data_start = 0x1234567 $3 = 0x1234567 (gdb) print *(unsigned int *)&__data_start $4 = 19088743 (gdb) continue Continuing. Note: automatically using hardware breakpoints for read-only addresses. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000004 in __interrupt_vector () (gdb) stepi 0x00000004 in __interrupt_vector () (gdb) 0x00000004 in __interrupt_vector () (gdb) 0x00000004 in __interrupt_vector () (gdb) p/x *(int *)&__data_start = 0x1234567 $5 = 0x1234567 (gdb) continue Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000004 in __interrupt_vector () (gdb) stepi 0x00000004 in __interrupt_vector () (gdb) 0x00000004 in __interrupt_vector () (gdb) ---------- Regards, Claude Sylvain Electro-Technica inc. From csylvain at electro-technica.com Sat Feb 17 04:14:29 2007 From: csylvain at electro-technica.com (Claude Sylvain) Date: Fri, 16 Feb 2007 23:14:29 -0500 Subject: Debugging a program located in internal FLASH of the M52235 ColdFire MCU. Message-ID: <7.0.1.0.2.20070216231203.02655b98@sympatico.ca> Hello, The last time I tryed to get out of trouble, I forgot to change the PC value (as you recommend me to do). So, I tryed again (without forgetting to change the PC value). Here is the GDB output: ---------- .. m68k-elf-sprite:Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF Rev C (PE60123 45)) m68k-elf-sprite:Target reset 0x00000000 in __interrupt_vector () (gdb) break main Breakpoint 1 at 0x512: file ./src/main.c, line 172. (gdb) p/x $pc = __start $1 = 0x400 (gdb) p/x $pc $2 = 0x400 (gdb) disassemble 0x400 0x420 Dump of assembler code from 0x400 to 0x420: 0x00000400 <__start+0>: moveal #536903680,%sp 0x00000406 <__start+6>: moveal #0,%fp 0x0000040c <__start+12>: movel #0,%d1 0x00000412 <__start+18>: movel %d1,%sp at - 0x00000414 <__start+20>: movel %fp,%sp at - 0x00000416 <__start+22>: jmp 0xc48 <__start1> 0x0000041c <__do_global_dtors_aux+0>: linkw %fp,#0 End of assembler dump. (gdb) p/x *(int *)&__data_start = 0x1234567 $3 = 0x1234567 (gdb) continue Continuing. Note: automatically using hardware breakpoints for read-only addresses. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000404 in __start () (gdb) p/x *(int *)&__data_start = 0x1234567 $4 = 0x1234567 (gdb) continue Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000404 in __start () (gdb) stepi 0x00000404 in __start () (gdb) 0x00000404 in __start () (gdb) 0x00000404 in __start () (gdb) 0x00000404 in __start () (gdb) print *(unsigned int *) &__data_start $5 = 19088743 (gdb) ---------- As you can see, the MCU is still stucked at the middle of an instruction. Claude Sylvain Electro-Technica inc. From csylvain at electro-technica.com Sun Feb 18 06:12:38 2007 From: csylvain at electro-technica.com (Claude Sylvain) Date: Sun, 18 Feb 2007 01:12:38 -0500 Subject: Debugging a program located in internal FLASH of the M52235 ColdFire MCU. Message-ID: <7.0.1.0.2.20070218011120.0266c970@sympatico.ca> Hello Marc, > > Marc Vincent wrote: > > > You need to setup both RAMBAR's before accessing internal SRAM (your > stack push: movel %d1,%sp at -). Try inserting these lines before the > push: > > movel #0x20000201,%d0 > movec %d0,rambar > movel #0x20000200,%d0 > movel %d0,0x40000002 /* SCM RAMBAR */ > > > Note: Maybe the setup script used by the sprite already enables the > internal SRAM in order to load program to it, but you need to do the > above anyway to run without gdb. > > I have not the startup source code. So, I can not make any change/correction to it. Note that "__start" is not the address pointed by the reset vector. The address pointed by the reset vector is "__reset". I voluntarily changed the PC to force the MCU to start from that point ("__start") to avoid an endless loop (at "__reset") in which the MCU stuck. All the problems seems to be in the startup code. First problem: The startup module "cf-unhosted-crt0.o" used by "m52235evb-rom.ld" can not be used in standalone mode (without the debugger) because of an endless loop at "__reset" that enable the debugger to take control of the MCU. Second problem: Even if this startup module is used with the debugger, something hang the MCU at the middle of an instruction !? It seems to me that two solutions are possible: 1) Get the startup source code and try to patch those problems. The startup source code is not included with Sourcery G++ Lite. Is it possible to get it ? 2) Write a startup module from scratch. Regards, Claude Sylvain Electro-Technica inc. From mark at codesourcery.com Sun Feb 18 18:21:36 2007 From: mark at codesourcery.com (Mark Mitchell) Date: Sun, 18 Feb 2007 10:21:36 -0800 Subject: [coldfire-gnu-discuss] Re: Debugging a program located in internal FLASH of the M52235 ColdFire MCU. In-Reply-To: <7.0.1.0.2.20070218011120.0266c970@sympatico.ca> References: <7.0.1.0.2.20070218011120.0266c970@sympatico.ca> Message-ID: <45D89930.6090102@codesourcery.com> Claude Sylvain wrote: > 1) Get the startup source code and try to patch those problems. The > startup source code is not included with Sourcery G++ Lite. > Is it possible to get it ? All of the source code is available in the source package. The crt0 code is also available in m68k-elf/lib/cf-crt0.S of the binary installation, although this file does not include __reset. (This code is not covered by the GPL, so there is no requirement that it be provided at all, but our packaging machinery will automatically include it, as a convenience to users.) Sourcery G++ Lite 4.1-32 does appear to have a defect in the handling of __reset for unhosted mode. Our Personal and Professional edition customers already have this fix; a future Lite edition release will correct it as well. However, even with 4.1-32, you may simply define your own __reset function (in assembly code) and link it into your program. It will take precedence over the version in the library. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From csylvain at electro-technica.com Mon Feb 19 04:38:53 2007 From: csylvain at electro-technica.com (Claude Sylvain) Date: Sun, 18 Feb 2007 23:38:53 -0500 Subject: Debugging a program located in internal FLASH of the M52235 ColdFire MCU. Message-ID: <7.0.1.0.2.20070218233433.02573480@sympatico.ca> Hello Mark, >> >>Claude Sylvain wrote: >> >> >> 1) Get the startup source code and try to patch those problems. The >> startup source code is not included with Sourcery G++ Lite. >> Is it possible to get it ? >> > > Mark Mitchell wrote: > > All of the source code is available in the source package. The crt0 > code is also available in m68k-elf/lib/cf-crt0.S of the binary > installation, although this file does not include __reset. (This code > is not covered by the GPL, so there is no requirement that it be > provided at all, but our packaging machinery will automatically include > it, as a convenience to users.) > > Sourcery G++ Lite 4.1-32 does appear to have a defect in the handling of > __reset for unhosted mode. Our Personal and Professional edition > customers already have this fix; a future Lite edition release will > correct it as well. > > However, even with 4.1-32, you may simply define your own __reset > function (in assembly code) and link it into your program. It will take > precedence over the version in the library. > I wrote my own startup module (crt0_flash.S). In this startup module, I put the "new" code associated with __reset and __start. In the linker script file, I replaced all the reference to the original startup object file (cf-unhosted-crt0.o) by the one I wrote (crt0_flash.o). Sadly, when I build the application, the linker seems to see multiple definition of __reset and __start !? This tell me that __reset and __start are not defined in cf-unhosted-crt0.o module, but elsewhere in another library. This also tell that linker do not handle multiple definition of __reset and __start symbols. Here is the makefile output: ---------- c_mcf52235>make m68k-elf-as -mcpu=52235 --gstabs -al -o ./obj/isv_flash.o \ ./src/isv_flash.S > ./obj/isv_flash.lst m68k-elf-as -mcpu=52235 --gstabs -al -o ./obj/crt0_flash.o \ ./src/crt0_flash.S > ./obj/crt0_flash.lst m68k-elf-gcc -c -I./src -I./src/common -I./src/drivers -mcpu=52235 -T./src/m5223 5evb-flash.ld -g -o ./obj/main.o ./src/main.c m68k-elf-gcc -c -I./src -I./src/common -I./src/drivers -mcpu=52235 -T./src/m5223 5evb-flash.ld -g -o ./obj/common.o \ ./src/common.c m68k-elf-gcc -c -I./src -I./src/common -I./src/drivers -mcpu=52235 -T./src/m5223 5evb-flash.ld -g -o ./obj/uart0.o \ ./src/drivers/uart0.c m68k-elf-gcc -c -I./src -I./src/common -I./src/drivers -mcpu=52235 -T./src/m5223 5evb-flash.ld -g -o ./obj/ach_con.o \ ./src/common/ach_con.c m68k-elf-gcc -I./src -I./src/common -I./src/drivers -mcpu=52235 -T./src/m52235ev b-flash.ld -g -o ./out/basic_mcf52235.elf ./obj/isv_flash.o ./obj/crt0_flash.o . /obj/main.o ./obj/common.o ./obj/uart0.o ./obj/ach_con.o ./obj/crt0_flash.o:./src/crt0_flash.S:50: multiple definition of `__start' ./obj/crt0_flash.o:./src/crt0_flash.S:50: first defined here ./obj/crt0_flash.o:./src/crt0_flash.S:32: multiple definition of `__reset' ./obj/crt0_flash.o:./src/crt0_flash.S:32: first defined here collect2: ld returned 1 exit status make: *** [out/basic_mcf52235] Error 1 C:\Documents and Settings\Claude Sylvain\My Documents\Code\coldfire-gnu\prj\basi c_mcf52235> ---------- So, It seems impossible to make my own startup module. I think, it will be better for me to wait the next release of Sourcery G++, or try to convince my boss to buy a Sourcery G++ licence (not sure I will succeed, since we only evaluate the tool for future project(s)). Thank you Mark for your help. Also, thank you to Marc Vincent for its __reset code example and advices. Claude Sylvain Electro-Technica inc. From mark at codesourcery.com Mon Feb 19 06:12:17 2007 From: mark at codesourcery.com (Mark Mitchell) Date: Sun, 18 Feb 2007 22:12:17 -0800 Subject: [coldfire-gnu-discuss] Re: Re: Re: Debugging a program located in internal FLASH of the M52235 ColdFire MCU. In-Reply-To: <7.0.1.0.2.20070218233433.02573480@sympatico.ca> References: <7.0.1.0.2.20070218233433.02573480@sympatico.ca> Message-ID: <45D93FC1.2010304@codesourcery.com> Claude Sylvain wrote: > Sadly, when I build the application, the linker seems to see multiple > definition of __reset and __start !? You will also have to change the linker script to reference your crt0.o, instead of the default. Find the STARTUP line in the m52235evb-rom.ld script, and point it at your crt0.o file. > I think, it will be better for me to wait the next release of Sourcery > G++, or try to convince my boss to buy a Sourcery G++ licence (not sure > I will succeed, since we only evaluate the tool for future project(s)). There is a free 30-day evaluation, and the Personal Edition is only $399. So, it only has to save a few hours of your time to be a good deal. :-) Thanks, -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From dan at codesourcery.com Mon Feb 19 12:39:54 2007 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Mon, 19 Feb 2007 07:39:54 -0500 Subject: [coldfire-gnu-discuss] Re: Re: Re: Debugging a program located in internal FLASH of the M52235 ColdFire MCU. In-Reply-To: <45D93FC1.2010304@codesourcery.com> References: <7.0.1.0.2.20070218233433.02573480@sympatico.ca> <45D93FC1.2010304@codesourcery.com> Message-ID: <20070219123952.GA29232@caradoc.them.org> On Sun, Feb 18, 2007 at 10:12:17PM -0800, Mark Mitchell wrote: > Claude Sylvain wrote: > > > Sadly, when I build the application, the linker seems to see multiple > > definition of __reset and __start !? > > You will also have to change the linker script to reference your crt0.o, > instead of the default. Find the STARTUP line in the m52235evb-rom.ld > script, and point it at your crt0.o file. Actually, it looks to me as if Claude has both done that and added the file on the linker command line. Try doing one, or the other, but not both. -- Daniel Jacobowitz CodeSourcery From csylvain at electro-technica.com Mon Feb 19 17:01:33 2007 From: csylvain at electro-technica.com (Claude Sylvain) Date: Mon, 19 Feb 2007 12:01:33 -0500 Subject: Debugging a program located in internal FLASH of the M52235 ColdFire MCU. Message-ID: <7.0.1.0.2.20070219115620.0228ee78@electro-technica.com> >> >> Claude Sylvain wrote: >> >>> Sadly, when I build the application, the linker seems to see multiple >>> definition of __reset and __start !? >> >> You will also have to change the linker script to reference your crt0.o, >> instead of the default. Find the STARTUP line in the m52235evb-rom.ld >> script, and point it at your crt0.o file. >> > > Daniel Jacobowitz wrote: > > Actually, it looks to me as if Claude has both done that and added the > file on the linker command line. Try doing one, or the other, but not both. > Daniel, You're absolutely right. crt0_flash module is now handled in the make file. So, it must not appear in the linker script. I commented out the folowing linker script line: "STARTUP(./obj/crt0_flash.o)", and now, I can build the application. Thank you, Claude Sylvain Electro-Technica inc. From daniel.mclean at optusnet.com.au Wed Feb 28 02:13:23 2007 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Wed, 28 Feb 2007 12:13:23 +1000 Subject: M52235EVB - Problem using malloc - Access Error Attempted Write to Write-Protected Space Message-ID: <200702280213.l1S2DgGO014895@mail24.syd.optusnet.com.au> Hi, I'm having some troubles using malloc (or more specifically malloc_r).. I'm running from the internal flash and in unhosted mode. I'm using my own startup code and interrupt vectors and am happy that everything seems to be running ok (I can flash the LEDs on the development kit, read the switches, print text to the serial port, etc). I've just added the first lot of code that makes use of malloc. I've provided an implementation of sbrk so that it can request sections of memory. However it seems that malloc attempts to access write protected space and causes an interrupt. This is displayed via a printf on the serial port. It says that the program counter is at 0x000040CA when this occurs.. Below is the appropriate section of my map file: .text 0x00003f6c 0x32 c:\program files\codesourcery\sourcery g++\bin\../m68k-elf/lib\libc.a(malloc.o) 0x00003f86 malloc 0x00003f6c free *fill* 0x00003f9e 0x2 00 .text 0x00003fa0 0x76e c:\program files\codesourcery\sourcery g++\bin\../m68k-elf/lib\libc.a(mallocr.o) 0x00003fa0 _malloc_r *fill* 0x0000470e 0x2 00 I am using a (very slightly) modified version of the linker control file provided: m52235evb-rom.ld The only modifications I've made to this are associated with using my own vector table and startup code (all based on the sample code from the Freescale site). Any suggestions would be appreciated. I'd also be interested in knowing what compiler options the newlib libraries were compiled with? I am assuming that they are at least compiled with re-entrancy support considering the inclusion of files such as _malloc_r by the linker. Thanks Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at codesourcery.com Wed Feb 28 13:35:48 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 28 Feb 2007 13:35:48 +0000 Subject: [coldfire-gnu-discuss] M52235EVB - Problem using malloc - Access Error Attempted Write to Write-Protected Space In-Reply-To: <200702280213.l1S2DgGO014895@mail24.syd.optusnet.com.au> References: <200702280213.l1S2DgGO014895@mail24.syd.optusnet.com.au> Message-ID: <45E58534.7020608@codesourcery.com> Daniel McLean wrote: > the first lot of code that makes use of malloc. I?ve provided an > implementation of sbrk so that it can request sections of memory. > However it seems that malloc attempts to access write protected space > and causes an interrupt. This is displayed via a printf on the serial > port. It says that the program counter is at 0x000040CA when this > occurs.. Below is the appropriate section of my map file: > Any suggestions would be appreciated? unfortunately, without an actual test case it's not possible to determine what is happening. Have you verified your sbrk is returning the values you expect it to? > I?d also be interested in knowing what compiler options the newlib > libraries were compiled with? I am assuming that they are at least > compiled with re-entrancy support considering the inclusion of files > such as _/malloc/_r by the linker? Newlib is compiled with -O2 -mcpu=FOO for appropriate FOO values. You're correct that newlib is configured to be reentrant. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From daniel.mclean at optusnet.com.au Wed Feb 28 13:53:54 2007 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Wed, 28 Feb 2007 23:53:54 +1000 Subject: [coldfire-gnu-discuss] M52235EVB - Problem using malloc - Access Error Attempted Write to Write-Protected Space In-Reply-To: <45E58534.7020608@codesourcery.com> Message-ID: <200702281354.l1SDs1w5018519@mail33.syd.optusnet.com.au> Thanks for the quick response Nathan.. What test would you like in terms of a test case? Currently my start and end of RAM pointers (as exported from the linker control file) are ok. The start pointer is at about 0x2000418 (which seems about right). What looks to be going on is that my sbrk routine is not called. I've got printf statements in it, and never see any console output. I am just trying to malloc a small amount of memory (5 bytes) as a test. Here's the snippet of code in my main function: int main(void) { extern char _end[]; void *temp; mcf5223_unmask_all_interrupts(); mcf5xxx_irq_enable(); printD("End of used RAM is 0x%0X \n", _end); temp = malloc(5); printD("Malloced data is 0x%0X \n", temp); .... I get two access write attempt interrupts when the program counter is inside malloc_r My sbrk routine is: void *sbrk(ptrdiff_t nbytes) { char *base; printD("SBRK end is 0x%0X \n", _end); if (heap_ptr == NULL) { heap_ptr = (char *)&_end; } printD("Heap pointer is 0x%0X \n", heap_ptr); base = heap_ptr; heap_ptr += nbytes; printD("Heap pointer now 0x%0X \n", heap_ptr); return base; } I've also tried linking against the coldfire library that is in the codesourcery tree and this makes no difference, which is why I am suspicious of the malloc_r.. I'm wondering if I haven't done anything that would mean that malloc_r is trying to write into flash, although as I said before I am using the same linker control file as the one supplied... Any further ideas? -----Original Message----- From: Nathan Sidwell [mailto:nathan at codesourcery.com] Sent: Wednesday, 28 February 2007 11:36 PM To: Daniel McLean Cc: coldfire-gnu-discuss at codesourcery.com Subject: Re: [coldfire-gnu-discuss] M52235EVB - Problem using malloc - Access Error Attempted Write to Write-Protected Space Daniel McLean wrote: > the first lot of code that makes use of malloc. I've provided an > implementation of sbrk so that it can request sections of memory. > However it seems that malloc attempts to access write protected space > and causes an interrupt. This is displayed via a printf on the serial > port. It says that the program counter is at 0x000040CA when this > occurs.. Below is the appropriate section of my map file: > Any suggestions would be appreciated. unfortunately, without an actual test case it's not possible to determine what is happening. Have you verified your sbrk is returning the values you expect it to? > I'd also be interested in knowing what compiler options the newlib > libraries were compiled with? I am assuming that they are at least > compiled with re-entrancy support considering the inclusion of files > such as _/malloc/_r by the linker. Newlib is compiled with -O2 -mcpu=FOO for appropriate FOO values. You're correct that newlib is configured to be reentrant. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.4/705 - Release Date: 27/02/2007 3:24 PM