-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Codespaces/Devcontainer support #7
Comments
Hi @riestmo In Codespaces, the extension (and the vscode-device-manager extension) need to be installed in the UI extension host by installing them manually (search for arm device manager and arm embedded debug in the extensions panel). Unfortunately, the extension devcontainer entries get installed in the wrong host due to the bug you commented on: https://github.com/orgs/community/discussions/41636#discussioncomment-4632157 When running in the UI extension host on codespaces, communication to the usb device will be via WebUSB. Running a devcontainer locally requires usb passthrough on the container (as the extensions use native usb on the desktop). I believe this can be done using privileged mode containers, but be aware that USB passthrough doesn't work on MacOS with docker: But is apparently possible if you use VirtualBox: https://osxdaily.com/2022/07/02/how-to-connect-usb-devices-to-macos-virtualbox-vm/ |
Hi @thegecko, thanks for sharing the insights. I already tried to install the arm embedded debug extension in the UI extension host. However, in contrast to the arm device manager extension, VSCode only allows me to install the embedded debug extension per default in the Codespace. I had to enforce to install the extension in the UI extension host using the following setting
Is this intended? I would expect the same behavior as for the arm device manager. And once I install the arm embedded debug extension in the UI extension host, it throws me the following error when trying to flash a hex file via "Flash Binary (DAPLink)" Do you have an idea on what could go wrong here? |
A fix for the target Regarding the failure, the system cannot find the program you specified, can you share your |
Great to hear that the fix for the extensionHost will be in the next release. The task.json for flashing the hex file looks like this:
Running it in VSCode locally, it is able to find the hex file in the workspace. However, as soon as I switch to the Codespace/Devcontainer setup, it throws me the previously mentioned error. |
You can try putting in the full path in the "program": "${workspaceFolder}/myapp.hex" If that fixes it, you can also create a task to just echo out the path for the
In your scenario, I believe you may also be able to flash the file directly by right-clicking your hex file in the explorer. |
Unfortunately neither of the suggested workarounds were successful. I created a repo for reproducing the extension behavior: https://github.com/riestmo/debug-extension-test. Could you try to reproduce the issue? Is it possible that the extension tries to find the file locally (since it's installed in the UI extension host) instead of the finding it inside the workspace? |
Thanks, I can recreate the issue and suspect it is a problem with the schemes used in codespaces. I'll investigate... |
Thanks for the info @riestmo. A fix has been published and flashing now works in a codespace of your example repository. |
Thanks a lot @thegecko! I can confirm that flashing hex files from codespace is working now. |
Type: Feature Request
I would like to use the vscode-embedded-debug extension running in Github Codespaces or locally using a devcontainer. So far I was not able to flash or debug my application in such a scenario. Are you planning to support the Codespace/Devcontainer use case for this extension (and possibly all other Arm extensions as well)?
The text was updated successfully, but these errors were encountered: