• Ok, I just spotted your other post and your original issue I believe could be that you're building for Linux natively and are then switching to a different device and are not cleaning the build:

    # building for linux
    make clean && make
    # get t he stuff you need for other builds
    source scripts/provision.sh ESPRUINOWIFI
    # YOU NEED 'make clean' IN HERE <======================

    Is it necessary to run the provision.sh script each and every time a build is desired?

    If you close the terminal window between times then yes. provision.sh sets up the environment variables for that terminal session, so if you close it, it you need to run that again.

    Obviously you can do things to make it permanent but then if provision.sh changes you get into all kinds of pain - so I figure it's best for the casual developer to just use provision.sh each time

  • Wed 2021.10.06

    'your original issue I believe could be that you're building for Linux natively and are then switching to a different device and are not cleaning the build:'

    Thank you for the analysis @Gordon.

    'could be that you're building for Linux natively'
    'then switching to a different device'

    I'm not entirely sure I'm performing the task referenced here. Just to be clear, I'm not intentionally changing the device for the nRF52840 build.

    Please (anyone) correct me if my understanding is incorrect, but all my commands are being entered inside the terminal window that is launched from the VSCode menu. My belief (as I'm sure I'm not fully understanding) is that WSL is the binding that allows a user to enter/execute Unix like commands on a DOS based PC. Kinda like a Unix virtual machine running inside it's own frame. (not sure if 'window' is a good choice of words for Unix) So, I don't believe I need a separate terminal window like the Putty app, just using the one VSCode provides.

    When you explain 'building for Linux natively' and should that mean creating the .hex file and then 'switching to a different device' is something I'm not (intentionally) doing.

    I was however during frantic now what the expletive do I do now sessions, did try combinations of clean and switching the provision scripts as that sequence did a couple of times seem to allow me to make progress. (errors changed and were never repeatable)

    The insight @fanoush observed seems to be what is happening based on my file write delay hunch.

    Over the weekend, I'll try that post #10 sequence with the additional step and make (no pun - okay pun) sure I repeat that exact sequence each time.

    Also, the additional J-Link adapter board arrived today so I'll have a chance to attempt the debug suggestions @fanoush provided, once I locate a brief operations tutorial and pin-out for the SEGGER board. I'll also play with the PATH environment var within the terminal window as my belief is that the update of nRFConnect has done somethong within the registry that when I launch a cmd window, VSCode and nRFConnect from a clean boot, the Win10 PATH environment var starts duplicating itself, running out of space, thereby corrupting it and blocking apps/processes from running cleanly. If I can get to the bottom of
    that, I'll post results. Leaving that here in case others stumble across similar issues as in this thread.


Avatar for Gordon @Gordon started