avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] avarice again


From: Klaus Rudolph
Subject: Re: [avr-gcc-list] avarice again
Date: Thu, 01 Aug 2002 19:19:02 +0200

Hi Theodore, hallo NG,

sorry Theodore, My last PM was sent in the same moment I receved this
mail.
Sorry for this.



> I just looked through the gdb code in simulavr and found this:
> 
>         /* NOTE: from what I've read on the gdb lists, gdb never uses the
>            "continue at address" functionality. That may change, so let's
>            catch that case. */
> 
> The "continue at address" is the cAAAA or sAAAA command.

Fine, that will not be used and ....

> 
> You should be able to set PC to anything you want like this:
> 
>   (gdb) set $pc = 0xXXXX


will currently not work. Aeehhh, what methods to debug you use? Never
set
PC before? Wondering....

Thank you for reply all my questions. From the actual position I think 
there is so much todo, that I can update my avr ice, because the
working part is less than the not working. And after rewriting all
the code (if neccessary) we have an actual avarice.
So I will do the update tommorow, if I have a bit time. And the
following
week I will implement all the needed features to make avarice a working
one.

I´m really wondering that here some people told me that they are working 
with the tool without changing PC.... differnt people, differnt debug
methods :-)

So there comes again one week without writing productiv code. It is good
that I have
not to earn my money with this tools.

Thanks,
        Klaus


> 
> where XXXX is the address. Note the the address should be 2 times what the
> real flash address is since gdb thinks all addresses are bytes but the
> avr addresses the flash space by words.
> 
> Of course, I decided to test this before I sent this message and, alas, it
> doesn't work. :-(
> 
> (gdb) break main
> Breakpoint 1 at 0x390: file memtest.c, line 294.
> (gdb) c
> Continuing.
> 
> Breakpoint 1, main () at memtest.c:294
> 294         MCUCR = _BV (SRE);          /* Enable External SRAM/XMEM */
> (gdb) set debug remote 1
> (gdb) set $pc = 0x0
> Sending packet: $P22=00000000#71...Ack
> Packet received: E01
> Remote failure reply: E01
> 
> It looks like 'P' packets are not implemented in avarice. Plus, I see that
> the 'P' packet code that is there isn't handling the PC register
> correctly.
> 
> What should really happen is avarice should complete ignore 'P' packets
> for now and just send gdb an empty reply. Then gdb could try another
> method of setting the register if possible. If I can find some time this
> weekend, I'll see what I can come up with on this. Not Likely though. :-(
> 
> And looking at what simulavr does, I see that I forgot to update it to
> handle the change from 2 to 4 bytes for the PC. D'oh! ... Fixed.
> 
> Ted Roth
> 
> On Thu, 1 Aug 2002, Klaus Rudolph wrote:
> 
> :) Hallo all,
> :)
> :) I took a short look inside the avarice sources and found
> :) no function to set the PC. So I must not
> :) wonder that I am not able to set PC from gdb. Or have
> :) I overseen something?
> :)
> :) I think that there must be a 'cAAAA' command which
> :) set PC to new execution position and
> :) therefor must be a way to get the AAAA to the device via
> :) jtag. But inside the remote.cc i found:
> :)
> :)     240     case 'c':  // cAA..AA    Continue from address AA..AA(optional)
> :)     241     // try to read optional parameter, pc unchanged if no parm
> :)     242 #if 0 // not yet supported
> :)     243     if(hexToInt(&ptr, &addr))
> :)     244     {
> :)     245         registers[PC] = addr;
> :)     246     }
> :)     247 #endif
> :)     248     if (jtagContinue())
> :)     249     {
> :)     250         strcpy(remcomOutBuffer, "S05"); // Just tell it a break
> :) happened.
> :)     251     }
> :)     252     else
> :)     253     {
> :)     254         // A breakpoint did not occur. Assume that GDB sent a 
> break.
> :)     255
> :)     256         // NEED SOMETHING MORE CLEVER THAN THIS!!
> :)     257
> :)     258         // Flush the GDB command buffer.
> :)     259         (void)tcflush(gdbFileDescriptor, TCIFLUSH);
> :)     260         // Halt the target.
> :)     261         finishCommand();
> :)     262         // Send signal up to gdb. Sadly, I can't find in the GDB
> :) manual,
> :)     263         // which signal to send up. When you run GDB locally under
> :)     264         // Linux, a CTRL-C results in GDB saying "Program received
> :)     265         // signal SIGINT, Interrupt." This should mean that the
> :)     266         // following should work. So far, I can only get GDB to
> :) either
> :)     267         // declare that "The program no longer exists" or simply 
> not
> :)     268         // return the GDB prompt to me :-(.
> :)     269 //      strcpy(remcomOutBuffer, "W02"); // Just tell it interrupt
> :) occured.
> :)     270         strcpy(remcomOutBuffer, "S05"); // Just tell it a break
> :) happened.
> :)     271 //      strcpy(remcomOutBuffer, "W07"); // Just tell it a break
> :) happened.
> :)     272 //      strcpy(remcomOutBuffer, "S03"); // Just tell it interrupt
> :) occured.
> :)     273 //      strcpy(remcomOutBuffer, "S17"); // Just tell it processed
> :) stoped.
> :)     274 //      strcpy(remcomOutBuffer, "W00"); // Just tell it processed
> :) stoped.
> :)     275     }
> :)     276     break;
> :)
> :) This seems not to be working way to set PC, or?
> :)
> :) Same I found with single step instructions: 'sAAAA'
> :) Also only set a breakpoint here :-(
> :)
> :) How do you set the execution position with gdb and avarice?
> :) Which gdb commands can I use to debug?
> :)
> :)
> :) Thanks
> :)     Klaus
> :)
> :) --
> :) GMX - Die Kommunikationsplattform im Internet.
> :) http://www.gmx.net
> :)
> :) avr-gcc-list at http://avr1.org
> :)
> 
> avr-gcc-list at http://avr1.org
avr-gcc-list at http://avr1.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]