peripheral_hids_keyboard sample: Different flashing behaviour in Vscode vs Ozone

Hello,

I am using nRF Connect 2.5.2 with a Xiao Seeed BLE Sense nRF52840 and Jlink EDU mini

I am trying to flash the peripheral_hids_keyboard sample with Ozone, and I immediately hit a hard fault (escalation of a fault with configurable priority that cannot be handled)

I can flash the peripheral_hids_keyboard sample using Vscode (nrfjprog / West) and debug successfully.  I can even flash with Vscode and attach to process with Ozone.

Ozone also worked fine to flash other samples (lsm6dsl)

I am confused why Ozone can't flash the peripheral_hids_keyboard sample, and what Ozone is doing differently than Vscode / nrfjprog

Thanks!

Parents Reply Children
  • Hi Benjii,

    Benjii519 said:
    But then why do breakpoints in vscode work? How are the two setups different?

    This depends on where you set the breakpoint. If you set it into time sensitive tasks, for example

    err = bt_le_adv_start(adv_param, ad, ARRAY_SIZE(ad), sd,
                      ARRAY_SIZE(sd));

    you will get hard fault.

    Benjii519 said:
    Where working state is: I can see the LED flashing, attach VScode debugger + verify),

    Do you define working as programming firmware into a device? LED means LED5 here?

    For VS Code debugger, when you start the debugger, it will start download immediately. Make sure there is no another debugger already running.

    For debug with Ozone, it supports download a firmware to do debugging(Debug->Start Debug Session->Download & Reset Program) or you can "Attach to running program" already start by VS Code debugger. 

    Just let me know if I have any misunderstanding. I can try to repeat the issue on my side.

    Best regards,

    Charlie

  • Ok! I had some time to dig further into this over the last few days and I've figured it ou.

    There were two issues. 

    The first issue: vscode was not flashing correctly over jlink (and Ozone was). This was due to the default board settings. Updating the config with these settings resolved that:

    CONFIG_BUILD_OUTPUT_UF2=n
    CONFIG_USE_DT_CODE_PARTITION=n
    The second issue: Ozone hard fault after resuming a breakpoint. This was the issue that you pointed out. It doesn't happen in VCS because monitor mode debugging is used. If I enable that in Ozone, I get the same behavior (no hard fault)
    Exec.Command ("SetMonModeDebug = 1");
  • Related