How to FULLY UNINSTALL nRF Connect SDK and SES on macOS?

Kind folks,

Automated tools like the nRF Connect SDK environment are wonderful when they work, but can be a Procrustean bed when they break or don't fit the exact requirements.  Case in point: I've gone through installing and reinstalling nRF Connect SDK, SES and the VS extension at least half a dozen time in various combinations of automated and manual procedures.  The goal was to merge two sample apps: nrf_dm from the new Nordic v1.9.1 SDK and the nrf_matrix_led example from within the zephyr repo and run the resulting app on a BBC Micro:Bit V2 (an nRF52833-based SBC).  This involved many Kconfig and Device Tree issues.  You can read about some of the details of my journey in an earlier ticket.

Suffice it to say that I've made multiple attempts to uninstall all of the related software, make sure I have cleared away any remnants, and reinstall nRF Connect, and SES (leaving VS code out of the discussion for the moment) all of this running on the absolutely latest macOS Monterey 12.3.  I have failed in this endeavor several times.  Multiple pieces of "trash" (prior state) seem to remain.  For example, when a freshly installed SES is started by clicking on the Open SES, the SES app opens, showing a dashboard which shows a list of recent project (not a blank list).  Then either upon executing the File | Open nRF Connect Project... command, or automatically without any user interaction, the new nRF Project dialog pops up with a covering error message:

Closing the error message leaves an unresponsive options pane.

So, clearly there's some remembered state from prior installs that's preventing a new installation from being done cleanly.  Searching for uninstall instructions for nRF Connect SDK yielded no useful information.  Even searching for uninstallation instructions for SES yields only one suggestion, which proved to be insufficient and didn't erase prior project history. Therefore, I request:

  1. An uninstaller tool for nRF Connect, its plugins (e.g., tool manager), any "embedded" SES IDE inside it's tool collection, and any other remnants of nRF Connect, or
  2. At least a list of files and directories that need to be deleted to effect a complete uninstallation, and
  3. Probably too much to ask for at the current moment, but it sure would be useful to have a description of the process by which "New nRF Connect Project..." does its work inside SES (including critical script files, locations, etc.)

Thanks for any advice.  I am truly stuck and unable to proceed otherwise.

Parents
  • Results of Further Testing:

    • My Windows 10 VM was broken. Built a new, clean Win10 VM (64-bit), installed nRF Connect for SDK Desktop app, Tool Manager, SDK 1.91.  All went without error!
    • From an "Open Terminal" window, it is possible to demonstrate that the west.exe stub does exist and west can be invoked directly from the command line, both of which can be seen from this screen shot.

    • SES launches properly from clicking the "Start SES" button in Tool Manager.
    • The Project Options pane opens without error from the "File | Open nRF Project..." SES menu command.
    • Solution nrf_ dm on nrf52840dk_ nrf52840 generated and built OK
    • Solution nrf_ led matrix on bbc_ microbit v2 generated and built OK

    In other words, everything worked as it should on Windows 10.

    In contrast, I should note:

    • Here's the corresponding terminal output regarding the configuration of the west module on my MacBook Pro running macOS Monterey:
    • Note that a "west.exe" doesn't exist (That's a Windows app), but a "west" file does exist at pathname "../../../west"
    • Converting to an absolute path, that's: /Users/mike/.asdf/installs/python/3.10.0/bin/west
    • That's inside a directory controlled by the asdf virtual environment system I'm using to control multiple Python versions (a multi-language tool more general than env) and, unfortunately, not in the right place to be executed directly from the command line.

    Not sure how to correct this yet, but it certainly points to a problem with west execution in my particular macOS environment.  

    Not sure yet if all of the issues I've encountered are due to this one cause, but fixing it is certainly a good place to start.  I've noted that your online docs now(?) include some comments about use of venv in the Mac environment.  Would be great if you could get together with one of your Python experts to sort out what the proper nRF SDK installation procedures are in a complex Python environment.  I suspect this isn't just a macOS problem, just where we've first encountered it.

    I'll work from my end, but I'm neither a venv or asdf expert.  Just give me some suggestions and I'll try them out.  I suspect this will result in some extra cautions in the documentation or even changes to the installation code.

    Thanks,

    Mike

Reply
  • Results of Further Testing:

    • My Windows 10 VM was broken. Built a new, clean Win10 VM (64-bit), installed nRF Connect for SDK Desktop app, Tool Manager, SDK 1.91.  All went without error!
    • From an "Open Terminal" window, it is possible to demonstrate that the west.exe stub does exist and west can be invoked directly from the command line, both of which can be seen from this screen shot.

    • SES launches properly from clicking the "Start SES" button in Tool Manager.
    • The Project Options pane opens without error from the "File | Open nRF Project..." SES menu command.
    • Solution nrf_ dm on nrf52840dk_ nrf52840 generated and built OK
    • Solution nrf_ led matrix on bbc_ microbit v2 generated and built OK

    In other words, everything worked as it should on Windows 10.

    In contrast, I should note:

    • Here's the corresponding terminal output regarding the configuration of the west module on my MacBook Pro running macOS Monterey:
    • Note that a "west.exe" doesn't exist (That's a Windows app), but a "west" file does exist at pathname "../../../west"
    • Converting to an absolute path, that's: /Users/mike/.asdf/installs/python/3.10.0/bin/west
    • That's inside a directory controlled by the asdf virtual environment system I'm using to control multiple Python versions (a multi-language tool more general than env) and, unfortunately, not in the right place to be executed directly from the command line.

    Not sure how to correct this yet, but it certainly points to a problem with west execution in my particular macOS environment.  

    Not sure yet if all of the issues I've encountered are due to this one cause, but fixing it is certainly a good place to start.  I've noted that your online docs now(?) include some comments about use of venv in the Mac environment.  Would be great if you could get together with one of your Python experts to sort out what the proper nRF SDK installation procedures are in a complex Python environment.  I suspect this isn't just a macOS problem, just where we've first encountered it.

    I'll work from my end, but I'm neither a venv or asdf expert.  Just give me some suggestions and I'll try them out.  I suspect this will result in some extra cautions in the documentation or even changes to the installation code.

    Thanks,

    Mike

Children
Related