[Top][All Lists]
[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