From codesourcery at mymail.mattcohn.com Mon Sep 1 22:30:45 2008 From: codesourcery at mymail.mattcohn.com (Matt Cohn) Date: Mon, 1 Sep 2008 15:30:45 -0700 Subject: m68k-elf-sprite 4.2-125 crashing Message-ID: Hia, I am debugging a M52233DEMO board using the P&E USB BDM. I connect to it via m68k-elf-sprite. I turned on the verbose console and put the sprite in verbose mode, and here's the problem I'm experiencing. Usually debugging will work fine for a while. I will be able to continue, suspend, step, break, and continue again without problems. After leaving the program running for a while (a couple minutes) or doing a lot of stepping (anywhere, not in one particular place) I will experience the following. If the code was running and I try to do a suspend, m68k-elf-sprite uses a lot of CPU and doesn't respond. Eventually GDB times out with "Target request failed: Failed to interrupt". During this there is no response on the console. If I was stepping through the code when the problem happened, I will see the following on the console: m68k-elf-sprite: Step at 0x0 m68k-elf-sprite: error: Lost connection to hardware device m68k-elf-sprite: Sent response: 'E.fatal.Lost connection to hardware device' Error from remote target: Lost connection to hardware device I should also note that occasionally (about 1/5th of the time) when programming my board using CF Flasher, it will hang, timeout, fail validation and need to be flashed again. Flashing again works fine. I have tried disconnecting all of my USB devices, using a different USB port, and killing all background processes and services to no avail. Any advice is sincerely appreciated. Thank you very much, --Matt From nathan at codesourcery.com Tue Sep 2 08:25:54 2008 From: nathan at codesourcery.com (Nathan Sidwell) Date: Tue, 02 Sep 2008 09:25:54 +0100 Subject: [coldfire-gnu-discuss] m68k-elf-sprite 4.2-125 crashing In-Reply-To: References: Message-ID: <48BCF892.2040401@codesourcery.com> Matt Cohn wrote: > Hia, > > I am debugging a M52233DEMO board using the P&E USB BDM. I connect to it via m68k-elf-sprite. I turned on the verbose console and put the sprite in verbose mode, and here's the problem I'm experiencing. > > Usually debugging will work fine for a while. I will be able to continue, suspend, step, break, and continue again without problems. After leaving the program running for a while (a couple minutes) or doing a lot of stepping (anywhere, not in one particular place) I will experience the following. > > If the code was running and I try to do a suspend, m68k-elf-sprite uses a lot of CPU and doesn't respond. Eventually GDB times out with "Target request failed: Failed to interrupt". During this there is no response on the console. > I should also note that occasionally (about 1/5th of the time) when programming my board using CF Flasher, it will hang, timeout, fail validation and need to be flashed again. Flashing again works fine. I have tried disconnecting all of my USB devices, using a different USB port, and killing all background processes and services to no avail. Any advice is sincerely appreciated. This sounds very much like a hardware problem, because you're getting it from two independent software tools. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery From David.Seymour at freescale.com Tue Sep 2 14:25:48 2008 From: David.Seymour at freescale.com (Seymour David-RA2693) Date: Tue, 2 Sep 2008 07:25:48 -0700 Subject: [coldfire-gnu-discuss] m68k-elf-sprite 4.2-125 crashing In-Reply-To: <48BCF892.2040401@codesourcery.com> References: <48BCF892.2040401@codesourcery.com> Message-ID: We've been having issues with the version of P&E USB BDM firmware. You might register on www.pemicro.com and download the latest BDM test utility and firmware to see if that helps. Regards, David David E Seymour http://www.freescale.com/coldfire -----Original Message----- From: Nathan Sidwell [mailto:nathan at codesourcery.com] Sent: Tuesday, September 02, 2008 3:26 AM To: Matt Cohn Cc: coldfire-gnu-discuss at codesourcery.com Subject: Re: [coldfire-gnu-discuss] m68k-elf-sprite 4.2-125 crashing Matt Cohn wrote: > Hia, > > I am debugging a M52233DEMO board using the P&E USB BDM. I connect to it via m68k-elf-sprite. I turned on the verbose console and put the sprite in verbose mode, and here's the problem I'm experiencing. > > Usually debugging will work fine for a while. I will be able to continue, suspend, step, break, and continue again without problems. After leaving the program running for a while (a couple minutes) or doing a lot of stepping (anywhere, not in one particular place) I will experience the following. > > If the code was running and I try to do a suspend, m68k-elf-sprite uses a lot of CPU and doesn't respond. Eventually GDB times out with "Target request failed: Failed to interrupt". During this there is no response on the console. > I should also note that occasionally (about 1/5th of the time) when programming my board using CF Flasher, it will hang, timeout, fail validation and need to be flashed again. Flashing again works fine. I have tried disconnecting all of my USB devices, using a different USB port, and killing all background processes and services to no avail. Any advice is sincerely appreciated. This sounds very much like a hardware problem, because you're getting it from two independent software tools. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery From mattcohn at mattcohn.com Mon Sep 1 20:11:08 2008 From: mattcohn at mattcohn.com (Matt Cohn) Date: Mon, 1 Sep 2008 13:11:08 -0700 Subject: m68k-elf-sprite 4.2-125 crashing - Message-ID: <000301c90c6e$e1fdc3d0$a5f94b70$@com> Hia, I am debugging a M52233DEMO board using the P&E USB BDM. I connect to it via m68k-elf-sprite. I turned on the verbose console and put the sprite in verbose mode, and here's the problem I'm experiencing. Usually debugging will work fine for a while. I will be able to continue, suspend, step, break, and continue again without problems. After leaving the program running for a while (a couple minutes) or doing a lot of stepping (anywhere, not in one particular place) I will experience the following. If the code was running and I try to do a suspend, m68k-elf-sprite uses a lot of CPU and doesn't respond. Eventually GDB times out with "Target request failed: Failed to interrupt". During this there is no response on the console. If I was stepping through the code when the problem happened, I will see the following on the console: m68k-elf-sprite: Step at 0x0 m68k-elf-sprite: error: Lost connection to hardware device m68k-elf-sprite: Sent response: 'E.fatal.Lost connection to hardware device' Error from remote target: Lost connection to hardware device I should also note that occasionally (about 1/5th of the time) when programming my board using CF Flasher, it will hang, timeout, fail validation and need to be flashed again. Flashing again works fine. I have tried disconnecting all of my USB devices, using a different USB port, and killing all background processes and services to no avail. Any advice is sincerely appreciated. Thank you very much, --Matt From Corrin.Meyer at dornerworks.com Wed Sep 3 18:27:45 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Wed, 3 Sep 2008 14:27:45 -0400 Subject: C Stack Initialization Message-ID: Is there an easy way using CS3 to have the stack initialized to a predefined bit pattern? By the time main is executed the stack area has already been used to some degree so starting at __cs3_stack would likely cause problems. I suppose I can try to determine the current stack pointer once I enter main() by grabbing it from the register or something similar but the stack should really be fully initialized prior to entering main. 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 Thu Sep 4 10:44:39 2008 From: nathan at codesourcery.com (Nathan Sidwell) Date: Thu, 04 Sep 2008 11:44:39 +0100 Subject: [coldfire-gnu-discuss] C Stack Initialization In-Reply-To: References: Message-ID: <48BFBC17.1080708@codesourcery.com> Corrin Meyer wrote: > Is there an easy way using CS3 to have the stack initialized to a > predefined bit pattern? By the time main is executed the stack area has > already been used to some degree so starting at __cs3_stack would likely > cause problems. I suppose I can try to determine the current stack > pointer once I enter main() by grabbing it from the register or > something similar but the stack should really be fully initialized prior > to entering main. What do you mean by initialize the stack? Do you want a memory contents on the stack? Where exactly on the stack? What are you trying to do? nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery From Corrin.Meyer at dornerworks.com Thu Sep 4 12:15:10 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Thu, 4 Sep 2008 08:15:10 -0400 Subject: [coldfire-gnu-discuss] C Stack Initialization In-Reply-To: <48BFBC17.1080708@codesourcery.com> References: <48BFBC17.1080708@codesourcery.com> Message-ID: Nathan Sidwell wrote: >> Is there an easy way using CS3 to have the stack initialized to a >> predefined bit pattern? By the time main is executed the stack area has >> already been used to some degree so starting at __cs3_stack would likely >> cause problems. I suppose I can try to determine the current stack >> pointer once I enter main() by grabbing it from the register or >> something similar but the stack should really be fully initialized prior >> to entering main. > >What do you mean by initialize the stack? Do you want a memory contents on >the >stack? Where exactly on the stack? What are you trying to do? I want to have the stack contain a known bit sequence so that I can periodically check the entire stack to see how much of it has been used (or at least a reasonable idea) in order to determine what my stack usage is like (have I run out of stack space, am I low on stack space, do I have a lot more than I need, etc). Corrin Meyer From codesourcery at mymail.mattcohn.com Fri Sep 5 00:32:57 2008 From: codesourcery at mymail.mattcohn.com (Matt Cohn) Date: Thu, 4 Sep 2008 17:32:57 -0700 Subject: [coldfire-gnu-discuss] m68k-elf-sprite 4.2-125 crashing Message-ID: Thank you, I'm running the GNU tools via cygwin on Windows XP for clarification. I found and used USBDeview.exe to uninstall my USB drivers to be reinstalled - they reinstalled fine but it did not alleviate the problem. I don't have testcfz.exe, it wasn't on the CD that came with the M52233DEMO, and I wasn't able to find it anywhere on pemicro.com. Do you know where I can find a copy? Also I connected an external power supply and that had no effect. What's so frustrating about this problem is I can't find any evidence of anyone else having anything similar! Most of the time when leaving code executing for a couple minutes I'm simply unable to suspend again. If I'm stepping through, invariably after so many steps (anywhere from 5 to 50) I recieve one of: m68k-elf-sprite: error: Lost connection to hardware device Error from remote target: Lost connection to hardware device --or-- m68k-elf-sprite: error: Lost connection to hardware device m68k-elf-sprite: Not closing port because of lost connection Remote communication error: No error. --or-- nothing on the console and m68k-elf-sprite will simply consume lots of CPU while eclipse does nothing, the step buttons grayed out, pressing halt or suspend grays out the corrosponding button. I additionally installed XP SP3 as well as a few other Windows updates, disabled as many startup programs as I could bare to be without, updated Zylin Embedded Debug to its latest version, and tried using "GDB Hardware Debugging" instead of "Zylin Embedded debug" today with no effect. Any ideas or things to try are sincerely appreciated - thank you! --Matt > Just to test the BDM interface I have a utility (PC/Windows based) call > Testcfz.exe. With the M52233DEMO connect to PC via the USB cable, it > will find the ColdFire device and run a simple test and report PASS or > FAILURE. > I've seen weird things if the PC USB port doesn't supply the 500mA. You > might try using external power supply to rule that out. > Does your issue happen when not using verbose mode? > I haven't sparked up my Linux box with CodeSourcery tools for awhile. > I'll try to find some time to do that. > I have used a utility called "USBDeview.exe" (again PC/Windows based) to > remove/uninstall the USB drivers so that I can start fresh and new. > Regards, > David > > > David E Seymour > > http://www.freescale.com/coldfire > > > -----Original Message----- > From: Matt Cohn [mailto:codesourcery at mymail.mattcohn.com] > Sent: Thursday, September 04, 2008 2:18 PM > To: Seymour David-RA2693 > Subject: RE: [coldfire-gnu-discuss] m68k-elf-sprite 4.2-125 crashing > > Thanks David, I gave it a shot, but I wasn't able to locate updated > firmware you mentioned. From here: > http://www.pemicro.com/support/download_processor.cfm the only relevent > updates I found were to the hardware interface drivers (which I updated > just to be sure). > > The M52233DEMO board lists its onboard BDM as equivalent to USB-ML-CF, > here: > http://www.pemicro.com/products/product_viewDetails.cfm?product_id=163&C > FID=1912140&CFTOKEN=57896256 > whose downloads section doesn't list any updated firmware. > > Do you have any further ideas or things for me to try? > > Thank you, > --Matt > > > > We've been having issues with the version of P&E USB BDM firmware. > > You might register on www.pemicro.com and download the latest BDM test > > > utility and firmware to see if that helps. > > Regards, > > David > > > > > > David E Seymour > > > > http://www.freescale.com/coldfire > > > > > > -----Original Message----- > > From: Nathan Sidwell [mailto:nathan at codesourcery.com] > > Sent: Tuesday, September 02, 2008 3:26 AM > > To: Matt Cohn > > Cc: coldfire-gnu-discuss at codesourcery.com > > Subject: Re: [coldfire-gnu-discuss] m68k-elf-sprite 4.2-125 crashing > > > > Matt Cohn wrote: > > > Hia, > > > > > > I am debugging a M52233DEMO board using the P&E USB BDM. I connect > > > to > > it via m68k-elf-sprite. I turned on the verbose console and put the > > sprite in verbose mode, and here's the problem I'm experiencing. > > > > > > Usually debugging will work fine for a while. I will be able to > > continue, suspend, step, break, and continue again without problems. > > After leaving the program running for a while (a couple minutes) or > > doing a lot of stepping (anywhere, not in one particular place) I will > > > experience the following. > > > > > > If the code was running and I try to do a suspend, m68k-elf-sprite > > uses a lot of CPU and doesn't respond. Eventually GDB times out with > > "Target request failed: Failed to interrupt". During this there is no > > > response on the console. > > > > > I should also note that occasionally (about 1/5th of the time) when > > programming my board using CF Flasher, it will hang, timeout, fail > > validation and need to be flashed again. Flashing again works fine. > > I have tried disconnecting all of my USB devices, using a different > > USB port, and killing all background processes and services to no > avail. > > Any advice is sincerely appreciated. > > > > This sounds very much like a hardware problem, because you're getting > > it from two independent software tools. > > > > nathan > > > > -- > > Nathan Sidwell :: http://www.codesourcery.com :: > > CodeSourcery > > > From Corrin.Meyer at dornerworks.com Fri Sep 5 20:20:08 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Fri, 5 Sep 2008 16:20:08 -0400 Subject: Debugging from flash Message-ID: I am using the P&E Micro flash utility (CPROGCFZ) to flash the ColdFire on the board I am working on. I would like to be able to debug the running program using GDB. The problem is that the error I am getting is right at boot and since the USB device can't be claimed by both the P&E Micro utility and the m68k-elf-sprite at the same time I have to first flash it and then connect GDB to it but by that time it has already run into the error. I need to be able to tell the program to restart. Normally I would just do a 'load' command within GDB but that will only work when running from RAM. Is there anyway to restart a program that is already running in flash? I can't do a reset as then breakpoint set by GDB is cleared, it needs to be a software reset issued by GDB. 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 dan at codesourcery.com Fri Sep 5 21:33:26 2008 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Fri, 5 Sep 2008 17:33:26 -0400 Subject: [coldfire-gnu-discuss] Debugging from flash In-Reply-To: References: Message-ID: <20080905213323.GX6268@caradoc.them.org> On Fri, Sep 05, 2008 at 04:20:08PM -0400, Corrin Meyer wrote: > I am using the P&E Micro flash utility (CPROGCFZ) to flash the ColdFire > on the board I am working on. I would like to be able to debug the > running program using GDB. The problem is that the error I am getting > is right at boot and since the USB device can't be claimed by both the > P&E Micro utility and the m68k-elf-sprite at the same time I have to > first flash it and then connect GDB to it but by that time it has > already run into the error. > > > > I need to be able to tell the program to restart. Normally I would just > do a 'load' command within GDB but that will only work when running from > RAM. Is there anyway to restart a program that is already running in > flash? I can't do a reset as then breakpoint set by GDB is cleared, it > needs to be a software reset issued by GDB. When you start the sprite, unless you tell it not to, it resets the board. So your program should be back at the reset vector when you connect from GDB. Is that not happening? ["load" works fine and programs flash if you have a non-Lite SG++, by the way :-)] -- Daniel Jacobowitz CodeSourcery From codesourcery at mymail.mattcohn.com Sat Sep 6 20:41:32 2008 From: codesourcery at mymail.mattcohn.com (Matt Cohn) Date: Sat, 6 Sep 2008 13:41:32 -0700 Subject: [coldfire-gnu-discuss] m68k-elf-sprite 4.2-125 crashing Message-ID: Hi David, I gave the tool a try, I had five sucesses before a failure, the last item to appear on the log in the failure was "Filling memory from location $10000100 to $1000011F". Unfourtunatley that still leaves either my computer's USB to blame (although I have used multiple ports on separate controllers) or the BDM on the board itself, but it does confirm that the problem is not with GDB or the GNU/codesourcery toolchain. I would love to try on my laptop to narrow it down, however I've been unable to get my Vista laptop to recognize the USB Multilink. After installing the drivers, uninstalling, reinstalling, although USBDeview shows the board connected, various tools are all unable to see the USB Multilink. I suppose I will continue to use it as-is until later this month when I'm back in school. My professor has the same board, so I can find out exactly what's to blame. Thank you for all your help, --Matt > Hi Matt, > I'm assuming you are registered on the P&E web site. Correct? > If so, click on the following > - Support > - FAQs > - Enter FAQ# 103 > > You should have a "Related Downloads" that has "Test_cfz" link. > > I just updated my driver and need to reboot...hoping all goes well. > Regards, > David > > > David E Seymour > > http://www.freescale.com/coldfire > > > -----Original Message----- > From: Matt Cohn [mailto:codesourcery at mymail.mattcohn.com] > Sent: Thursday, September 04, 2008 7:33 PM > To: coldfire-gnu-discuss at codesourcery.com > Subject: RE: [coldfire-gnu-discuss] m68k-elf-sprite 4.2-125 crashing > > Thank you, I'm running the GNU tools via cygwin on Windows XP for > clarification. I found and used USBDeview.exe to uninstall my USB > drivers to be reinstalled - they reinstalled fine but it did not > alleviate the problem. I don't have testcfz.exe, it wasn't on the CD > that came with the M52233DEMO, and I wasn't able to find it anywhere on > pemicro.com. Do you know where I can find a copy? Also I connected an > external power supply and that had no effect. > > What's so frustrating about this problem is I can't find any evidence of > anyone else having anything similar! Most of the time when leaving code > executing for a couple minutes I'm simply unable to suspend again. If > I'm stepping through, invariably after so many steps (anywhere from 5 to > 50) I recieve one of: > > m68k-elf-sprite: error: Lost connection to hardware device Error from > remote target: Lost connection to hardware device > > --or-- > > > m68k-elf-sprite: error: Lost connection to hardware device > m68k-elf-sprite: Not closing port because of lost connection Remote > communication error: No error. > > --or-- > > nothing on the console and m68k-elf-sprite will simply consume lots of > CPU while eclipse does nothing, the step buttons grayed out, pressing > halt or suspend grays out the corrosponding button. > > I additionally installed XP SP3 as well as a few other Windows updates, > disabled as many startup programs as I could bare to be without, updated > Zylin Embedded Debug to its latest version, and tried using "GDB > Hardware Debugging" instead of "Zylin Embedded debug" today with no > effect. > > Any ideas or things to try are sincerely appreciated - thank you! > > --Matt > > > > > Just to test the BDM interface I have a utility (PC/Windows based) > > call Testcfz.exe. With the M52233DEMO connect to PC via the USB > > cable, it will find the ColdFire device and run a simple test and > > report PASS or FAILURE. > > I've seen weird things if the PC USB port doesn't supply the 500mA. > > You might try using external power supply to rule that out. > > Does your issue happen when not using verbose mode? > > I haven't sparked up my Linux box with CodeSourcery tools for awhile. > > I'll try to find some time to do that. > > I have used a utility called "USBDeview.exe" (again PC/Windows based) > > to remove/uninstall the USB drivers so that I can start fresh and new.. > > Regards, > > David > > > > > > David E Seymour > > > > http://www.freescale.com/coldfire > > > > > > -----Original Message----- > > From: Matt Cohn [mailto:codesourcery at mymail.mattcohn.com] > > Sent: Thursday, September 04, 2008 2:18 PM > > To: Seymour David-RA2693 > > Subject: RE: [coldfire-gnu-discuss] m68k-elf-sprite 4.2-125 crashing > > > > Thanks David, I gave it a shot, but I wasn't able to locate updated > > firmware you mentioned. From here: > > http://www.pemicro.com/support/download_processor.cfm the only > > relevent updates I found were to the hardware interface drivers (which > > > I updated just to be sure). > > > > The M52233DEMO board lists its onboard BDM as equivalent to USB-ML-CF, > > here: > > http://www.pemicro.com/products/product_viewDetails.cfm?product_id=163 > > &C > > FID=1912140&CFTOKEN=57896256 > > whose downloads section doesn't list any updated firmware. > > > > Do you have any further ideas or things for me to try? > > > > Thank you, > > --Matt > > > > > > > We've been having issues with the version of P&E USB BDM firmware. > > > You might register on www.pemicro.com and download the latest BDM > > > test > > > > > utility and firmware to see if that helps. > > > Regards, > > > David > > > > > > > > > David E Seymour > > > > > > http://www.freescale.com/coldfire > > > > > > > > > -----Original Message----- > > > From: Nathan Sidwell [mailto:nathan at codesourcery.com] > > > Sent: Tuesday, September 02, 2008 3:26 AM > > > To: Matt Cohn > > > Cc: coldfire-gnu-discuss at codesourcery.com > > > Subject: Re: [coldfire-gnu-discuss] m68k-elf-sprite 4.2-125 crashing > > > > > > Matt Cohn wrote: > > > > Hia, > > > > > > > > I am debugging a M52233DEMO board using the P&E USB BDM. I > > > > connect to > > > it via m68k-elf-sprite. I turned on the verbose console and put the > > > > sprite in verbose mode, and here's the problem I'm experiencing. > > > > > > > > Usually debugging will work fine for a while. I will be able to > > > continue, suspend, step, break, and continue again without problems.. > > > After leaving the program running for a while (a couple minutes) or > > > doing a lot of stepping (anywhere, not in one particular place) I > > > will > > > > > experience the following. > > > > > > > > If the code was running and I try to do a suspend, m68k-elf-sprite > > > uses a lot of CPU and doesn't respond. Eventually GDB times out > > > with "Target request failed: Failed to interrupt". During this > > > there is no > > > > > response on the console. > > > > > > > I should also note that occasionally (about 1/5th of the time) > > > > when > > > programming my board using CF Flasher, it will hang, timeout, fail > > > validation and need to be flashed again. Flashing again works fine.. > > > I have tried disconnecting all of my USB devices, using a different > > > USB port, and killing all background processes and services to no > > avail. > > > Any advice is sincerely appreciated. > > > > > > This sounds very much like a hardware problem, because you're > > > getting it from two independent software tools. > > > > > > nathan > > > > > > -- > > > Nathan Sidwell :: http://www.codesourcery.com :: > > > CodeSourcery > > > > > > From Corrin.Meyer at dornerworks.com Mon Sep 8 13:04:09 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Mon, 8 Sep 2008 09:04:09 -0400 Subject: [coldfire-gnu-discuss] Debugging from flash In-Reply-To: <20080905213323.GX6268@caradoc.them.org> References: <20080905213323.GX6268@caradoc.them.org> Message-ID: I am not really sure what is happening now... Following is what I am getting. ... (gdb) target remote | m68k-elf-sprite pe: m52235evb m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF REF : M52235DEMO (PE60)) m68k-elf-sprite: Target reset 0x00000000 in __cs3_interrupt_vector_coldfire() (gdb) b __cs3_reset Breakpoint 1 at 0x400 (gdb) c Continuing Note: automatically using hardware breakpoints for read-only addresses. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000f62 in __cs3_isr_illegal_instruction () (gdb) >> I am using the P&E Micro flash utility (CPROGCFZ) to flash the ColdFire >> on the board I am working on. I would like to be able to debug the >> running program using GDB. The problem is that the error I am getting >> is right at boot and since the USB device can't be claimed by both the >> P&E Micro utility and the m68k-elf-sprite at the same time I have to >> first flash it and then connect GDB to it but by that time it has >> already run into the error. >> >> >> >> I need to be able to tell the program to restart. Normally I would just >> do a 'load' command within GDB but that will only work when running from >> RAM. Is there anyway to restart a program that is already running in >> flash? I can't do a reset as then breakpoint set by GDB is cleared, it >> needs to be a software reset issued by GDB. > >When you start the sprite, unless you tell it not to, it resets the >board. So your program should be back at the reset vector when you >connect from GDB. Is that not happening? > >["load" works fine and programs flash if you have a non-Lite SG++, by >the way :-)] > >-- >Daniel Jacobowitz >CodeSourcery From Corrin.Meyer at dornerworks.com Mon Sep 8 13:21:09 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Mon, 8 Sep 2008 09:21:09 -0400 Subject: [coldfire-gnu-discuss] Debugging from flash In-Reply-To: References: <20080905213323.GX6268@caradoc.them.org> Message-ID: Here is another wrinkle... I have a very small test application (basically a 'hello world'). I compile it and then use the P&E Micro tool flash it. Once the board reboots the application runs as expected. I then connect to it using GDB: (gdb) target remote | m68k-elf-sprite pe: m52235evb Remote debugging using | m6k-elf-sprite pe: m52235evb m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF REF : M52235DEMO (PE60)) m68k-elf-sprite: Target reset 0x00000000 in __cs3_interrupt_vector_coldfire () (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000e12 in __cs3_isr_illegal_instruction () (gdb) I would expect that after issuing the continue command that the program should execute just as if the board had been booted. Am I missing something? Corrin Meyer > -----Original Message----- > From: Corrin Meyer [mailto:Corrin.Meyer at dornerworks.com] > Sent: Monday, September 08, 2008 9:04 AM > To: coldfire-gnu-discuss at codesourcery.com > Subject: RE: [coldfire-gnu-discuss] Debugging from flash > > I am not really sure what is happening now... Following is what I am > getting. > > ... > (gdb) target remote | m68k-elf-sprite pe: m52235evb > m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF REF : > M52235DEMO (PE60)) > m68k-elf-sprite: Target reset > 0x00000000 in __cs3_interrupt_vector_coldfire() > (gdb) b __cs3_reset > Breakpoint 1 at 0x400 > (gdb) c > Continuing > Note: automatically using hardware breakpoints for read-only addresses. > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00000f62 in __cs3_isr_illegal_instruction () > (gdb) > > >> I am using the P&E Micro flash utility (CPROGCFZ) to flash the > ColdFire > >> on the board I am working on. I would like to be able to debug the > >> running program using GDB. The problem is that the error I am > getting > >> is right at boot and since the USB device can't be claimed by both > the > >> P&E Micro utility and the m68k-elf-sprite at the same time I have to > >> first flash it and then connect GDB to it but by that time it has > >> already run into the error. > >> > >> > >> > >> I need to be able to tell the program to restart. Normally I would > just > >> do a 'load' command within GDB but that will only work when running > from > >> RAM. Is there anyway to restart a program that is already running in > >> flash? I can't do a reset as then breakpoint set by GDB is cleared, > it > >> needs to be a software reset issued by GDB. > > > >When you start the sprite, unless you tell it not to, it resets the > >board. So your program should be back at the reset vector when you > >connect from GDB. Is that not happening? > > > >["load" works fine and programs flash if you have a non-Lite SG++, by > >the way :-)] > > > >-- > >Daniel Jacobowitz > >CodeSourcery From dan at codesourcery.com Mon Sep 8 13:42:23 2008 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Mon, 8 Sep 2008 09:42:23 -0400 Subject: [coldfire-gnu-discuss] Debugging from flash In-Reply-To: References: <20080905213323.GX6268@caradoc.them.org> Message-ID: <20080908134221.GE6268@caradoc.them.org> On Mon, Sep 08, 2008 at 09:21:09AM -0400, Corrin Meyer wrote: > (gdb) target remote | m68k-elf-sprite pe: m52235evb Just checking, is your board actually an M52235EVB or is it something similar but slightly different? > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00000e12 in __cs3_isr_illegal_instruction () > (gdb) At this point, I'd suggest you check the exception frame on the stack to see what instruction was illegal. > I would expect that after issuing the continue command that the program > should execute just as if the board had been booted. Am I missing > something? Almost the same. The only difference is that the initialization sequence in the board file is executed first; this is to support programs run from RAM, which may require the memory controller to be initialized first. But in general the initialization sequence does not cause a problem if executed twice. -- Daniel Jacobowitz CodeSourcery From Corrin.Meyer at dornerworks.com Mon Sep 8 14:41:31 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Mon, 8 Sep 2008 10:41:31 -0400 Subject: [coldfire-gnu-discuss] Debugging from flash In-Reply-To: <20080908134221.GE6268@caradoc.them.org> References: <20080905213323.GX6268@caradoc.them.org> <20080908134221.GE6268@caradoc.them.org> Message-ID: It actually is not a M52235EVB but the ColdFire is configured like a M52235EVB. I have been able to successfully run and debug applications from RAM. It is just once I go to Flash that I am getting this problem. Corrin Meyer > -----Original Message----- > From: Daniel Jacobowitz [mailto:dan at codesourcery.com] > Sent: Monday, September 08, 2008 9:42 AM > To: Corrin Meyer > Cc: coldfire-gnu-discuss at codesourcery.com > Subject: Re: [coldfire-gnu-discuss] Debugging from flash > > On Mon, Sep 08, 2008 at 09:21:09AM -0400, Corrin Meyer wrote: > > (gdb) target remote | m68k-elf-sprite pe: m52235evb > > Just checking, is your board actually an M52235EVB or is it something > similar but slightly different? > > > Program received signal SIGTRAP, Trace/breakpoint trap. > > 0x00000e12 in __cs3_isr_illegal_instruction () > > (gdb) > > At this point, I'd suggest you check the exception frame on the stack > to see what instruction was illegal. > > > I would expect that after issuing the continue command that the program > > should execute just as if the board had been booted. Am I missing > > something? > > Almost the same. The only difference is that the initialization > sequence in the board file is executed first; this is to support > programs run from RAM, which may require the memory controller > to be initialized first. But in general the initialization sequence > does not cause a problem if executed twice. > > -- > Daniel Jacobowitz > CodeSourcery From Corrin.Meyer at dornerworks.com Mon Sep 8 21:24:40 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Mon, 8 Sep 2008 17:24:40 -0400 Subject: [coldfire-gnu-discuss] Debugging from flash In-Reply-To: References: <20080905213323.GX6268@caradoc.them.org> <20080908134221.GE6268@caradoc.them.org> Message-ID: Sorry, I forgot to include the exception frame. That is actually what I was trying to look into but it doesn't seem to make sense to me. The following GDB session output was from attempting to debug the 'hello world' program from flash. This program, when run without GDB, runs fine. It can be debugged fine by GDB when run from RAM. (gdb) target remote | m68k-elf-sprite pe: m52235evb Remote debugging using | m68k-elf-sprite pe: m52235evb m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF REF : M52230DEMO (PE60)) m68k-elf-sprite: Target reset 0x00000000 in __cs3_interrupt_vector_coldfire () (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000f5e in __cs3_isr_illegal_instruction () (gdb) p $sp $1 = (void *) 0x20007f88 (gdb) x/4xw $sp 0x20007f88: 0x20007fd4 0x40102708 0x00000002 0xfffffffe (gdb) This exception frame doesn't seem to make a whole lot of sense to me. I did make some progress though. If I manually set $pc = __cs3_reset and $sp = 0x20008000 and then issue the continue command, it executes as expected. Also I can add breakpoints if I use 'hbreak' but it doesn't seem to add hardware breakpoints by default. Corrin Meyer > -----Original Message----- > From: Corrin Meyer [mailto:Corrin.Meyer at dornerworks.com] > Sent: Monday, September 08, 2008 10:42 AM > To: coldfire-gnu-discuss at codesourcery.com > Subject: RE: [coldfire-gnu-discuss] Debugging from flash > > It actually is not a M52235EVB but the ColdFire is configured like a > M52235EVB. I have been able to successfully run and debug applications > from RAM. It is just once I go to Flash that I am getting this problem. > > Corrin Meyer > > > -----Original Message----- > > From: Daniel Jacobowitz [mailto:dan at codesourcery.com] > > Sent: Monday, September 08, 2008 9:42 AM > > To: Corrin Meyer > > Cc: coldfire-gnu-discuss at codesourcery.com > > Subject: Re: [coldfire-gnu-discuss] Debugging from flash > > > > On Mon, Sep 08, 2008 at 09:21:09AM -0400, Corrin Meyer wrote: > > > (gdb) target remote | m68k-elf-sprite pe: m52235evb > > > > Just checking, is your board actually an M52235EVB or is it something > > similar but slightly different? > > > > > Program received signal SIGTRAP, Trace/breakpoint trap. > > > 0x00000e12 in __cs3_isr_illegal_instruction () > > > (gdb) > > > > At this point, I'd suggest you check the exception frame on the stack > > to see what instruction was illegal. > > > > > I would expect that after issuing the continue command that the > program > > > should execute just as if the board had been booted. Am I missing > > > something? > > > > Almost the same. The only difference is that the initialization > > sequence in the board file is executed first; this is to support > > programs run from RAM, which may require the memory controller > > to be initialized first. But in general the initialization sequence > > does not cause a problem if executed twice. > > > > -- > > Daniel Jacobowitz > > CodeSourcery From frank.bennett at valcomelton.com Thu Sep 4 17:37:19 2008 From: frank.bennett at valcomelton.com (Frank Bennett) Date: Thu, 04 Sep 2008 13:37:19 -0400 Subject: m68k-elf-sprite *IPSBAR read won't work Message-ID: <48C01CCF.3050901@valcomelton.com> I created a board/Arcturus.xml for a uc5282 (attached) working for a 32 bit SDRAM and sram but m68-elf-sprite[gdb] can't read the H/W registers relative to IPSBAR...with or without the memory write... Suggestions? thanks, Frank Bennett *$ cat .gdbinit* target remote | m68k-elf-sprite pe://USBMultilink/PE6016704 arcturus x 0x20000000 x set *(0x00000000) = 0xA5A59696 x 0x0 x x 0x40000000 x *$ m68k-elf-gdb* GNU gdb (Sourcery G++ 4.2-135) 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: . m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF Rev C (PE6016704)) m68k-elf-sprite: Target reset 0x00000000 in ?? () 0x20000000: 0x100001ac 0x20000004: 0x100001cc 0x0: 0xa5a59696 0x4: 0x44082704 0x40000000: c:\projects\EL1177\utc16CodeSourcer\bootflash/.gdbinit:7: Error in sourced command file: Cannot access memory at address 0x40000000 (gdb) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: arcturus.xml Type: text/xml Size: 3666 bytes Desc: not available URL: From special at mymail.mattcohn.com Fri Sep 5 00:32:45 2008 From: special at mymail.mattcohn.com (Matt Cohn) Date: Thu, 4 Sep 2008 17:32:45 -0700 Subject: [coldfire-gnu-discuss] m68k-elf-sprite 4.2-125 crashing Message-ID: Thank you, I'm running the GNU tools via cygwin on Windows XP for clarification. I found and used USBDeview.exe to uninstall my USB drivers to be reinstalled - they reinstalled fine but it did not alleviate the problem. I don't have testcfz.exe, it wasn't on the CD that came with the M52233DEMO, and I wasn't able to find it anywhere on pemicro.com. Do you know where I can find a copy? Also I connected an external power supply and that had no effect. What's so frustrating about this problem is I can't find any evidence of anyone else having anything similar! Most of the time when leaving code executing for a couple minutes I'm simply unable to suspend again. If I'm stepping through, invariably after so many steps (anywhere from 5 to 50) I recieve one of: m68k-elf-sprite: error: Lost connection to hardware device Error from remote target: Lost connection to hardware device --or-- m68k-elf-sprite: error: Lost connection to hardware device m68k-elf-sprite: Not closing port because of lost connection Remote communication error: No error. --or-- nothing on the console and m68k-elf-sprite will simply consume lots of CPU while eclipse does nothing, the step buttons grayed out, pressing halt or suspend grays out the corrosponding button. I additionally installed XP SP3 as well as a few other Windows updates, disabled as many startup programs as I could bare to be without, updated Zylin Embedded Debug to its latest version, and tried using "GDB Hardware Debugging" instead of "Zylin Embedded debug" today with no effect. Any ideas or things to try are sincerely appreciated - thank you! --Matt > Just to test the BDM interface I have a utility (PC/Windows based) call > Testcfz.exe. With the M52233DEMO connect to PC via the USB cable, it > will find the ColdFire device and run a simple test and report PASS or > FAILURE. > I've seen weird things if the PC USB port doesn't supply the 500mA. You > might try using external power supply to rule that out. > Does your issue happen when not using verbose mode? > I haven't sparked up my Linux box with CodeSourcery tools for awhile. > I'll try to find some time to do that. > I have used a utility called "USBDeview.exe" (again PC/Windows based) to > remove/uninstall the USB drivers so that I can start fresh and new. > Regards, > David > > > David E Seymour > > http://www.freescale.com/coldfire > > > -----Original Message----- > From: Matt Cohn [mailto:codesourcery at mymail.mattcohn.com] > Sent: Thursday, September 04, 2008 2:18 PM > To: Seymour David-RA2693 > Subject: RE: [coldfire-gnu-discuss] m68k-elf-sprite 4.2-125 crashing > > Thanks David, I gave it a shot, but I wasn't able to locate updated > firmware you mentioned. From here: > http://www.pemicro.com/support/download_processor.cfm the only relevent > updates I found were to the hardware interface drivers (which I updated > just to be sure). > > The M52233DEMO board lists its onboard BDM as equivalent to USB-ML-CF, > here: > http://www.pemicro.com/products/product_viewDetails.cfm?product_id=163&C > FID=1912140&CFTOKEN=57896256 > whose downloads section doesn't list any updated firmware. > > Do you have any further ideas or things for me to try? > > Thank you, > --Matt > > > > We've been having issues with the version of P&E USB BDM firmware. > > You might register on www.pemicro.com and download the latest BDM test > > > utility and firmware to see if that helps. > > Regards, > > David > > > > > > David E Seymour > > > > http://www.freescale.com/coldfire > > > > > > -----Original Message----- > > From: Nathan Sidwell [mailto:nathan at codesourcery.com] > > Sent: Tuesday, September 02, 2008 3:26 AM > > To: Matt Cohn > > Cc: coldfire-gnu-discuss at codesourcery.com > > Subject: Re: [coldfire-gnu-discuss] m68k-elf-sprite 4.2-125 crashing > > > > Matt Cohn wrote: > > > Hia, > > > > > > I am debugging a M52233DEMO board using the P&E USB BDM. I connect > > > to > > it via m68k-elf-sprite. I turned on the verbose console and put the > > sprite in verbose mode, and here's the problem I'm experiencing. > > > > > > Usually debugging will work fine for a while. I will be able to > > continue, suspend, step, break, and continue again without problems. > > After leaving the program running for a while (a couple minutes) or > > doing a lot of stepping (anywhere, not in one particular place) I will > > > experience the following. > > > > > > If the code was running and I try to do a suspend, m68k-elf-sprite > > uses a lot of CPU and doesn't respond. Eventually GDB times out with > > "Target request failed: Failed to interrupt". During this there is no > > > response on the console. > > > > > I should also note that occasionally (about 1/5th of the time) when > > programming my board using CF Flasher, it will hang, timeout, fail > > validation and need to be flashed again. Flashing again works fine. > > I have tried disconnecting all of my USB devices, using a different > > USB port, and killing all background processes and services to no > avail. > > Any advice is sincerely appreciated. > > > > This sounds very much like a hardware problem, because you're getting > > it from two independent software tools. > > > > nathan > > > > -- > > Nathan Sidwell :: http://www.codesourcery.com :: > > CodeSourcery > > > From nathan at codesourcery.com Tue Sep 9 06:45:01 2008 From: nathan at codesourcery.com (Nathan Sidwell) Date: Tue, 09 Sep 2008 07:45:01 +0100 Subject: [coldfire-gnu-discuss] m68k-elf-sprite *IPSBAR read won't work In-Reply-To: <48C01CCF.3050901@valcomelton.com> References: <48C01CCF.3050901@valcomelton.com> Message-ID: <48C61B6D.4080708@codesourcery.com> Frank Bennett wrote: > I created a board/Arcturus.xml for a uc5282 (attached) working for a 32 > bit SDRAM and sram > but m68-elf-sprite[gdb] can't read the H/W registers relative to > IPSBAR...with or > without the memory write... > Suggestions? > c:\projects\EL1177\utc16CodeSourcer\bootflash/.gdbinit:7: Error in > sourced command file: > Cannot access memory at address 0x40000000 > (gdb) You need to add IPSBAR to the section. classify it as RAM. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery From Corrin.Meyer at dornerworks.com Tue Sep 9 12:54:58 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Tue, 9 Sep 2008 08:54:58 -0400 Subject: [coldfire-gnu-discuss] Debugging from flash In-Reply-To: References: <20080905213323.GX6268@caradoc.them.org> <20080908134221.GE6268@caradoc.them.org> Message-ID: I have been continuing to try to debug my problem. While I am still not sure if I am doing it correctly, I have at least been able to start stepping though my code as long as after connecting with the sprite I set PC to __cs3_reset. The problem I have now is that I am getting an access error: Remote debugging using | m68k-elf-sprite pe: versimation m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF REF : M52230DEMO (PE60)) m68k-elf-sprite: Target reset 0x00000000 in __cs3_interrupt_vector_coldfire () (gdb) set $pc=__cs3_reset (gdb) si 0x00000406 in __cs3_reset_m52235evb () (gdb) 0x0000040a in __cs3_reset_m52235evb () (gdb) 0x00000410 in __cs3_reset_m52235evb () (gdb) 0x00000414 in __cs3_reset_m52235evb () (gdb) 0x00000416 in __cs3_reset_m52235evb () (gdb) 0x0000041c in __cs3_reset_m52235evb () (gdb) 0x00005620 in _start () (gdb) 0x00005622 in _start () (gdb) Cannot access memory at address 0x5620 (gdb) x/4xw 0x401d0014 0x401d The entire block (as far as I can tell; I haven't tested every entry) of flash from 0x4000 to 0x5fff is inaccessible. Corrin Meyer > -----Original Message----- > From: Corrin Meyer [mailto:Corrin.Meyer at dornerworks.com] > Sent: Monday, September 08, 2008 5:25 PM > To: coldfire-gnu-discuss at codesourcery.com > Subject: RE: [coldfire-gnu-discuss] Debugging from flash > > Sorry, I forgot to include the exception frame. That is actually what I > was trying to look into but it doesn't seem to make sense to me. The > following GDB session output was from attempting to debug the 'hello > world' program from flash. This program, when run without GDB, runs > fine. It can be debugged fine by GDB when run from RAM. > > > (gdb) target remote | m68k-elf-sprite pe: m52235evb Remote debugging > using | m68k-elf-sprite pe: m52235evb > m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF REF : > M52230DEMO (PE60)) > m68k-elf-sprite: Target reset > 0x00000000 in __cs3_interrupt_vector_coldfire () > (gdb) c > Continuing. > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00000f5e in __cs3_isr_illegal_instruction () > (gdb) p $sp > $1 = (void *) 0x20007f88 > (gdb) x/4xw $sp > 0x20007f88: 0x20007fd4 0x40102708 0x00000002 > 0xfffffffe > (gdb) > > > This exception frame doesn't seem to make a whole lot of sense to me. > > I did make some progress though. If I manually set $pc = __cs3_reset > and $sp = 0x20008000 and then issue the continue command, it executes as > expected. Also I can add breakpoints if I use 'hbreak' but it doesn't > seem to add hardware breakpoints by default. > > Corrin Meyer > > > -----Original Message----- > > From: Corrin Meyer [mailto:Corrin.Meyer at dornerworks.com] > > Sent: Monday, September 08, 2008 10:42 AM > > To: coldfire-gnu-discuss at codesourcery.com > > Subject: RE: [coldfire-gnu-discuss] Debugging from flash > > > > It actually is not a M52235EVB but the ColdFire is configured like a > > M52235EVB. I have been able to successfully run and debug > applications > > from RAM. It is just once I go to Flash that I am getting this > problem. > > > > Corrin Meyer > > > > > -----Original Message----- > > > From: Daniel Jacobowitz [mailto:dan at codesourcery.com] > > > Sent: Monday, September 08, 2008 9:42 AM > > > To: Corrin Meyer > > > Cc: coldfire-gnu-discuss at codesourcery.com > > > Subject: Re: [coldfire-gnu-discuss] Debugging from flash > > > > > > On Mon, Sep 08, 2008 at 09:21:09AM -0400, Corrin Meyer wrote: > > > > (gdb) target remote | m68k-elf-sprite pe: m52235evb > > > > > > Just checking, is your board actually an M52235EVB or is it > something > > > similar but slightly different? > > > > > > > Program received signal SIGTRAP, Trace/breakpoint trap. > > > > 0x00000e12 in __cs3_isr_illegal_instruction () > > > > (gdb) > > > > > > At this point, I'd suggest you check the exception frame on the > stack > > > to see what instruction was illegal. > > > > > > > I would expect that after issuing the continue command that the > > program > > > > should execute just as if the board had been booted. Am I missing > > > > something? > > > > > > Almost the same. The only difference is that the initialization > > > sequence in the board file is executed first; this is to support > > > programs run from RAM, which may require the memory controller > > > to be initialized first. But in general the initialization sequence > > > does not cause a problem if executed twice. > > > > > > -- > > > Daniel Jacobowitz > > > CodeSourcery From Corrin.Meyer at dornerworks.com Tue Sep 9 16:50:55 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Tue, 9 Sep 2008 12:50:55 -0400 Subject: Reading back VBR from GDB Message-ID: Is there anyway to read the value of the VBR in GDB? 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 Corrin.Meyer at dornerworks.com Tue Sep 9 17:57:15 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Tue, 9 Sep 2008 13:57:15 -0400 Subject: [coldfire-gnu-discuss] Debugging from flash In-Reply-To: References: <20080905213323.GX6268@caradoc.them.org> <20080908134221.GE6268@caradoc.them.org> Message-ID: It appears that _start starts at 0x400 which is where default values that control the flash access permissions and control are stored. I moved _start to 0x420 and fill the space between 0x400 and 0x420 with 0x0 and things seemed to start to work. Corrin Meyer > -----Original Message----- > From: Corrin Meyer [mailto:Corrin.Meyer at dornerworks.com] > Sent: Tuesday, September 09, 2008 8:55 AM > To: coldfire-gnu-discuss at codesourcery.com > Subject: RE: [coldfire-gnu-discuss] Debugging from flash > > I have been continuing to try to debug my problem. While I am still not > sure if I am doing it correctly, I have at least been able to start > stepping though my code as long as after connecting with the sprite I > set PC to __cs3_reset. > > The problem I have now is that I am getting an access error: > > > Remote debugging using | m68k-elf-sprite pe: versimation > m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF REF : > M52230DEMO (PE60)) > m68k-elf-sprite: Target reset > 0x00000000 in __cs3_interrupt_vector_coldfire () > (gdb) set $pc=__cs3_reset > (gdb) si > 0x00000406 in __cs3_reset_m52235evb () > (gdb) > 0x0000040a in __cs3_reset_m52235evb () > (gdb) > 0x00000410 in __cs3_reset_m52235evb () > (gdb) > 0x00000414 in __cs3_reset_m52235evb () > (gdb) > 0x00000416 in __cs3_reset_m52235evb () > (gdb) > 0x0000041c in __cs3_reset_m52235evb () > (gdb) > 0x00005620 in _start () > (gdb) > 0x00005622 in _start () > (gdb) > Cannot access memory at address 0x5620 > (gdb) x/4xw 0x401d0014 > 0x401d > > > The entire block (as far as I can tell; I haven't tested every entry) of > flash from 0x4000 to 0x5fff is inaccessible. > > Corrin Meyer > > > -----Original Message----- > > From: Corrin Meyer [mailto:Corrin.Meyer at dornerworks.com] > > Sent: Monday, September 08, 2008 5:25 PM > > To: coldfire-gnu-discuss at codesourcery.com > > Subject: RE: [coldfire-gnu-discuss] Debugging from flash > > > > Sorry, I forgot to include the exception frame. That is actually what > I > > was trying to look into but it doesn't seem to make sense to me. The > > following GDB session output was from attempting to debug the 'hello > > world' program from flash. This program, when run without GDB, runs > > fine. It can be debugged fine by GDB when run from RAM. > > > > > > (gdb) target remote | m68k-elf-sprite pe: m52235evb Remote debugging > > using | m68k-elf-sprite pe: m52235evb > > m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF REF > : > > M52230DEMO (PE60)) > > m68k-elf-sprite: Target reset > > 0x00000000 in __cs3_interrupt_vector_coldfire () > > (gdb) c > > Continuing. > > > > Program received signal SIGTRAP, Trace/breakpoint trap. > > 0x00000f5e in __cs3_isr_illegal_instruction () > > (gdb) p $sp > > $1 = (void *) 0x20007f88 > > (gdb) x/4xw $sp > > 0x20007f88: 0x20007fd4 0x40102708 0x00000002 > > 0xfffffffe > > (gdb) > > > > > > This exception frame doesn't seem to make a whole lot of sense to me. > > > > I did make some progress though. If I manually set $pc = __cs3_reset > > and $sp = 0x20008000 and then issue the continue command, it executes > as > > expected. Also I can add breakpoints if I use 'hbreak' but it doesn't > > seem to add hardware breakpoints by default. > > > > Corrin Meyer > > > > > -----Original Message----- > > > From: Corrin Meyer [mailto:Corrin.Meyer at dornerworks.com] > > > Sent: Monday, September 08, 2008 10:42 AM > > > To: coldfire-gnu-discuss at codesourcery.com > > > Subject: RE: [coldfire-gnu-discuss] Debugging from flash > > > > > > It actually is not a M52235EVB but the ColdFire is configured like a > > > M52235EVB. I have been able to successfully run and debug > > applications > > > from RAM. It is just once I go to Flash that I am getting this > > problem. > > > > > > Corrin Meyer > > > > > > > -----Original Message----- > > > > From: Daniel Jacobowitz [mailto:dan at codesourcery.com] > > > > Sent: Monday, September 08, 2008 9:42 AM > > > > To: Corrin Meyer > > > > Cc: coldfire-gnu-discuss at codesourcery.com > > > > Subject: Re: [coldfire-gnu-discuss] Debugging from flash > > > > > > > > On Mon, Sep 08, 2008 at 09:21:09AM -0400, Corrin Meyer wrote: > > > > > (gdb) target remote | m68k-elf-sprite pe: m52235evb > > > > > > > > Just checking, is your board actually an M52235EVB or is it > > something > > > > similar but slightly different? > > > > > > > > > Program received signal SIGTRAP, Trace/breakpoint trap. > > > > > 0x00000e12 in __cs3_isr_illegal_instruction () > > > > > (gdb) > > > > > > > > At this point, I'd suggest you check the exception frame on the > > stack > > > > to see what instruction was illegal. > > > > > > > > > I would expect that after issuing the continue command that the > > > program > > > > > should execute just as if the board had been booted. Am I > missing > > > > > something? > > > > > > > > Almost the same. The only difference is that the initialization > > > > sequence in the board file is executed first; this is to support > > > > programs run from RAM, which may require the memory controller > > > > to be initialized first. But in general the initialization > sequence > > > > does not cause a problem if executed twice. > > > > > > > > -- > > > > Daniel Jacobowitz > > > > CodeSourcery From trevor.white100 at googlemail.com Thu Sep 25 14:58:55 2008 From: trevor.white100 at googlemail.com (Trevor White) Date: Thu, 25 Sep 2008 15:58:55 +0100 Subject: mcf51qe128 Message-ID: <48DBA72F.7000704@googlemail.com> Hi all. I am wanting to code with the Coldfire mcf51qe128. Do I have to define all the registers for io and timer peripherals, etc myself? Are there any files already generated i.e. mcf51qe128.h like in the codewarrier system. Many thanks Trev From mark at codesourcery.com Tue Sep 30 20:14:32 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Tue, 30 Sep 2008 13:14:32 -0700 Subject: [coldfire-gnu-discuss] mcf51qe128 In-Reply-To: <48DBA72F.7000704@googlemail.com> References: <48DBA72F.7000704@googlemail.com> Message-ID: <48E288A8.8000504@codesourcery.com> > I am wanting to code with the Coldfire mcf51qe128. Do I have to define > all the registers for io and timer peripherals, etc myself? Yes, you do. Our CS3 framework provides some support for low-level details like interrupt handling, but there is no direct peripheral support. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713