ataradov / edbg

Simple utility for programming MCUs and FPGAs though CMSIS-DAP protocol. Works on Linux, MAC and Windows.
BSD 3-Clause "New" or "Revised" License
283 stars 93 forks source link

Error: hid_error is not implemented yet #114

Closed Sreedharbot closed 3 years ago

Sreedharbot commented 3 years ago

Trying to flash my ATSAMD11C14A IC with freeDap programer. I was resulted with this error "Error: hid_error is not implemented yet", What is it??,

Moreover , I'm not able to detect my samd11c14a IC, when I plug it to my system, which was flashed.. (I did physical debugging, like checking the solder joints, traces, etc. all were in place). what might be an issue ?? Do you have any idea..?

Please watch this video.. What is issue, with the samd MCU?..

Thanks Sreedhar

ataradov commented 3 years ago

The video is too blurry and I have no idea what you are doing. Can you actually describe step by step your actions and results? Include screenshots if necessary.

I don't understand what Arduino and blink sketch have anything to do with this.

Sreedharbot commented 3 years ago

Okay,

  1. please tell me, what is error indicate "Error: hid_error is not implemented yet"

In the video, step - 1. I have flashed sam_ba_Generic_D11C14A_SAMD11C14A from particle debugger, using EDBG. step -2 . I was able to detect the samd in arduino. step - 3 . when I tried to upload blink sketch using, mattair's "samd11c board library" step - 4. After uploading the code, I was not able to detect the samd ... but the code was verified.

Now , my question is after uploading the code , samd loses the serial monitor. why is so?

ataradov commented 3 years ago

How does free-dap relate to this?

It looks like the error is due to this line of code message("Error: %ls\n", hid_error(handle)); in dbg_mac.c

It looks like some error happens and it tries to print the error message, but this HID library does not implement this function. The MAC port was not created by me, I don't have any Apple hardware for testing. You can try to print the value of "res" variable, may be it will say something useful.

What is your actual hardware debugger? What does "edbg -l" say?

Sreedharbot commented 3 years ago

Okay , actually, I'm facing 2 issue.. with my 2 DIY SAMD ic.

Issue 1

Please watch this video. This is the actual problem. After flashing the bin, I'm not able to view, my SAMD in my system.

Issue 2

For this issue, I will make a clear video post you.. It is related to arduino and SAMD11c ic , but it deals nothing with free-dap or edbg..

Sorry, If I confused you..

ataradov commented 3 years ago
  1. How was the bin file obtained? Can you take a clear picture of the board?
  2. I don't care to even look at issue that have nothing to do with my software.
Sreedharbot commented 3 years ago

Actually, the bin file was downloaded from this link.

Here is the photo of my board and also schematic.

Okay, but can you help in debugging the issue.. ?

ataradov commented 3 years ago

I tried to program the binary into some random D11 board and it works.

I remember there was some fix for MAC because it stopped recognizing HID descriptors correctly. It is possible that the binary is built from older code. Try this file free_dap_d11_std.bin.zip Note that it may not work as an actual programmer, since pinout will not match, but it should be recognized as a USB device.

And also, disconnect the programmer, just in case it is holding the reset or SWD line low.

If it does not work, you need to find something in MAC OS that shows devices (like dmesg command on Linux or device manager on Windows) to see if it is at least looks like USB device.

There may be issues with soldering or something like that.

ataradov commented 3 years ago

Also, double check the voltage after the regulator. You don't have output capacitor, and AMS1117 may be unstable without an output capacitor.

Sreedharbot commented 3 years ago

Also, double check the voltage after the regulator. You don't have output capacitor, and AMS1117 may be unstable without an output capacitor.

It's working.. I add a capacitor.. at the end of voltage regulator 3.3v & computer is detecting the device.

But, now I'm a facing a different issue, in my Linux machine.. "Segmentation fault (core dumped) "

Screenshot from 2021-09-12 16-49-08

what is the issue here. I have installed same like mac.. but I can't figure out what is wrong in my steps?? Please help me out !!...

ataradov commented 3 years ago

This looks like a real issue, possibly related to some unexpected response from this specific debugger.

The only way to know what is going on is to debug. If you can, add calls like verbose("debug\n"); along the way and see where it fails. I don't have this debugger hardware, so I can't debug this on my side.

Sreedharbot commented 3 years ago

Okay, I have added verbose line.. to check for debug. I ended in hex like last time..

0x10 0x03 0x83 0x00 0x00 0x00 0x00 0x00 0x2b 0xc4 0x8a 0x92 0x85 0x5b 0xb4 0x08

0x10 0x03 0x83 0x00 0x00 0x00 0x00 0x00 0x2b 0xc4 0x8a 0x92 0x85 0x5b 0xb4 0x08

0x10 0x03 0x83 0x00 0x00 0x00 0x00 0x00 0x2b 0xc4 0x8a 0x92 0x85 0x5b 0xb4 0x08 Segmentation fault (core dumped)

what does it tell? and what is my next move?....

ataradov commented 3 years ago

This is strange. 0x10 is ID_DAP_SWJ_PINS. But I don't understand this sequence.

The first time this command would be issues is in the dap_reset_target_hw(), which is called from reset_with_extension(), which is called from target_select() from target_atmel_cm0p.c

But this function would only generate 2 commands, and one of them would have 0x00 in the second byte.

So I would add debug prints starting from the beginning of the target_select() to see which parts of the code correspond to the hex commands. Right now I don't see how those 3 commands are possible like this.

Sreedharbot commented 3 years ago

okay, but when I tried the code flash in my mac, I was resulted with this error msg....

0x10 0x80 0x83 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xa0 0x10 0x80 0x11 0x2e 0x31 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

0x12 0x88 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff 0x12 0x00 0x11 0x2e 0x31 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

0x05 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x05 0x00 0x07 0x2e 0x31 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

0x01 0x00 0x00 0xf0 0xf1 0x11 0xe0 0xfe 0x7f 0x00 0x00 0x14 0x61 0xae 0x0f 0x01 0x01 0x00 0x07 0x2e 0x31 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

0x03 0xf0 0xf1 0x11 0xe0 0xfe 0x7f 0x00 0x00 0x19 0x61 0xae 0x0f 0x01 0x00 0x00 0x03 0x00 0x07 0x2e 0x31 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

Error: invalid response during transfer (count = 0/1, status = 7)

ataradov commented 3 years ago

This just means that target device did not respond. Status =7 means that SWDIO line was always high in the ACK phase, so either target is not connected or is not responding for some reason.

ataradov commented 3 years ago

I just fixed one possible segfault issue. See if the latest code fixed that for you.

It mya happen when there is permission error. So you need to add a udev rule or run as root (sudo works too).

Sreedharbot commented 3 years ago

This time, I have got this error.. 0x10 0x03 0x83 0x00 0x00 0x00 0x00 0x00 0x48 0x69 0x1e 0xc1 0xd6 0x5b 0x29 0x05 debugger write(): Bad file descriptor

ataradov commented 3 years ago

This looks exactly like incorrect permissions.

Try running with sudo or under root directly. And if that helps, then make udev rule for your device (see file 90-atmel-edbg.rules)

Sreedharbot commented 3 years ago

Yes.. it is working.. code is uploaded..Thanks

Sreedharbot commented 3 years ago

After successful flashs, I removed the wires and connected back.. just like that.. Now I'm facing this issue

0x03 0x00 0x33 0x5e 0xf5 0x4f 0x0f 0x27 0x8a 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Error: invalid response during transfer (count = 0/1, status = 7)

ataradov commented 3 years ago

Status =7 still means that the target is not connected or does not respond to the debugger commands over SWD.