-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Error: invalid response received" in ATSAMD11C14A #112
Comments
EDBG support on MAC is incomplete, since I don't have any Apple hardware. It has the report size hard coded:
You probably need to change that value to 64 for your device, since it is likely to be a USB FS device. |
After Changing the
|
Then you need to print out the values of the hid_buffer before hid_write() and after hid_read(). First byte must match. But more importantly you will know on what command it fails. Do that and provide the output.
|
The code here is for Linux version. Leave the existing mac code as is, just copy the part that prints the data. And when running make sure to pass the "-b" argument to enable verbose output. Also, are you sure it is using the newly built version of the edbg? Typically you need to run it like ./edbg ..... to run the version in the current directory and not in the path. |
Okay..
I have just edited the file by adding the verbose.. in the top and both.. (Please correct me, if I am going it wrong ?) then, I run "make clean " and "make all".. This time as you said I run the edbg in the edbg directory.. the code, i have used is
this time, I got a strange output.. like this??..
Can you tell me what this HEX code trying to say..? , how do you decode this ?.. and how to rectify this issue?.... |
This looks like you have not actually corrected 512 -> 64. Do this change, recompile and try again. If you did the change, then it looks like the debugger is just not responding to the information requests. This is the firmware issue in the debugger. The first byte of the request and the response must match. But this could only happen if you send the exact number of bytes the device is expecting. |
just forgot to do the change.... Right Now, I did the change from 512 to 64 and ran "make clean", "make all" After executing "./edbg -bpv -e -t samd11 -f sam_ba_Generic_D11C14A_SAMD11C14A.bin" I received
I got this interesting error.. so, what mistake I have did.. now? I love this debugging!!... |
Now you don't have a target connected to the debugger. You can remove the hex print. The debugger now works. Status = 7 meant that SWDIO line remained high, so there was no active response from the target device (D11 in this case) |
Wait, the target got detected. So something else is wrong. The target did not respond while the flash was erasing. Try to remove the erase command (-e) from the command line and see if the programming succeeds. |
I have removed the -e command...
Now I am facing.. this error Error: invalid response during transfer (count = 0/3, status = 7) |
Please don't add any more of thew hex stuff. It is no longer relevant. Something is still wrong with the target device. Do you have a reset asserted by any chance? |
I didn't had any
moreover.. I tried to run. program many times. and I got the result "Error: invalid response received" only.. |
I meant asserted by some external circuitry. Based on the previous logs, your SWD communication is working, edbg managed to read the device id and recognize the part. But then programming fails. So double check your power supply to the target and electrical stuff like this. And yes, a new chip test would be useful too. |
Hey..good news it is working.. & thanks Initially, I have powered from 5V usb then I have removed that connection and powered from particle debugger. and the output was success.. Hey, if you are interested to share, how you were able to debug the issue. Please share.. ?? I'm very interested to known the backend process.. of this..?? What is USB FS device? , why i needed to do the change the value from 512 to 64.. and How did you conclude that there is some electrical issue.. (did you read from HEX code or ???) . Please answer to the above question it will be helpful for me for my documentation... |
Don't do bold text either. I can read fine. I was able to tell because I ran into a similar issue some time ago with another person. Hex codes were useful in confirming the issue. You could see that debugger responded with 0xff for all but first command. 0xff is the error code. It means that it was interpreting extra byes (stuff over 64 bytes) as commands too. And that obviously would not work. USB HID protocol that is used for CMSIS-DAP communication requires frames to be sent with fixed size. USB Full Speed devices support 64 bytes max, so this is the size that is commonly used. USB High Speed devices can go higher, so 512 or 1024 bytes are common. Linux and Windows ports use OS-specific APIs to determine the size of the endpoint and automatically adjust. MAC port is not really maintained, since I don't use macs and don't have any apple hardware. So the size is just set to a fixed value. |
Hi,
Actually, This is my 1st time in working with ARM Cortex Chip.. Moreover, I want to make a Free_CMSIS_DAP on my own.
You can see my documentation.. By clicking Here where I refer how to build Free_CMSIS_DAP on my own and my failures while building it.
I use:
I also having doubt in using the pins.. so far i have seen many are using jtag 10 pins to program in particle debugger..but when i check continuity between the pins and jtag connector, all are connect expect the RST line..
I also made a video regarding this issue"Error: invalid response received". Here is the link .
Things I want to know is..
I don't have small JTag connector, hence i used jumpers to connect them. I tried uploading the code from Jtag connector and also from the female header pins both indicated same error ? I also checked continuity of my board Free_CMSIS_DAP there is no interconnection.
Please help me out to rectify this issue..
Moreover, please could you share how the EDBG works with Micro-controller.. Is there any other way to debug.. this...
The text was updated successfully, but these errors were encountered: