That’s odd. If you can find some steps to reproduce this then please email email@example.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.
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? (https://os.mbed.com/docs/mbed-studio/current/manage-libraries/index.html#using-a-shared-instance-of-mbed-os). 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: https://os.mbed.com/docs/mbed-studio/current/source-control/index.html
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: https://github.com/mbedmicro/pyOCD/pull/944
Arek - Mbed Studio team
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.
choose the debug build
- build happens
- get the image
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
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.
Thank you for reporting the bug with port 49,999. We confirmed that there was a case when an incorrect port was used for debugging in pyOCD. The issue was fixed. Fix for it will be shipped with the upcoming 1.3.1 release. Apologies for the inconvenience.
We also keep working on a solution to improve debugging in Studio and on supporting more development boards.
Arek - Mbed Studio team
Is there a way to change the port in the preferences or will we have to wait for the patch? If we have to wait for the patch, is there an ETA on the release?
Unfortunately, it is impossible at the moment. We are planning to allow soon to modify all pyOCD config in Studio. It won’t however be possible in the upcoming 1.3.1 patch release. It should be released at the beginning of next week.
Arek - Mbed Studio team