• State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 67 subscribers
  • Views 3090 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 104434
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
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

Problems with event handling and having ble_evt_dispatch called

Mike Wirth

Folks,

Sorry if I'm just being boneheaded here, but have been fighting with a couple problems while migrating my app on nRF51822/"C0"/SDK 4.2.2/S110 5 to nRF51822/"G0"/SDK 6.1.0/S110 7.1.0.

App worked fine before, e.g., Advertising started, responded to a Connection attempt (from an iOS app), Connected and sent Notifications to the phone just fine.

Now, after migrating to the new environment (and adding some app timers, etc. -- sorry for the possible sources of error :-) I'm having trouble in two main places:

  • If I try to run "power_manage" after starting Advertising (with a call to sd_app_evt_wait();), the MCU goes into such a deep sleep that Advertising is cut off.
  • If instead I go into a polling loop, waiting for a connection, Advertising happens as expected. But when Central (the iOS app) attempts to connect, I never get a call to ble_evt_dispatch, even though it was passed during stack enable to softdevice_ble_evt_handler_set(ble_evt_dispatch); without error.

Note: I've checked to see if I've initialized any peripherals which might have generated "pending" interrupts (i.e., without properly calling sd_nvic_EnableIRQ, but I don't think so.

Any hints on what I'm missing here?

Thanks,

Mike

Parents
  • 0

    Petter, et al,

    "DS" is a bit of Mac lore from the early days of the MacsBug debugger, and stands for just what you expected, a "Deep S##t", unrecoverable error :-)

    Our app started out with the LED/Button example code in nAN-36, with the earlier versions of the SDK (4.4.2) and S110 (5.2.1, IIRC). Added another (BLE standard) profile and specialized the proprietary profile in the LBS app for our purposes; added a bunch of other app code. So it didn't seem to be practical to restart from an SDK 6.1 sample app (and the nAN-36 LBS app hasn't been updated either).

    The good news is that the problem(s) which caused me to submit this question are now gone (after doing a code scrub to make sure all references to SDK BLE routines, etc., are to the current library, removing some now unnecessary UART port switching code, etc.) The second above problem using a polling loop was my error :-) Didn't make sure that app_sched_execute was being called often enough.

    So out of the weeds for now and making progress on debugging my BLE services and characteristics. Let's consider this item closed.

    Lessons learned:

    • Migrating across chip versions, SDK versions, and Soft Device versions was a relatively painful process. Lot's of time spent "in the weeds" (low level crashes and hangs with misleading symptoms).
    • Sure would have been nice to have better diagnostic tools and/or feedback here.
    • Failing that, better docs, including issues and their resolution that other people encountered would be useful.
    • An update to nAN-36 to keep it current with chip/SDK/SD releases would have been very useful. (I still have to scrub our modified version of the LBS proprietary service -- having some service discovery issues with it, as sensed by the LIghtBlue app on iOS.) And while you're at it, some improvements in nAN-36 would also be appreciated -- less ad hoc detail (replace these three lines with...) and more discussion of the context and relevance of the changes.

    Thanks,

    Mike

Reply
  • 0

    Petter, et al,

    "DS" is a bit of Mac lore from the early days of the MacsBug debugger, and stands for just what you expected, a "Deep S##t", unrecoverable error :-)

    Our app started out with the LED/Button example code in nAN-36, with the earlier versions of the SDK (4.4.2) and S110 (5.2.1, IIRC). Added another (BLE standard) profile and specialized the proprietary profile in the LBS app for our purposes; added a bunch of other app code. So it didn't seem to be practical to restart from an SDK 6.1 sample app (and the nAN-36 LBS app hasn't been updated either).

    The good news is that the problem(s) which caused me to submit this question are now gone (after doing a code scrub to make sure all references to SDK BLE routines, etc., are to the current library, removing some now unnecessary UART port switching code, etc.) The second above problem using a polling loop was my error :-) Didn't make sure that app_sched_execute was being called often enough.

    So out of the weeds for now and making progress on debugging my BLE services and characteristics. Let's consider this item closed.

    Lessons learned:

    • Migrating across chip versions, SDK versions, and Soft Device versions was a relatively painful process. Lot's of time spent "in the weeds" (low level crashes and hangs with misleading symptoms).
    • Sure would have been nice to have better diagnostic tools and/or feedback here.
    • Failing that, better docs, including issues and their resolution that other people encountered would be useful.
    • An update to nAN-36 to keep it current with chip/SDK/SD releases would have been very useful. (I still have to scrub our modified version of the LBS proprietary service -- having some service discovery issues with it, as sensed by the LIghtBlue app on iOS.) And while you're at it, some improvements in nAN-36 would also be appreciated -- less ad hoc detail (replace these three lines with...) and more discussion of the context and relevance of the changes.

    Thanks,

    Mike

Children
Related