Blinky w/ JLink Unable to Find Bootable Image

I recently got my Segger JLink Ultra+ working with the nRF tool suite but after programming my Thingy:53 dev board once it no longer boots correctly. Prior to using the JLink I was using the DFU programming over USB without issue but the need for real time debugging pushed me to the JLink approach.

Currently I've gone back to the blinky application under the Zephyr samples in the SDK folder. I'm using SDK v.2.4.0 and am able to build the blinky application for the thingy53_nrf5340_cpuapp_ns without issue. The problem comes after I flash or debug.

The code bootloader code apears to hit this section and fail:

    if (FIH_NOT_EQ(fih_rc, FIH_SUCCESS)) {
        BOOT_LOG_ERR("Unable to find bootable image");

        mcuboot_status_change(MCUBOOT_STATUS_NO_BOOTABLE_IMAGE_FOUND);

#ifdef CONFIG_BOOT_SERIAL_NO_APPLICATION
        /* No bootable image and configuration set to remain in serial
         * recovery mode
         */
        boot_serial_enter();
#endif

        FIH_PANIC;
    }

The above code is from the file "C:\ncs\v2.4.0\bootloader\mcuboot\boot\zephyr\main.c"

When the system hits this conditional fih_rc = 357913941

From stepping through the code it looks like the "context_boot_go" panics because the boot_swap_type somehow ends up being BOOT_SWAP_TYPE_PANIC. This seems to occur in the file "C:\ncs\v2.4.0\bootloader\mcuboot\boot\bootutil\src\loader.c" around line 2234

What could be causing the bootloader to not find the blinky image? Is there something I need to erase or clear or reprogram? I'm stuck and this is really stalling out progress on my project.

Parents
  • Hello,

    Are you adding DFU support for your Blinky sample or is this happening just with the sample from the SDK? If you are adding the DFU support could you tell me whatever changes you have made to the main application. If you have followed any guide like this please let me know .So that I will get more idea on what's happening on the Application side.

    Prior to using the JLink I was using the DFU programming over USB without issue but the need for real time debugging pushed me to the JLink approach.

    Does that mean you were using nRF connect programmer App for flashing the Thingy53 and was working fine?

    I want to make sure that it's not an issue with the improper installation of SDK and toolchain manager. I hope you have followed all the steps mentioned in this tutorial. Have you tried flashings any other sample and ended up successfully?

    Kind Regards,

    Abhijith

  • Here is another data point. I tried flashing the precompiled peripheral_LBS example from the thingy53 downloads I linked in another post.

    I used the nRF Programmer v3.0.9 with my Segger Jlink Ultra+.

    When I flashed the "merged_CPUAPP.hex" and "merged_CPUNET.hex" from the 2023-06-09 version of the precompiled examples, I get no flashing light showing that it's running which is similar to the behavior I originally posted about.

    However, when I flashed the "merged_CPUAPP.hex" and "merged_CPUNET.hex" from the 2023-03-24 version of the precompiled exmamples, the board flashes it's LED and appears to be working correctly. I can view it in the nRF Connect Iphone app as well.

    As far as I am aware the only difference between these precompiled examples is the toolchain version. The version that isn't working is using V2.4.0 of the SDK and the version that is working is using V2.3.0 of the SDK. I wonder if something in the lastest version of the SDK doesn't work with the Thingy53 platform.

  • Hello,

    zachwork said:
    I wonder if something in the lastest version of the SDK doesn't work with the Thingy53 platform.

    I don't think there is any change with latest SDK. But can you once update the thingy53 with the Edge impulse Application(default thingy FW)      that comes in the nRF programmer mobile Application?

    You can follow the steps mentioned here. i.e nRF programmer mobile Application-->Edge Impulse-->Install-->Select you device.

    After the proper FW updation try flashing the samples using the segger Jlink .

    Kind Regards,

    Abhijith 

  • This works. If I update the software via BLE or over USB using the DFU image then I don't have the issue and the system operates correctly if it was operating correctly before.

    Once I program the Thingy:53 system with any build made with the SDK v2.4.0, whether it's a precompiled example or and example I compiled myself, I get the bootloader panic issue.

    This happened to my coworker as well using an nRF52840DK as a JTAG to program the Thingy:53.

    You should be able to recreate my issue if you use program a Thingy:53 board via JTAG with a build from SDK v2.4.0.

    I'm not sure the root cause but v2.3.0 doesn't appear to cause this issue.

Reply
  • This works. If I update the software via BLE or over USB using the DFU image then I don't have the issue and the system operates correctly if it was operating correctly before.

    Once I program the Thingy:53 system with any build made with the SDK v2.4.0, whether it's a precompiled example or and example I compiled myself, I get the bootloader panic issue.

    This happened to my coworker as well using an nRF52840DK as a JTAG to program the Thingy:53.

    You should be able to recreate my issue if you use program a Thingy:53 board via JTAG with a build from SDK v2.4.0.

    I'm not sure the root cause but v2.3.0 doesn't appear to cause this issue.

Children
Related