Open maxgerhardt opened 3 years ago
Yes, I am aware that firmware loading does not work properly yet. It's been a while since I have had the spare time to work on this but if I remember correctly this is due to the load command not being implemented properly on the rsp-server side in python.
If I have the time I'm planning to look more at it during this weekend or next week.
Good to hear. I still have plans to: a) bring in your hardcoded mystery values into pyedbglib (easy) b) bring the "debugger" into pymcuprog (more tricky) and that way separate the gdb server part from the pymcuprog extension
Good to hear. I still have plans to: a) bring in your hardcoded mystery values into pyedbglib (easy)
When you are saying hardcoded mystery values are you talking about event polling with AVR_EVENT
, checking running state and SREG reads? My impression so far is that most of the debugger functionality can be achieved just by accessing the raw avr protocol class in pyedbglib
b) bring the "debugger" into pymcuprog (more tricky) and that way separate the gdb server part from the pymcuprog extension
Yes I can see how this could be tricky, though you could just have a debugger class like you currently find in debugger.py where you just make it obvious for eventual users of the library how you need to interface with the python module todo debug functionality. I also agree that the gdb server should be separated wholely from pymcuprog. This would allow other projects and other debuggers to use it as well. My problem currently with the whole gdb communication is that it is very hard sometimes to understand the command flow for specific commands (like load above) without just sitting there and trying all the commands on there own making iteration time and debugging a little time-consuming.
Had a more in-depth look at this yesterday, part of the problem was packet sizes being arbitrarily limited to 1000 chars, which does not make any sense to limit since everything here works over a TCP/IP connection. The core problem currently is read and writes to flash while the device is in debugging mode.
current flash read, which for some reason does not work in debugger.py
def readFlash(self, address, numBytes):
logging.info("Reading "+str(numBytes)+" bytes from flash at " + str(address))
return self.device.read(self.memoryinfo.memory_info_by_name('flash'), address, numBytes)
@mraardvark are you aware of any specific requirements that are done in pymcuprog to preform flash reads and writes?
I think the intended use-case of the protocol was to:
If I use PlatformIO to tell GDB to connect to the GDB server upload the debug firmware by using the default GDB
load
command, I get a crash in the script:What PlatformIO does should be giving GDB this init script