Author Topic: Does anyone have experience debugging CMSIS-DAP firmware itself?  (Read 13085 times)

0 Members and 1 Guest are viewing this topic.

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #75 on: May 14, 2021, 04:59:24 am »
status 3 is illegal, but I get the drift. This is an actual communication error with the target. Hard to tell what exactly is wrong without investigating the place that fails.
Alex
 

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #76 on: May 14, 2021, 05:00:42 am »
status 3 is illegal, but I get the drift. This is an actual communication error with the target. Hard to tell what exactly is wrong without investigating the place that fails.
I'll put a more complete log here once I can. ATSAML11 don't have JTAG anyway.
 

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #77 on: May 14, 2021, 11:26:10 am »
Here is what I got:
Code: [Select]
$ ./edbg -b -c 1000 -t saml11 -r -f temp.bin
---
0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0xb0 0x4f 0xf0 0xe0 0x9b 0x7f 0x00 0x00
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x02 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x03 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x04 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x04 0x31 0x2e 0x30 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0xf0 0x2e 0x30 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x01 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
Debugger: SushiBits Innovative SushiBits One with CMSIS-DAP 2ACC2DF0 1.0 (S)
Clock frequency: 1.0 MHz
---
0x03 0x10 0x92 0x35 0xea 0xfe 0x7f 0x00 0x00 0x8f 0xa0 0x8a 0x05 0x01 0x00 0x00
0x03 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x02 0x01 0x10 0x92 0x35 0xea 0xfe 0x7f 0x00 0x00 0x94 0xa0 0x8a 0x05 0x01 0x00
0x02 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x04 0x00 0x00 0x80 0x80 0x00 0x10 0x92 0x35 0xea 0xfe 0x7f 0x00 0x00 0xa5 0xa0
0x04 0x00 0x00 0x80 0x80 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x13 0x00 0x10 0x92 0x35 0xea 0xfe 0x7f 0x00 0x00 0xac 0xa0 0x8a 0x05 0x01 0x00
0x13 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x11 0x40 0x42 0x0f 0x00 0x10 0x92 0x35 0xea 0xfe 0x7f 0x00 0x00 0xb7 0xa0 0x8a
0x11 0x00 0x42 0x0f 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x01 0x00 0x01 0x10 0x92 0x35 0xea 0xfe 0x7f 0x00 0x00 0xc3 0xa0 0x8a 0x05 0x01
0x01 0x00 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x10 0x00 0x83 0x00 0x00 0x00 0x00 0xe0 0x8e 0x35 0xea 0xfe 0x7f 0x00 0x00 0xf8
0x10 0x2c 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x10 0x80 0x83 0x00 0x00 0x00 0x00 0xe0 0x8e 0x35 0xea 0xfe 0x7f 0x00 0x00 0xf8
0x10 0xac 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x12 0x88 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
0x12 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
---
0x05 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x05 0x01 0x01 0x77 0x14 0xf1 0x0b 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x05 0x00 0x03 0x00 0x16 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x04 0x00 0x0f
0x05 0x03 0x01 0x00 0x16 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x04 0x00 0x0f
---
0x05 0x00 0x03 0x01 0x10 0x00 0x00 0xff 0x05 0x01 0x21 0x00 0x41 0x0d 0x00 0x02
0x05 0x03 0x01 0x01 0x10 0x00 0x00 0xff 0x05 0x01 0x21 0x00 0x41 0x0d 0x00 0x02
---
0x05 0x00 0x03 0x01 0x12 0x00 0x00 0xff 0x05 0x18 0x21 0x00 0x41 0x0f 0x02 0x00
0x05 0x03 0x01 0x03 0x01 0x83 0x20 0xff 0x05 0x18 0x21 0x00 0x41 0x0f 0xff 0xff
---
0x01 0x00 0x00 0x00 0x8b 0x35 0xea 0xfe 0x7f 0x00 0x00 0xa4 0x97 0x8a 0x05 0x01
0x01 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x03 0x00 0x8b 0x35 0xea 0xfe 0x7f 0x00 0x00 0xa9 0x97 0x8a 0x05 0x01 0x00 0x00
0x03 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
Error: unknown target device (DSU_DID = 0x20830103)
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #78 on: May 14, 2021, 04:09:34 pm »
This is good. This device is just not on the list. Add the following line to the target_mchp_cm23.c (devices array):
Code: [Select]
  { 0x20830003, "saml11", "SAM L11D16A",  64*1024, true  },

At this point you can also remove the hex printouts, they served their purpose.
Alex
 

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #79 on: May 15, 2021, 12:25:58 am »
This is good. This device is just not on the list. Add the following line to the target_mchp_cm23.c (devices array):
Code: [Select]
  { 0x20830003, "saml11", "SAM L11D16A",  64*1024, true  },


At this point you can also remove the hex printouts, they served their purpose.
Code: [Select]
$ ./edbg -b -c 1000 -t saml11 -r -f temp.bin
---
0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x30 0x4f 0x90 0xf6 0xae 0x7f 0x00 0x00
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x02 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x03 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x04 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x04 0x31 0x2e 0x30 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0xf0 0x2e 0x30 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x01 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
Debugger: SushiBits Innovative SushiBits One with CMSIS-DAP 2ACC2DF0 1.0 (S)
Clock frequency: 1.0 MHz
---
0x03 0x10 0xe2 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x5f 0x50 0x90 0x05 0x01 0x00 0x00
0x03 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x02 0x01 0x10 0xe2 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x64 0x50 0x90 0x05 0x01 0x00
0x02 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x04 0x00 0x00 0x80 0x80 0x00 0x10 0xe2 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x75 0x50
0x04 0x00 0x00 0x80 0x80 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x13 0x00 0x10 0xe2 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x7c 0x50 0x90 0x05 0x01 0x00
0x13 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x11 0x40 0x42 0x0f 0x00 0x10 0xe2 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x87 0x50 0x90
0x11 0x00 0x42 0x0f 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x01 0x00 0x01 0x10 0xe2 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x93 0x50 0x90 0x05 0x01
0x01 0x00 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x10 0x00 0x83 0x00 0x00 0x00 0x00 0xe0 0xde 0x2f 0xea 0xfe 0x7f 0x00 0x00 0xf8
0x10 0x2c 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x10 0x80 0x83 0x00 0x00 0x00 0x00 0xe0 0xde 0x2f 0xea 0xfe 0x7f 0x00 0x00 0xf8
0x10 0xac 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x12 0x88 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
0x12 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
---
0x05 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x05 0x01 0x01 0x77 0x14 0xf1 0x0b 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x05 0x00 0x03 0x00 0x16 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x04 0x00 0x0f
0x05 0x03 0x01 0x00 0x16 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x04 0x00 0x0f
---
0x05 0x00 0x03 0x01 0x10 0x00 0x00 0xff 0x05 0x01 0x21 0x00 0x41 0x0d 0x00 0x02
0x05 0x03 0x01 0x01 0x10 0x00 0x00 0xff 0x05 0x01 0x21 0x00 0x41 0x0d 0x00 0x02
---
0x05 0x00 0x03 0x01 0x12 0x00 0x00 0xff 0x05 0x18 0x21 0x00 0x41 0x0f 0x02 0x00
0x05 0x03 0x01 0x03 0x01 0x83 0x20 0xff 0x05 0x18 0x21 0x00 0x41 0x0f 0xff 0xff
Target: SAM L11D16A (Rev B)
Reading...---
0x10 0x00 0x83 0x00 0x00 0x00 0x00 0xe0 0xde 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x68
0x10 0x2c 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x10 0x80 0x83 0x00 0x00 0x00 0x00 0xe0 0xde 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x68
0x10 0xac 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x12 0x88 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
0x12 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
---
0x05 0x00 0x01 0x02 0x83 0x20 0xff 0x05 0x18 0x21 0x00 0x41 0x0f 0xff 0xff 0xff
0x05 0x01 0x01 0x77 0x14 0xf1 0x0b 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x05 0x00 0x03 0x00 0x16 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x04 0x00 0x0f
0x05 0x03 0x01 0x00 0x16 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x04 0x00 0x0f
---
0x05 0x00 0x03 0x01 0x10 0x00 0x00 0xff 0x05 0x01 0x21 0x00 0x41 0x0d 0x00 0x02
0x05 0x03 0x01 0x01 0x10 0x00 0x00 0xff 0x05 0x01 0x21 0x00 0x41 0x0d 0x00 0x02
---
0x05 0x00 0x03 0x01 0x12 0x00 0x00 0xff 0x05 0x20 0x21 0x00 0x41 0x0d 0xaa 0x47
0x05 0x03 0x01 0x01 0x12 0x00 0x00 0xff 0x05 0x20 0x21 0x00 0x41 0x0d 0xaa 0x47
---
0x05 0x00 0x03 0x01 0x10 0x00 0x00 0xff 0x05 0x02 0x21 0x00 0x41 0x0f 0x47 0x42
0x05 0x03 0x01 0x00 0x20 0x8e 0x18 0xff 0x05 0x02 0x21 0x00 0x41 0x0f 0xff 0xff
---
0x05 0x00 0x03 0x01 0x10 0x00 0x00 0xff 0x05 0x02 0x21 0x00 0x41 0x0f 0xff 0xff
0x05 0x03 0x01 0x00 0x20 0x8e 0x18 0xff 0x05 0x02 0x21 0x00 0x41 0x0f 0xff 0xff
---
0x05 0x00 0x03 0x01 0x12 0x00 0x00 0xff 0x05 0x24 0x21 0x00 0x41 0x0f 0xff 0xff
0x05 0x03 0x01 0x39 0x00 0x00 0xec 0xff 0x05 0x24 0x21 0x00 0x41 0x0f 0xff 0xff
---
0x05 0x00 0x03 0x01 0x10 0x00 0x00 0xff 0x05 0x02 0x21 0x00 0x41 0x0f 0xff 0xff
0x05 0x03 0x01 0x00 0x20 0x0e 0x18 0xff 0x05 0x02 0x21 0x00 0x41 0x0f 0xff 0xff
---
0x05 0x00 0x42 0x01 0x12 0x00 0x00 0xff 0x05 0x00 0x00 0x00 0x00 0x0f 0x0f 0x0f
0x05 0x03 0x04 0x01 0x12 0x00 0x00 0xff 0x05 0x00 0x00 0x00 0x00 0x0f 0x0f 0x0f
---
0x01 0x00 0x00 0x30 0xda 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x74 0x47 0x90 0x05 0x01
0xff 0x0f 0x0f 0x0f 0x0f 0x0f 0x0f 0x0f 0x0f 0x0f 0x0f 0x0f 0x0f 0xff 0xff 0xff
---
0x01 0x00 0x00 0xe0 0xd8 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x81 0x46 0x90 0x05 0x01
0x01 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x03 0xe0 0xd8 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x86 0x46 0x90 0x05 0x01 0x00 0x00
0x01 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
Error: invalid response received
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #80 on: May 15, 2021, 12:46:27 am »
I don't understand how that is possible.

0x05 is a transfer command. So it reads the memory successfully for some time.

The last 0x01 and 0x03 are from the check(). [BTW, remove them for now so they don't confuse the output]. And it looks like the answer to 0x03 (Disconnect) is also screwed up.

But the 0x01/0xff pair, which caused the error, I don't understand. It clearly has not read the whole image, so it would not intentionally disable the led. But even if it does, why the response 0xff?

You would need to add verbose("") prints around target_mchp_cm23.c in the reading part to try to narrow down what causes that request.

Alex
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #81 on: May 15, 2021, 12:53:42 am »
Ok, I know what is the problem. MAC port is not complete. It has "static int report_size = 512;" hardcoded. For a full speed device you need to change that to 64.

I don't have any apple hardware to maintain that port, so it is half baked. I have no idea how to get proper endpoint size on a mac.

For now there is no way to make this automatic. I refuse to give apple my money, so unless someone contributes the code, it will remain this way.
« Last Edit: May 15, 2021, 12:58:22 am by ataradov »
Alex
 

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #82 on: May 15, 2021, 03:09:30 am »
Ok, I know what is the problem. MAC port is not complete. It has "static int report_size = 512;" hardcoded. For a full speed device you need to change that to 64.

I don't have any apple hardware to maintain that port, so it is half baked. I have no idea how to get proper endpoint size on a mac.

For now there is no way to make this automatic. I refuse to give apple my money, so unless someone contributes the code, it will remain this way.
Well you can hackintosh. Or use a modified copy of VMware.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #83 on: May 15, 2021, 03:13:41 am »
Why would I support a closed and hostile to developers platform while simultaneously pirating their software?  What do I stand to gain? The easiest course of action here for me is to delete mac support entirely. It is there for now because someone contributed it, but as things improve in other parts, it may be left behind.
Alex
 

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #84 on: May 15, 2021, 04:49:42 am »
Why would I support a closed and hostile to developers platform while simultaneously pirating their software?  What do I stand to gain?
macOS is close and hostile only if you used Apple's high level libraries, most of which requires Objective-C and Swift languages. Otherwise the underlying XNU kernel is a fully open source UNIX distribution.

The easiest course of action here for me is to delete mac support entirely. It is there for now because someone contributed it, but as things improve in other parts, it may be left behind.
From what I see you should be able to test that macOS code under Linux. dbg_mac.c file has zero reference to Apple-specific headers and libhidapi are cross platform.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #85 on: May 15, 2021, 05:14:15 am »
I can't push the code that I (or someone else) have not tested. Also, I want to get rid of that stupid libhidapi. I hate that it is there and that it is a dependency. So there is no chance I will do anything with it. If I ever do anything with MAC, I figure out how to access HID stuff directly.

Anyway, for me doing anything with MAC is not worth my time. There is no return there. I mostly maintain that tool for my own personal use. If it happens to be useful for others - great.
Alex
 

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #86 on: May 15, 2021, 06:03:36 am »
I can't push the code that I (or someone else) have not tested. Also, I want to get rid of that stupid libhidapi. I hate that it is there and that it is a dependency. So there is no chance I will do anything with it. If I ever do anything with MAC, I figure out how to access HID stuff directly.

Anyway, for me doing anything with MAC is not worth my time. There is no return there. I mostly maintain that tool for my own personal use. If it happens to be useful for others - great.
I may take over maintaining that if I have enough spare time for it. I do PCB design and embedded development on a Hackintosh (Windows and Linux just don't agree with my 24-inch 4K monitor.)
 

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #87 on: May 16, 2021, 08:52:20 am »
Migrating to freedap failed for me, so I am sticking to official ARM code (and migrated to their CMSIS-DAP v2 code).

Now it is actually trying to debug something with my own firmware.
 

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #88 on: May 17, 2021, 10:55:25 am »
Well I am getting errors from OpenOCD once GDB connects. I am not sure whether it is a SAML11 problem or a firmware problem though.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #89 on: May 17, 2021, 03:47:45 pm »
What kind of errors? It very well may be SAM L11. Those TrustZone devices are extremely annoying to work with for no real benefit, IMO.
Alex
 

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #90 on: May 17, 2021, 04:09:10 pm »
What kind of errors? It very well may be SAM L11. Those TrustZone devices are extremely annoying to work with for no real benefit, IMO.
Somehow OpenOCD thinks it is out of sync and tries to re-establish connection with the MCU, performing multiple JTAG-to-SWD sequences. I'm going to put that board on hold for now until I can get samples for ATSAML10D16 (which is supposed to be pin-compatible with the TrustZone-enabled ATSAML11 parts) and focus on something else for now.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #91 on: May 17, 2021, 04:21:17 pm »
L10 is not much better. They both have this annoying BootROM that tools have to interact with instead of normal debug stuff.

If you don't need all those security features, go with SAM D10/D11.
Alex
 

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #92 on: May 17, 2021, 04:32:27 pm »
L10 is not much better. They both have this annoying BootROM that tools have to interact with instead of normal debug stuff.

If you don't need all those security features, go with SAM D10/D11.
I want a Cortex-M23/M33 core to play with. If it is not L10/L11, I would have to go to STM32L5 or GD32E2/E3.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #93 on: May 17, 2021, 04:38:45 pm »
If you want the core specifically, then sure go for it. I'm not sure the device makes a difference. I think it is the core that is annoying. There are too many deviations for the worse from typical Corte-Mx cores, IMO. ARM kind of lost the thread there. I'm guessing marketing took precedence over engineering that time.
Alex
 

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #94 on: May 18, 2021, 01:50:17 am »
If you want the core specifically, then sure go for it. I'm not sure the device makes a difference. I think it is the core that is annoying. There are too many deviations for the worse from typical Corte-Mx cores, IMO. ARM kind of lost the thread there. I'm guessing marketing took precedence over engineering that time.
For me I just need to know if it is any different to support from a C-only environment with CMSIS and bare minimum device headers. For day to day projects I am still sticking to Cortex-M4 and Cortex-M0 products. (IMO Cortex-M3 r2p0 and above are really Cortex-M4 backports.)

STM32L5 is unobtanium here in China currently, and GD32E3/E3/E5 has terrible peripheral support.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #95 on: May 18, 2021, 02:44:41 am »
Non-TZ stuff is virtually the same. Anyone familiar with regular Cortex-Mx devices would find it easy to use.

TZ is nuts. It wrecks all the standard C compatibility that they worked hard to achieve. I guess technically you still code in C, but now they just forced compilers to support their garbage instead of adapting to the existing compilers. This makes the whole thing painful and awkward to use. With no real (non-marketing) benefits.
Alex
 

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #96 on: May 18, 2021, 03:43:40 am »
TZ is nuts. It wrecks all the standard C compatibility that they worked hard to achieve. I guess technically you still code in C, but now they just forced compilers to support their garbage instead of adapting to the existing compilers. This makes the whole thing painful and awkward to use. With no real (non-marketing) benefits.
Hmm I need more details on this...
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #97 on: May 18, 2021, 04:09:25 am »
Read about "-mcmse" flag and relevant linker flags. With TZ you need to separate your program into secure and non-secure parts. And then half your functions becomes littered with attributes like "__attribute__((cmse_nonsecure_entry))".

Here is a random article that shows a summary of what is going on - https://www.lobaro.com/using-the-armv8-m-trustzone-with-gcc/

Here is a sample code from there:
Code: [Select]
// some c file of secure firmware project defining veneer gateway functions
// must compiled with -mcmse gcc flag (!)
#include "arm_cmse.h"
typedef void (*funcptr_ns) (void) __attribute__((cmse_nonsecure_call));
void ControlCriticalIO(funcptr_ns callback_fn) __attribute__((cmse_nonsecure_entry)){
 funcptr_ns cb = callback_fn; // save volatile pointer from non-secure code
 
 // check if given pointer to non-secure memory is actually non-secure as expected
 cb = cmse_check_address_range(cb, sizeof(cb), CMSE_NONSECURE);
 
 if (cb != 0) {
    /* do some critical things e.g. use other secure functions */
    cb(); // invoke non-secure call back function
 }else {
   // do nothing if pointer is incorrect
 }
}

If anyone for a seconds thinks this is "C", they are as nuts as people that engineered that.

And interestingly, STM made an implementation of the same exact thing using external wrapper to the standard core. It is way cleaner and easier to use than this BS. ARM lost the plot here.

And yes, you generally build your program from two completely different binaries - secure and non-secure. Debugging this mess is tricky to put it mildly.
« Last Edit: May 18, 2021, 04:14:22 am by ataradov »
Alex
 

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
« Reply #98 on: May 18, 2021, 04:55:49 am »
Read about "-mcmse" flag and relevant linker flags. With TZ you need to separate your program into secure and non-secure parts. And then half your functions becomes littered with attributes like "__attribute__((cmse_nonsecure_entry))".

[snip]

If anyone for a seconds thinks this is "C", they are as nuts as people that engineered that.

And interestingly, STM made an implementation of the same exact thing using external wrapper to the standard core. It is way cleaner and easier to use than this BS. ARM lost the plot here.

And yes, you generally build your program from two completely different binaries - secure and non-secure. Debugging this mess is tricky to put it mildly.
Understood. If this is the case I think I will be putting SAML11 on infinite hold until ARM can get their sh!t together.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf