Open gmgallo opened 4 years ago
cc @thegecko
Is there any registry or settings somewhere to manually cleanup to start with a clean installation again? I really need this debugger now!
There aren't any registry settings for pyOCD, but I'm not sure about Mbed Studio. I'm not immediately sure what is causing this. It seems like a USB or concurrency issue.
What version of pyOCD is this? (pyocd --version
)
I have to do a bit of forensic work to dig out where the heck Mbed Studio hided all its tools but found it here: C:\ProgramData\Mbed Studio\mbed-studio-tools\python\Scripts\pyocd.exe The version is 0.27.0 and Python is 3.7.1
Thanks. The latest version is 0.27.2, so there have been a few bug fixes since 0.27.0. But none of the fixes look related to the assertion failure in your log.
Have you checked that you have the latest firmware version installed on the on-board KitProg3 on the PSoC board?
I'll see if I can reproduce it later today or tomorrow.
In the meantime, could you try placing the pyocd.yaml
config file from the attached pyocd-config.zip in the working directory from which pyocd is executed? Then attach the resulting pyocd_log.txt
to a comment here. This config file enables trace logging of the low level debug probe communications. (Unfortunately, I don't know what working directory Mbed Studio uses… you might try your project folder … @thegecko or @arekzaluski could you help here? Another option is to add --project-dir=<path>
to the pyocd command line to tell it the path to the folder where you put the config file.)
I ran the Kitprog firmware update again just in case... Kit FW is 'KitProg3' ver. 2.00 b809. Upgrade file is 'KitProg3' ver. 2.00 b809. So, that is the latest one available.
I'll try the pyocd.yaml config and report next.
I copied pyocd.yaml to the same directory where pyocd.exe, resides, but I have no clue where Mbed Stuido is executing this command, or where to look for pyocd_log.txt. I have no knowledge of the inner workings of Mbed Studio, si I think both teams should look into this and provide me with more precise directions.
I tried again to run the debugger. It still bombs with an exception as follows (directory paths may give some clues):
Selected port 50000 for debugging
Exception ignored in:
Traceback (most recent call last):
File "c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\usb\_objfinalizer.py", line 84, in __del__
self.finalize()
File "c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\usb\_objfinalizer.py", line 144, in finalize
self._finalizer()
File "c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\weakref.py", line 548, in __call__
return info.func(*info.args, **(info.kwargs or {}))
File "c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\usb\_objfinalizer.py", line 104, in _do_finalize_object_ref
obj._do_finalize_object()
File "c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\usb\_objfinalizer.py", line 71, in _do_finalize_object
self._finalize_object()
File "c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\usb\backend\libusb1.py", line 604, in _finalize_object
_lib.libusb_unref_device(self.devid)
OSError: exception: access violation writing 0x0000000000000024
On a second attempt it tried a different port "Selected port 50002 for debugging" instead of 50000. but nothing else happen. (threads not running and no prompt at the start of main().).
Thanks for checking the KitProg3 firmware.
The "OSError: exception: access violation…" messages are an annoying but apparently harmless side effect of a bug in the pyusb integration with libusb on Windows. As far as we can tell, they can be safely ignored. (Most annoyingly, pyusb has a fix, but they keep delaying a new release.)
Could you please try running pyocd directly? Just open a terminal window for the directory containing pyocd.exe, and run pyocd.exe cmd -vv -t cy8c6xxa
with the pyocd.yaml
file in the same directory. In this case, pyocd_log.txt
will be written to the same directory. This just connects to the device and presents a pyocd interactive command interface. If it somehow makes it to the pyocd>
prompt, you can just type "quit" to exit.
Does Mbed Studio show the pyocd command line it used? You could also try that command line when running pyocd directly.
Ultimately, I need a low level trace of the communications with the debug probe to try to understand what is happening here.
You're not running in a VM are you? That is know to cause trouble with USB, so it's always worth asking. Regardless, could you try adding -da limit_packets=1
to the pyocd command line? This forces only one outstanding USB packet at a time. Based on the log, this issue could be related to USB packet sequencing.
cc @bohdan-tymkiv
Thanks Flit, Quick answer for now... Unfortunately Mbed Studio hides the command line. The output window shows only the tool output. I'll try to guess the dir location to issue the command line as you indicated...
...and no, no VM environment, real hardware : Microsoft Surface laptop. I should try on another desktop just to confirm that the CPU is not to blame here.
Hi, I’m using Mbed Studio 1.1.0 for Windows (10) with the CY8CPROTO-062-434W development board and Mbed OS 6.2. Over the last two weeks I successfully loaded, modified and programmed several examples that worked fine. But, after a couple of short debug sessions, the debugger stop working. First it didn't start and I got a message saying that it was a timeout waiting for the debug server to start. After restarting the computer the debug session crashes more catastrophically. I uninstalled and then reinstalled Mbed Studio 1.1.0, but the problem persists. here is the long trace output printed on the debug console: