Hi,
I am using a 9160-feather which has been re-flashed with Zephyr Tools VSC extension (Windows OS and nRF-5340-DK as programmer)
Application works perfectly, but it no longer can work on battery : as soon as the USB is unplugged, the board is powered off.
The NRF_PS_EN signal is not active, so I suspect the mcuboot has been corrupted and I tried to re-flash with the simple blinky sample.

Up to now, this was not successful : I can re-flash but the behavior in case of USB disconnection is the same …

I would have a question about the CMakeLists.txt of the sample:
It seems that the condition in the CMakeLists.txt to add custom overlay settings in case of circuitdojo_feather_nrf9160ns is never hit (should it be 9160_ns or 9160ns ?)
I tried to change that, but in this case the build process loops indefinitely.
Any idea ?

PS: I’ve another board which behaves correctly, but its bootloader hasn’t been re-flashed up to now

    jft7 what version of NCS are you using?

    It’s very likely that you simply need to recompile with the correct bootloader to hold the PE_EN signal high. Also it only works if you have not modified the corresponding jumper (which I assume you have not modified) and you have nothing connected to PS_EN.

    • jft7 replied to this.

        jaredwolff
        The versions are:

        NCS 1.7.1
        Circuit Dojo Zephyr SDK Tools v0.1.17
        https://github.com/circuitdojo/nrf9160-feather-examples-and-drivers V1.7.x

        It seems that building+flashing a sample corrupts the boot (tested with blinky)

        The PSE jumper has not been modified.

        The board name is not correct in the CMakeList.txt sample, but fixing it to add .overlay for mcuboot makes that build never completes under Windows
        I am going to investigate further

            jft7 on NCS 1.7.x and beyond the board is renamed to circuitdojo_feather_nrf9160_ns. Make sure you’re building with the correct target.

              yes i have already corrected the name of the board in the CMakeList.txt and am building for the correct target.
              As stated just before, in this case the build process goes into an indefinite loop … just never ends.
              Until now the incorrect name in the CMakeList.txt caused this problem to be hidden, the application was built and worked fine … and the boot was also operational except that PS_EN was not handled.

                jft7 typically you do not set the board name within the CMakeLists.txt. That gets provided as an external parameter to west. The plugin does this automatically. That could be a problem right there.

                One thing you can also do is run a Zephyr Tools: Clean which removes your build folder. This often fixes weirdness like this.

                • jft7 replied to this.

                    jaredwolff
                    Of course I understand that the board name is not “set” in CMakeList.txt, but I’ve to fix the name in this file to match the correct name sent by the plugin.

                    Anyway, I think the problem is now solved.
                    For an obscure reason,
                    ’list(APPEND mcuboot_DTC_OVERLAY_FILE
                    “${CMAKE_CURRENT_LIST_DIR}/../../shared/conf/mcuboot/circuitdojo_feather_nrf9160ns.overlay”)'
                    doesn’t work under windows, and causes cmake to loop (but it’s OK under linux)
                    To fix that, I copied “mcuboot/circuitdojo_feather_nrf9160ns.overlay” in the sample directory and modified the line as follow:
                    ’list(APPEND mcuboot_DTC_OVERLAY_FILE
                    “${CMAKE_CURRENT_LIST_DIR}/mcuboot/circuitdojo_feather_nrf9160ns.overlay”)'

                    And now build process is OK, I’ll check tomorrow with our app and I’ll keep you informed.
                    Once again, thank you very much for your help

                        Of course I understand that the board name is not “set” in CMakeList.txt, but I’ve to fix the name in this file to match the correct name sent by the plugin.

                        Ahh ok

                        jft7 And now build process is OK, I’ll check tomorrow with our app and I’ll keep you informed.
                        Once again, thank you very much for your help

                        You are very welcome. Let’s hope it’s smooth sailing from here. 😆

                          4 months later

                          Since this is a bit off topic and and an old thread I’m going to close this up. But feel free to open up a new post if you have any other questions!

                          Terms and Conditions | Privacy Policy