Crash when attempting to load firmware

[maxgerhardt]

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:

C:\Users\Max\pyAVRdbg>python main.py
INFO:pyedbglib.hidtransport.hidtransportbase:Manufacturer: ATMEL
INFO:pyedbglib.hidtransport.hidtransportbase:Product: mEDBG CMSIS-DAP
INFO:pyedbglib.hidtransport.hidtransportbase:Serial Number: MICROUPDIPROGRAMMERX
INFO:pymcuprog.deviceinfo.deviceinfo:Looking for device atmega4809
INFO:pymcuprog.nvm:UPDI baud rate: 900000bps
INFO:root:Event recived
PC: 1529
INFO:root:Recived break event
INFO:root:No event
Waiting for GDB session 127.0.0.1:12555
Connected by ('127.0.0.1', 37185)
-> +$qSupported:multiprocess+;qRelocInsn+#2a
<- +
INFO:root:AVR running state False
Supported:multiprocess+;qRelocInsn+
<- $PacketSize=1000#f1
INFO:root:No event
-> +$!#21
<- +
INFO:root:AVR running state False
<- $#00
INFO:root:No event
-> +$Hg0#df
<- +
INFO:root:AVR running state False
<- $#00
INFO:root:No event
-> +$qTStatus#49
<- +
INFO:root:AVR running state False
TStatus
<- $#00
INFO:root:No event
-> +$?#3f
<- +
INFO:root:AVR running state False
<- $S00#b3
INFO:root:No event
-> +$qfThreadInfo#bb
<- +
INFO:root:AVR running state False
fThreadInfo
<- $#00
INFO:root:No event
-> +$qL1200000000000000000#50
<- +
INFO:root:AVR running state False
L1200000000000000000
<- $#00
INFO:root:No event
-> +$Hc-1#09
<- +
INFO:root:AVR running state False
<- $#00
INFO:root:No event
-> +$qC#b4
<- +
INFO:root:AVR running state False
C
<- $#00
INFO:root:No event
-> +$qAttached#8f
<- +
INFO:root:AVR running state False
Attached
<- $0#30
INFO:root:No event
-> +$qOffsets#4b
<- +
INFO:root:AVR running state False
Offsets
<- $Text=000;Data=000;Bss=000#24
INFO:root:No event
-> +$g#67
<- +
INFO:root:AVR running state False
['0x14', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x64', '0x0', '0x0', '0x0', '0x20', '0xb0', '0x23', '0x15', '0x0', '0x0', '0xd3', '0x48', '0x5', '0x0', '0x0', '0x4c', '0x23', '0x1', '0x0', '0x4', '0x2c', '0x3f', '0xb0', '0xa']
['0x80']
['0xde', '0x3f']
<- $14000000000000006400000020b023150000d3480500004c230100042c3fb00a80de3f#72
INFO:root:No event
-> +$p22#d4
<- +
INFO:root:AVR running state False
1898
0x76a
0xed4
00000ed4
d40e0000
<- $d40e0000#ed
INFO:root:No event
-> +$meca,a#23
<- +
INFO:root:AVR running state False
eca
a
0
INFO:root:Reading from address 0x000ECA
bytearray(b'\x0e\x94\xa1\x07\xa5\x9f\x90\r\xb4\x9f')
0e94a107a59f900db49f
<- $0e94a107a59f900db49f#62
INFO:root:No event
-> +$qSymbol::#5b
<- +
INFO:root:AVR running state False
Symbol::
<- $OK#9a
INFO:root:No event
-> +$X0,0:#1e
<- +
INFO:root:AVR running state False
<- $#00
INFO:root:No event
-> +$M0,7f0:0c9451000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c9479000c943e060c94dc060c94b6060c947900af0611241fbecfefcdbfdfe3debf28e2aae0b8e201c01d92ad3bb207e1f718e2a0e0b8e2e8e3f4e102c005900d92aa30b107d9f710e0c1e5d0e004c02197fe010e94da07c035d107c9f70e94a2060c94d2090c940000fc0194898589981720f4891b990b019708952fe330e0291b3109820f932f911d0895fc0192898389981761f0a389ae0fbf2fb11d59968c9193899f5f9f73938b90e008958fef9fef0895fc0192898389981731f08389e80ff11d818d90e008958fef9fef0895fc01228930e0205c3f4f8389a901481b5109ca018f7399270895cf93df93ec01e881f9810680f781e02d0995ec85fd8586818f738683ec85fd8585818f7585838b898a8b198adf91cf910895fc01948985899817d9f0a589ae0fbf2fb11da75abf4f2c91858990e001968f739078858ba485b58580e414968c93a485b58512962c9394898589981741f008950484f585e02d85818f7d85830895a485b585159
Traceback (most recent call last):
  File "main.py", line 332, in <module>
    handleData(conn, data)
  File "main.py", line 293, in handleData
    checksum = (data.split("#")[1])[:2]
IndexError: list index out of range

What PlatformIO does should be giving GDB this init script

target extended-remote 127.0.0.1:12555
load
tbreak loop

[stemnic]

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.

[mraardvark]

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

[stemnic]

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.

[stemnic]

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?

[mraardvark]

I think the intended use-case of the protocol was to:

• enter programming mode
• write flash
• leave programming mode
• attach

Writing flash inside of debugging mode i think was blocked to prevent interference with the software breakpoint mechanism. I also think that there is a session "function" which can be set to either programming or debugging - setting this to debugging will internally follow the leave programming mode with an auto-attach to prevent runaway code. You still call attach, but its really already done.