Gazelle and BLE

Hello,

  I'm working up an application that uses BLE and Gazella with a 'base' device that typically operates as a gazelle host to communicate to devices and then at the push of a button switches the gazella off and starts up BLE advertising to communicate with a phone app via UART and then switches BLE off and UART on at teh push of another button.

  I've merged the BLE UART example and the gazella host example.  However I have a strange problem when I start advertising with BLE with the following kernel panic (remember that nrf_gzll_enable() has not been called)

:

ASSERTION FAIL [esf != ((void *)0)] @ WEST_TOPDIR/zephyr/arch/arm/core/aarch32/cortex_m/fault.c:1086
ESF could not be retrieved successfully. Shall never occur.
[00:01:59.438,659] <inf> app: Button 1 pushed
[00:01:59.438,690] <inf> app: Starting BLE advertising
[00:01:59.440,185] <inf> app: Advertising started
[00:01:59.440,277] <inf> app: BLE is initialised, taken from semaaphore, ready to write
[00:01:59.459,716] <err> os: ***** HARD FAULT *****
[00:01:59.459,716] <err> os: Fault escalation (see below)
[00:01:59.459,747] <err> os: ARCH_EXCEPT with reason 4

[00:01:59.459,777] <err> os: r0/a1: 0x00000004 r1/a2: 0x0000043e r2/a3: 0x00000001
[00:01:59.459,777] <err> os: r3/a4: 0x0001d179 r12/ip: 0x00000000 r14/lr: 0x000152ff
[00:01:59.459,808] <err> os: xpsr: 0x41000011
[00:01:59.459,808] <err> os: Faulting instruction address (r15/pc): 0x00026320
[00:01:59.459,869] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:01:59.459,899] <err> os: Fault during interrupt handling

[00:01:59.459,930] <err> os: Current thread: 0x200028e8 (unknown)
�*** Booting Zephyr OS build v3.3.99-ncs1 ***ng system

  The application has been paired down so that there is no gazelle initialisation (not even the headers are included) at all but it still does the kernal panic.  However if I remove CONFIG_GZLL=y & CONFIG_GAZELL=y from the proj.conf file then the BLE starts.  It seems that included these in the config is stopping the BLE advertising even when the gazelle is not initalised; note that this only happens when BLE advertising is started but I'm not surprised at that.  How can I have gazelle host and BLE running in exclusive modes - I don't need them running together but something is causing them to clash even when not initialised.

  Thanks.

Cheers,

Neil

Parents
  • Hi Neil,

    You cannot use two separate radio protocols at the same time, which it seems you are trying to do here. In order to use two radio protocols there needs to be a form of time sharing, and this can be accomplished by the MPSL timeslot API, but we do not have any samples demonstrating this with Gazelle.

    Is it OK for your device to reset between when switching states? If so a simple and clean solution would be to make a choice at boot, and initialize either BLE or Bluetooth, and reset when there is a need for switching. In that case you could write to GPREGRET before resetting, and read that back after reset to know which mode to boot up in, or you could store this in flash if the changes in mode are not frequent.

    Br,

    Einar

  • Hello,

      Thanks for your reply - the idea was to turn the Gazelle and BLE on and off at the push of a button so neither is active at the same time but I guess that even when disabled the radio is effectively 'used' by the protocol?  The code at the moment doesn't do anything at all with Gazelle but simply adding in the config to add Gazelle causes the crash.

      In terms of resetting we could do it, receive data from the BLE interface, write it to flash and then reset to gazelle, load it in from the flash and send it to the devices.  However the same issue applies here as simply adding in CONFIG_GZLL=y and CONFIG_GAZELLE=y along with the BLE config causes the crash above to happen even if Gazelle and BLE are not configured when I start BLE advertising.

      Is there a way to specify what configurations are loaded according to a flag? Also is there a way to simply turn the Gazella/BLE on and off or does simply including the config option setup the radio for that protocol?

    Cheers,

    Neil

Reply
  • Hello,

      Thanks for your reply - the idea was to turn the Gazelle and BLE on and off at the push of a button so neither is active at the same time but I guess that even when disabled the radio is effectively 'used' by the protocol?  The code at the moment doesn't do anything at all with Gazelle but simply adding in the config to add Gazelle causes the crash.

      In terms of resetting we could do it, receive data from the BLE interface, write it to flash and then reset to gazelle, load it in from the flash and send it to the devices.  However the same issue applies here as simply adding in CONFIG_GZLL=y and CONFIG_GAZELLE=y along with the BLE config causes the crash above to happen even if Gazelle and BLE are not configured when I start BLE advertising.

      Is there a way to specify what configurations are loaded according to a flag? Also is there a way to simply turn the Gazella/BLE on and off or does simply including the config option setup the radio for that protocol?

    Cheers,

    Neil

Children
  • Hi Neil,

    It turns out that this is a bit trickier than I thought. The gazell glue layer was not designed for multiprotocol and therfore just including Gazell in the project will cause problems with multiple ISR's for the same interrupt as it does not support dynamic  interrupts. To demonstrate this, you can comment out line 70 - 152 in nrf/subsys/gazell/gzll_glue.c from NCS 2.4.2, and your Bluetooth code should work again. 

    Though we have not implmeented it for Gaszell, you can see how dynamic interrupts can be done in the ESB implementation in nrf/subsys/esb/esb.c (search for CONFIG_ESB_DYNAMIC_INTERRUPTS).

    Einar

  • Hello,

      Thanks, I think this is going to be a bit complicated to mis protocols.  I assume that I'm better off just sticking to one protocol so I'll look into having the device work as a BLE central and peripheral and communicate with the sub devices via BLE from base unit to sub device - the reason I didn't want to do that was because I don't want to advertise the sub devices because it'll confuse the end users to see multiple bluetooth devices advertised when they only need one but I can always just refuse connections to anything except the base unit or try to setup some kind of direct advertising system.

    Cheers,

    Neil

Related