Problems polling events from an EDBG Interface

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, forgive me if I'm posting this in the wrong section.

 

I'm currently trying to write my own debugger program for AVR which communicates on an EDBG device with the EDBG Interface documentation

I have some of it already sorted out like setting breakpoints, reading registers, reading/writing memory. However, I have some problems getting break events from the EDBG which can tell me when the AVR has stopped after setting a breakpoint.

From what I understand from the CMSIS-DAP documentation the EDBG is supposed to store all these events which it receives until I send a CMSIS command to poll for them.

 

This is command 0x82 (AVR_EVT) and you should expect a response given in the table under:

 

Field Size Description
AVR_EVT 1 byte 0x82
Size 2 byte, MSB first Number of event bytes
Event N bytes Enveloped AVR event

Source

 

So when I am setting a breakpoint and starting the core again I can confirm that the core halted on my breakpoint.

However, when I poll for the events I don't get anything no matter how many times I try.

 

Command:

0x82

Response:

0x82 0x0 0x0 0x6 0xe 0xe 0x0 0x12....

(Since the size is zero the rest of the bytes should be ignored)

 

Am I doing something wrong here in my interpretation of the documentation? Do I need to set any config on the debugger before this will work?

 

Would greatly appreciate any advice on this :)

This topic has a solution.
Last Edited: Sun. Jul 12, 2020 - 10:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the input seems like I forgot to start the housekeeper and missed the part that it was necessary for the host to receive events :)

Now though I'm getting events, however they seem not to match any event id in the docs.

 

Example of break which should have id 0x40

Field Size Description
EVT_AVR8_BREAK 1 byte Event ID
Version (0x00) 1 byte Event version
PC 4 byte Program Counter value (word address)
Break cause 1 byte

0x00 = unspecified

0x01 = program breakpoint

Extended info 2 bytes N/A

 

Recived:

0x82 0x00 0x0d 0x0e 0x00 0x00 0x00 0x12 0x40 0xaa 0x00 0x00 0x00 0x01 0x04 0x20 0x00 ....

My understanding of the decoding:

size: 0xd (13)

Event 13-bytes: 0x0e 0x00 0x00 0x00 0x12 0x40 0xaa 0x00 0x00 0x00 0x01 0x04 0x20

Event-id: 0xe

 

Is there some padding or other decoding step I am missing here?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you see an ID you don't recognize, just ignore it...

 

You should for instance be able to toggle the VTG line on the EDBG and see 2 0x10 event (Power), or pull the target reset line and get 0x12 (External Reset).

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

Last Edited: Sun. Jul 12, 2020 - 05:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will keep that in mind, however none of the events I receive is recognised. Though they should just be break events.

Here is an example of multiple polls after the device breaks.

(Every hex value is one byte)
0x82 0x0 0xd 0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
INFO:root:Event recived
0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x20
INFO:root:Unknown event

0x82 0x0 0xd 0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
INFO:root:Event recived
0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x20
INFO:root:Unknown event

0x82 0x0 0xd 0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 
INFO:root:Event recived
0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x20
INFO:root:Unknown event

0x82 0x0 0xd 0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x1 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
INFO:root:Event recived
0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x1
INFO:root:Unknown event

0x82 0x0 0xd 0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x21 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
INFO:root:Event recived
0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x21 
INFO:root:Unknown event

0x82 0x0 0xd 0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x1 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
INFO:root:Event recived
0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x1
INFO:root:Unknown event

0x82 0x0 0xd 0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 
INFO:root:Event recived
0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x20
INFO:root:Unknown event

0x82 0x0 0xd 0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
INFO:root:Event recived
0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x20
INFO:root:Unknown event

I can see a 0x40 here though it is succeeded by 0xaa which does not seem to match the event version criteria for 0x00

Also even though you assume that this is where the event starts then it does not match up with break cause:

Event-id: 0x40

Version: 0xaa

PC: 0x0 0x0 0x0 0x1

Break cause: 0x4

Extended info: 0x20 0x0

So it seems unlikely to be an offset problem

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Capture the EDBG traffic with a Logic Analyser. Capture the attendant JTAG or PDI signals.
Run a debug session in AS7.0
.
Then inspect the captured bytes and you will see how it all works.
I am pretty certain that this is what the debugWIRE enthusiasts did.
.
Life is a lot simpler if you just use AS7.0 or MPLABX as Nature intended.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That would probably work. In my case, I'm trying to do this on an atmega4809 curiosity nano over USB to the nEDBG chip. So I would need to sniff the usb traffic somehow.

 

Though if the documentation is supposed to be there (which it seems to), then I would prefer not to go through the steps of reverse-engineering the traffic to see what's wrong :P

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Ah, forgot that there's another level wrapped here... 

 

So, an AVR_EVT contains an enveloped AVR Event

 

Header:

0x82 0x0 0xd 

Enveloped data (0x0d long):

0xe 0x0 0x0 0x0 0x12 0x40 0xaa 0x0 0x0 0x0 0x1 0x4 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0

The enveloped data is a Mk3 AVR frame:

0xe - SOF
0x0 - Protocol version
0x0 0x0 - Sequence, lsb first
0x12 - Handler ID (0x12 = Avr8Generic)

Then, depending on the Handle ID, you know what handler is responsible to decode the event.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

Last Edited: Sun. Jul 12, 2020 - 07:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks! I will try that and see if the events make sense :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Got it working now. Thanks for the help!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stemnic wrote:

Got it working now. Thanks for the help!

 

Hi stemnic,

 

This is great news, I applaud your efforts. Are you planning on releasing your debugger code?

 

As a tinkerer running Linux on a modest 11" Notebook I am very interested in alternatives to AS and MPLabX. AS is out because I'm running Linux and MPLabX because it is very slow on my machine.

 

Best regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ccrause wrote:
As a tinkerer running Linux on a modest 11" Notebook I am very interested in alternatives to AS and MPLabX.
AVR GDB is in Visual Studio Code; may stemnic  consider this EDBG effort as a Visual Studio Code extension.

https://www.avrfreaks.net/forum/avr-studio-mac-linux#comment-2600281

 

"Dare to be naïve." - Buckminster Fuller