• State Verified Answer
  • Locked Locked
  • Replies 29 replies
  • Subscribers 74 subscribers
  • Views 7179 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 282289
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

"Couldn't find Zephyr root" both SEGGER and VsCode

Mr.Newlove

Hello all,

Lost my VM that had a working installation and just setting everything back up.

After installing SDK 1.8.0 and all of the extensions for VsCode. Now both SEGGER and VSCode cannoot find the Zephry root and I cannot find it on disk?

This was not a problem in the past, any ideas?

Thanks

Edit: Another problem... like all of the examples are missing?? searched for serial_lte_modem and it comes up with nothing. Even just searching serial, or application comes up with nothing useful?

Edit2: I installed the most recent 3 releases and none have a zephyr folder anymore?!?!?

Parents
  • 0

    From your root application folder in a bash, can you successfully perform a:

    west flash --erase
    ?

    Mr.Newlove said:
    Yea, pretty non-specific. What I have been doing is creating a folder in the same project called "Boards" and then creating a new board called "basic_serial_modem_ns" using the board wizard. I can record a video of this whole process tomorrow if that helps?

    Yes, that would be great. I have tested to create a custom board based on the nRF9160 non-secure myself with the wizard in VS Code. I stored it in my_root_application\boards and it seems to work fine, so no ”The system cannot find the file specified” here. I get build errors for sure, but they are expected without any modifications of the board files itself.

    That might not help you too much at this point, but at least it seems to look like that this approach should work.

    Mr.Newlove said:
    Another issue I ran into today is I can't seem to get the GPS to actually report a location, but I was waiting until our fully assembled boards to show up since the one I am working with I hand-assembled and I have had nothing but issues because its really hard to get a perfect solder job by hand with the 9160 chip

    Regarding this issue I would like to ask you to create a new case when relevant, as this might go a little bit too far off topic.

    Regards,

    Markus

  • 0 in reply to Albrecht Markus Schellenberger
    Albrecht Markus Schellenberger said:
    From your root application folder in a bash, can you successfully perform a:

    user@DESKTOP-END89DQ MINGW64 /c/ncs/MyApps/serial_lte_modem_uart0_gps
$ west flash --erase
-- west flash: rebuilding
[0/21] Performing build step for 'spm_subimage'
ninja: no work to do.
[1/5] Performing build step for 'mcuboot_subimage'
ninja: no work to do.
-- west flash: using runner nrfjprog
-- runners.nrfjprog: mass erase requested
Using board 960031669
-- runners.nrfjprog: Flashing file: C:\ncs\MyApps\serial_lte_modem_uart0_gps\build\zephyr\merged.hex
Parsing image file.
Verified OK.
Applying pin reset.
-- runners.nrfjprog: Board with serial number 960031669 flashed successfully.

    And the nrf9160 is not talking, but if I flash using the Programmer v2.1.1 desktop app from the SDK it works fine?

    Here is the log from that:

    10:15:49.270	Recovering Application core
10:15:52.814	Recovering Application core completed
10:15:52.816	Device recovery completed
10:15:52.816	Writing procedure starts for Application core
10:15:52.960	Writing HEX to Application core
10:15:53.297	Uploading image through JLink: 0%
10:15:56.303	Uploading image through JLink: 100%
10:15:56.497	Writing HEX to Application core completed
10:15:56.497	Writing procedure ends for Application core
10:15:56.499	Resetting device
10:15:57.121	Resetting device completed
10:15:57.124	Using @nordicsemiconductor/nrf-device-lib-js to communicate with target via JLink
10:15:57.124	JLink OB firmware version J-Link OB-K22-NordicSemi compiled Jul 2 2021 10:44:28
10:15:57.124	Device family NRF91
10:15:57.125	Device version NRF9160_xxAA_REV2
10:15:57.125	Board version PCA10090
10:15:57.126	Modem detected
10:15:57.126	Loading readback protection status for Application core
10:15:57.552	Readback protection status: NRFDL_PROTECTION_STATUS_NONE
10:15:57.997	Parse memory regions for Application core
10:15:57.999	Device is loaded and ready for further operation

    5270.merged.hex

    If it is helpful, this is the compiled and working hex file

    Albrecht Markus Schellenberger said:
    Yes, that would be great. I have tested to create a custom board based on the nRF9160 non-secure myself with the wizard in VS Code. I stored it in my_root_application\boards and it seems to work fine, so no ”The system cannot find the file specified” here. I get build errors for sure, but they are expected without any modifications of the board files itself.

    I will get this recorded sometime today, bit preoccupied atm.

    Albrecht Markus Schellenberger said:
    Regarding this issue I would like to ask you to create a new case when relevant, as this might go a little bit too far off topic.

    Yea, I am pretty sure its my fault anyway.

Reply
  • 0 in reply to Albrecht Markus Schellenberger
    Albrecht Markus Schellenberger said:
    From your root application folder in a bash, can you successfully perform a:

    user@DESKTOP-END89DQ MINGW64 /c/ncs/MyApps/serial_lte_modem_uart0_gps
$ west flash --erase
-- west flash: rebuilding
[0/21] Performing build step for 'spm_subimage'
ninja: no work to do.
[1/5] Performing build step for 'mcuboot_subimage'
ninja: no work to do.
-- west flash: using runner nrfjprog
-- runners.nrfjprog: mass erase requested
Using board 960031669
-- runners.nrfjprog: Flashing file: C:\ncs\MyApps\serial_lte_modem_uart0_gps\build\zephyr\merged.hex
Parsing image file.
Verified OK.
Applying pin reset.
-- runners.nrfjprog: Board with serial number 960031669 flashed successfully.

    And the nrf9160 is not talking, but if I flash using the Programmer v2.1.1 desktop app from the SDK it works fine?

    Here is the log from that:

    10:15:49.270	Recovering Application core
10:15:52.814	Recovering Application core completed
10:15:52.816	Device recovery completed
10:15:52.816	Writing procedure starts for Application core
10:15:52.960	Writing HEX to Application core
10:15:53.297	Uploading image through JLink: 0%
10:15:56.303	Uploading image through JLink: 100%
10:15:56.497	Writing HEX to Application core completed
10:15:56.497	Writing procedure ends for Application core
10:15:56.499	Resetting device
10:15:57.121	Resetting device completed
10:15:57.124	Using @nordicsemiconductor/nrf-device-lib-js to communicate with target via JLink
10:15:57.124	JLink OB firmware version J-Link OB-K22-NordicSemi compiled Jul 2 2021 10:44:28
10:15:57.124	Device family NRF91
10:15:57.125	Device version NRF9160_xxAA_REV2
10:15:57.125	Board version PCA10090
10:15:57.126	Modem detected
10:15:57.126	Loading readback protection status for Application core
10:15:57.552	Readback protection status: NRFDL_PROTECTION_STATUS_NONE
10:15:57.997	Parse memory regions for Application core
10:15:57.999	Device is loaded and ready for further operation

    5270.merged.hex

    If it is helpful, this is the compiled and working hex file

    Albrecht Markus Schellenberger said:
    Yes, that would be great. I have tested to create a custom board based on the nRF9160 non-secure myself with the wizard in VS Code. I stored it in my_root_application\boards and it seems to work fine, so no ”The system cannot find the file specified” here. I get build errors for sure, but they are expected without any modifications of the board files itself.

    I will get this recorded sometime today, bit preoccupied atm.

    Albrecht Markus Schellenberger said:
    Regarding this issue I would like to ask you to create a new case when relevant, as this might go a little bit too far off topic.

    Yea, I am pretty sure its my fault anyway.

Children
No Data
Related
Terms of service