Hi, I’m using the CY8CPROTO-062-434W developing board. Successfully built and programmed several examples that work fine. But, after a couple of simple debug sessions, the debugger stop working, first with a message saying that it was a timeout waiting for the debug server. After restarting the computer (Windows 10) 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 in the debug console:
[--------------------------------------------------------------------------------------------------------------]
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
0000679:INFO:board:Target type is cy8c6xxa
0000755:INFO:dap:DP IDR = 0x6ba02477 (v2 rev6)
0000762:INFO:ap:AHB-AP#0 IDR = 0x84770001 (AHB-AP var0 rev8)
0000767:INFO:ap:AHB-AP#1 IDR = 0x84770001 (AHB-AP var0 rev8)
0000779:INFO:ap:AHB-AP#2 IDR = 0x24770011 (AHB-AP var1 rev2)
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
0000803:CRITICAL:main:uncaught exception:
Traceback (most recent call last):
File "c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd_main.py", line 362, in run
self.COMMANDSself._args.cmd
File "c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd_main.py", line 680, in do_gdbserver
with session:
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\core\session.py”, line 302, in enter
self.open()
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\core\session.py”, line 420, in open
self._board.init()
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\board\board.py”, line 85, in init
self.target.init()
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\core\coresight_target.py”, line 160, in init
seq.invoke()
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\utility\sequencer.py”, line 213, in invoke
resultSequence.invoke()
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\utility\sequencer.py”, line 213, in invoke
resultSequence.invoke()
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\utility\sequencer.py”, line 208, in invoke
resultSequence = call()
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\coresight\ap.py”, line 1021, in find_components
super(AHB_AP, self).find_components()
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\utility\concurrency.py”, line 28, in _locking
return func(self, *args, **kwargs)
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\coresight\ap.py”, line 649, in find_components
cmpid.read_id_registers()
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\coresight\rom_table.py”, line 111, in read_id_registers
regs = self.ap.read_memory_block32(self.top_address + self.IDR_READ_START, self.IDR_READ_COUNT)
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\utility\concurrency.py”, line 28, in _locking
return func(self, *args, **kwargs)
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\coresight\ap.py”, line 972, in _read_memory_block32
resp += self._read_block32_page(addr, n//4)
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\coresight\ap.py”, line 930, in _read_block32_page
resp = self.dp.read_ap_multiple(self.address.address + self._reg_offset + MEM_AP_DRW, size)
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\coresight\dap.py”, line 664, in read_ap_multiple
return read_ap_multiple_cb()
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\coresight\dap.py”, line 654, in read_ap_multiple_cb
return result_cb()
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\probe\cmsis_dap_probe.py”, line 315, in read_ap_repeat_callback
return result()
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\probe\pydapaccess\dap_access_cmsis_dap.py”, line 871, in reg_read_repeat_cb
res = transfer.get_result()
File “c:\ProgramData\Mbed Studio\mbed-studio-tools\python\lib\site-packages\pyocd\probe\pydapaccess\dap_access_cmsis_dap.py”, line 142, in get_result
assert not self.daplink._crnt_cmd.get_empty()
AssertionError
“GDB server stopped unexpectedly with exit code 1”
Hi, thanks for reporting this. It’s likely to be a pyOCD issue.
Please could you consider reporting this on the pyOCD GitHub: GitHub - pyocd/pyOCD: Open source Python library for programming and debugging Arm Cortex-M microcontrollers
It might be worth starting by checking the version of the interface firmware on your board and upgrading it if there’s a newer version. You can also change the version of pyOCD from the built in terminal in Mbed Studio if there are compatibility issues.
Thanks,
Joe
Hi JoeA, thanks for pointing me in the right direction to report this problem. I’m still finding my way around all these forums. I just finish reporting it in that forum.
I started two weeks ago learning Mbed OS for a new project, therefore I downloaded the latest version of everything: Mbed OS 6.2, Mbed Studio 1.1 and also updated the board’s Kitprog3 to the latest firmware following Cypress recommendation. DAPLINK seems to be working fine for programming and, as I mentioned, I did a few short debug sessions in two or three different projects without any problem. Whatever it is that changed, it survived the Mbed Studio removal. I did get a DLL blocked from execution by the antivirus during the uninstall process. That must be it.
On an unrelated issue, I’m noticing a weird behavior of cut and paste in the Mbed Studio editor. In short, the paste operation lands on a seemingly random line, not the selected one. Once I figure out how to reproduce it, should I report here, or somewhere else?
That’s odd. If you can find some steps to reproduce this then please email studio@mbed.com. We have not seen this behaviour.
It seems that the touch pad of my laptop was misbehaving. I disabled it and using an external mouse I haven’t seen the problem .
Back to the initial problem, I reported it to pyOCD forum in github, but they don’t have much clue of what is going on either. See the discussion here.
One problem is that we don’t have knowledge of the inner workings of Mbed Studio, where are the working directories for intermediary files, etc.
I think that both teams, Mbed Studio and cyOCD, must work together to resolve this issue.
I am experiencing the exact same problem. Perhaps Mbed studio isn’t ready for prime time?
I installed MBed Studio 1.2 in a second computer running Windows 10 and moved there a project from the first one. First thing I noticed is that
Build → Clean Build (hammer button)
fails with a missing mded_config.h file error, until you run a regular build (the mbed_config .h file exists, but it uses a dual forward slashes instead of backslash in the path).
Now I can’t run a debug session because the bug button to start debugging is not lit up after a successful compile with
Build Profile = Debug.
Other problem: when clicking on the Run button (triangle icon), you can see the the compile progress in the output window, and in a little popup window on the bottom right, but it stops at the end of the link process. There is no information output about the programming progress. It used to be in the little pop up window, but it doesn’t show up anymore. So, you have to seat tight and wait to see if the thing you are working on comes back to life or not.
I can’t talk about Mac or Linux, but this won’t be a fully functional and productive IDE environment until they fix the debug functionality.
Hi Guillermo,
Thank you for your feedback.
Moving a project
How was the project moved? Using Source Control management or by copying and pasting all program files? If the second option then we recommend removing the BUILD folder. It may have some absolute paths that are relative to your first PC.
Have you also used a shared Mbed OS version? (Managing libraries - Managing libraries | Mbed Studio Documentation). Please keep in mind that when shared version is used the simple copying and pasting the program will not work as Mbed OS will not be copied as a program contains just a symlink to the Mbed OS that is relative to your first PC.
We recommend using Source Control Management when working on the same program across multiple systems. You can find more about it here: Working with Git - Source control | Mbed Studio Documentation
Debug
What board are you using? Unfortunately, Mbed Studio does not yet support debugging all Mbed boards. We are working on improving our debugger and adding more boards.
I can confirm that not supporting the debug for CY8CPROTO-062-434W board is a regression in version 1.2.0. We are working on a fix.
A PR has already been added to pyOCD for it: Fixed case of cy8c6xxa target in board ID list by mcgordonite · Pull Request #944 · pyocd/pyOCD · GitHub
Thanks,
Arek - Mbed Studio team
Hi Arek,
Thanks for the quick return.
I’m a lone wolf developer and don’t use source control (yet). I just copy the project folder from one computer to the other at the same default Mbed programs location, but, user names are different in both computers, so, that broke the path. For visual studio I use a simple path for all my projects C:\Code\… I guess I should do the same for Mbed. But deleting the BUILD folder is a simple enough fix. One more trick for my bag.
I’m still in learning mode for Mbed OS and not using a shared folder for it yet, but I will with an invariant absolute path among all my computers.
Regarding Debug, this is the real big problem. As stated at the beguining of this thread, CY8CPROTO-062-434W is my development board, which is also the reference design for my custom board. The drop of debug support for this board is a blow to my plans, I guess the same goes for all Cypress PSOC6 boards, or just this one?
Is the drop of support only for Mbed Studio for Windows, or across all platforms?
I hope you can find a fix for it soon, otherwise I (and many others I suppose) will have to rethink the choice of OS.
Same here. Very frustrating.
I have also noticed there seems to be a lot of arcane lore with these tools.
More details:
choose the debug build
hit build
- build happens
- get the image
then… crickets
The debug button is grayed out
The code is not burned to the board - prove by changing the timing on the blinky - the blinky is at the same rate
in the debug window, type “help” - get a message the debug session needs to be started
If switch to “develop” mode - build fine
- not burned to board (again, change blinky rate)
Hi Bandit, Guillermo
Apologies for this issue. Unfortunately all Cypress boards are affected. As I mentioned we implemented a fix for it already and are planning to release a new version of Studio (1.2.1) within the next few days.
Build button does not flash a program on the board. It only compiles the program and creates a binary that can then be flashed on the board (board does not need to be connected for this functionality to work). A run (deploy) button is compiling a program and flashing it on the board. Unfortunately run and debug buttons do not work for this board at the moment due to the bug I mentioned above. The binary however can still be flashed on a board using usual drag & drop functionality. You can find it in BUILD folder. Unfortunately until version 1.2.1 deploy/debug and serial monitor functionality will not work correctly for Cypress boards.
Until it is resolved you can also downgrade to version 1.1.0 of Studio. The auto-update mechanism will have to be disabled to prevent Studio from being updated to version 1.2.0. I’ve provided more information on how to do it in this thread: Mbed studio 1.2 won't detect platform - #17 by arekzaluski
Thanks,
Arek - Mbed Studio team
I’m using a Nucleo-144 pin with STM32F767. Debug worked fine with blinky until it didn’t. No changes to my setup. Version 1.2.0 on Windows 10.
Thanks Arek. It seems that this issue caught your attention, which is encouraging. For what I could see you have quite a few rough edges to work on.
IMO how and when the development platform should be upgraded must be an end user decision, if the upgrade fixes something or brings a feature of interest to that particular user.
Didn’t you notice that many software houses deliver brand new applications using libraries that are two or more years behind the latest releases?
Appreciate the response. I will eagerly look for 1.2.1.
BTW, while I love the DAPLink method, please see DAPLink window will *not* stay away
Yours … bandit
I think multiple issues are mixed up in this thread.
In my case, the debugger connection times out because of a port mismatch.
Version 1.2.1 seems to suffer from the same problem.
The gdb server is started on port 50000, then a connection to localhost:49999 times out and no debug session is possible.
Looks like a simple +1 error somewhere, but I can not find the location/configuration setting the ports.
My Setup is mbed studio 1.2.1 on Debian buster connected to a Nucleo-F102RB (integrated STLink).
Flashing works fine, program (blinky) runs, debug session connection times out.
I have the same problem with version 1.2.1 on Ubuntu 20.04 with a Nucleo_f446ZE board.
Starts the server on port 50000, then times out and complains about inability to connect to localhost:49999.
I’m seeing the same thing as you on a NUCLEO-F412ZG board on version 1.3.0 and Windows 10. Below is a screencap of the failure. It looks like the GDB server is coming up okay, but Mbed Studio is trying to connect to the wrong port:
I think that the guys responsible for Mbed Studio must fix this. I was told to reinstall a patch from the other tool that does the programming. To do that I need to install pyton, and once I do it I don’t know what else will be broken. I’m not wasting my time fixing the tool until the next release comes out. I must work on my project, so, I moved to other aspects of the project while they hopefully fix it. Otherwise I must move on to another more reliable platform.