• State Verified Answer
  • Replies 7 replies
  • Subscribers 75 subscribers
  • Views 3251 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 200704
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Softdevice assert: 4097:190958:256 by trying to adapt SDK for Mesh v1.0.1 light-switch demo to MtConnect05

PopradiArpad

Hi,

I know that MtConnect05 is not a Nordic product but it contains a nRF52832

and these questions are about SDK for mesh usage.

The questions:

1. What does this assert log mean?

It happens at the first or second time I write '0' to RTT
in advertiser_packet_send (see pics for the backtrace).

The provisioning and configuring works.

2. It seems it's a kind of timing problem, but what could it be?

Thanks,

Árpád

P.S:

I put the code on Github if somebody would like to play with that.

I adapted the SDK for Mesh v1.0.1 by creating and using new board (mtconnect05.h, BOARD_MTCONNECT05)
using SERVER_COUNT 1 and simplifying the button handling in main.c.
mtconnect05.h reconfigures all buttons to the same free slot GPIO 14. BUTTONS_NUMBER is 1.

The code is at
github.com/.../light-switch-mtconnect05.git on branch mtconnect05-board.

I use Segger Embedded Studio with

  • examples/light_switch/server/light_switch_server_nrf52832_xxAA_s132_3_1_0.emProject
  • examples/light_switch/client/light_switch_client_nrf52832_xxAA_s132_3_1_0.emProject

project files.

The project files are assigned to dedicated JLink serial numbers.

Reproducing:
1. Fire up two Segger Embedded Studio one for the server, one for the client.
2. Adapt the JLink serial numbers to your ones. (In Project explorer > right click on the project > Edit options > JLink > Host connection)
3. In the Client IDE: Bring up the Breakpoint window and disable the HardFault breakpoint to let catch the hard fault.
4. Set breakpoint to nrf_mesh_sdk.c line 113 in softdevice_assert_handler
5. Start Client code
6. Start Server code

  • 0

    hello PopradiArpad,

    I believe that you are running into the general debugging issue with Bluetooth and halt mode debugging. Of the RF protocols, Bluetooth in particular, has extremely sensitive timing requirements which means that it is very difficult to single step debug through various sections of application code without affecting radio operations. The softdevice has most likely asserted due to this. Most people run to breakpoints whilst in halt mode debug to ensure that timing issues are minimized.

    In order to entirely overcome the issue, you will have to enable monitor mode debugging (MMD) which is a feature of the Cortex-M3/M4 (and therefore will not be available if you are debugging an nrf51 chip). From the screenshots that you provided, it looks like you are using the nrf52832 so it's supported on that. The following link provides some basic details on MMD functionaility.

    The Nordic Blog also has some practical guidance on setting up MMD with SES, see here...as well as here... (there are a couple of blog entries that are unavailable/404 since the migration to this new devzone branding so i haven't been able to link to those)

    Finally, from your screenshots, you appear to be using ubuntu/linux as your development platform and there are licensing issues which you would need to be aware of (since the on-board nrf52x jlink MMD evaluation only covers Windows I believe). Please review the following link to determine your requirements on that front. (https://devzone.nordicsemi.com/f/nordic-q-a/27363/monitor-mode-debug-w-nrf52840-ses-3-3-sdk14-1-0-ble-s140/108073#108073)

    Post back if you need any additional details on the MMD front or clarification of the above.

    Regards,

  • 0 in reply to leonwj

    Hi leonwj,

    thank you for the info about Monitor Mode Debugging, I didn't know it.
    I will use that but in this case that is not problem.

    The issue even happens without any breakpoint set.

    I set up the breakpoint only to get more information about what it causes.
    Step 3 and 4 have only that purpose.
    Without Step 3 the breakpoint set to the assert handler (Step 4) doesn't come.

    So the breakpoint is set within the softdevice_assert_handler and comes
    only when the software already crashed.

    Best,

  • 0

    Hi,

    What are the values for "id", "pc" and "info" passed to softdevice_assert_handler(), and does it consistently assert with the same values? (You can figure out the values by mouse over, or read from the "locals" debug window which you can enable from the "view" menu or by Ctrl+Alt+L.)

    Regards,
    Terje

  • 0 in reply to tesc

    Hi tesc,

    it asserts with the same values reproducibly. You can read them from the second image I sent. (last line in the debug terminal).

    Best,

    Árpád

  • 0 in reply to PopradiArpad

    Hi tesc,

    you are right the logged values are not the same as the ones detected by the debugger:

    Here are the decimal values by mouse over:

    id: 0

    pc 190958

    info: 2

    Best,

    Árpád

    P.S What causes the difference?

Related
Terms of service