MKW41Z troubles using MWS module for BLE and GENFSK coexistence on same IC

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MKW41Z troubles using MWS module for BLE and GENFSK coexistence on same IC

1,210 Views
domenico_virgil
Contributor II

Hi everyone,

I have questions about running both BLE and GENFSK on same application and same IC, using MWS MCUXPresso SDK lib AND A FRDM-KW41Z dev board. The application works in this manner:

  • At start, both BLE and GENFSK layers are initialized, using Ble_Initialize() and GENFSK_Init(), GENFSK_AllocateInstance() APIs provided in MCUXPresso SDK 2.2.0 libs. The MWS default callbacks defined in BLE Link Layer and GENFSK Link Layer are both registered with MWS_Register() API.
  • The GENFSK configuration is GFSK_BT_0p5_h_0p5 radio mode at 250kbps datarate. BLE config is the default and only allowed BLE_MODE at 1Mbps datarate.
  • When you press a button, BUTTON 1, the application runs a TX/RX GENFSK sequences and exchanges data with another device, running the same firmware.
  • When you press another button, BUTTON 2,  the application changes it's behavior to BLE Perihperal mode and starts an advertising sequence, waiting for a connection from some device (i.e Smartphone, PC, etc.).
  • If you press again BUTTON 1, the application goes back to GENFSK mode and so on.

In order to make all stuffs working, I've followed this custom path, because no example is provided in SDK files:

  1. The application start mode is GENFSK mode.
  2. When switching from GENFSK to BLE mode, the high level custom Radio software sets idle it's state and than calls the MWS module functions MWS_Release(gMWS_GENFSK_c) and MWS_SignalIdle(gMWS_GENFSK_c).
  3. I've modified the MWS_GENFSK_Callback function in  "genfsk_ll.c" SDK file, which I think it's a bit incomplete because gMWS_Idle_c and gMWS_Init_c cases does nothing. In my custom version of the function, when the signaled event it's gMWS_Idle_c, it's first called a GENFSK_FreeInstance(mGenfskActiveInstance) function, which de-allocate the active GENFSK instance, and then the BLE arbitration bit is cleared with XCVR_MISC->BLE_ARB_CTRL &= ~XCVR_CTRL_BLE_ARB_CTRL_BLE_RELINQUISH_MASK; . When the event is gMWS_Active_c (triggered by MSW_Acquire() function), first it's called a GENFSK_AllocInstance() to create new GENFSK radio istance, then the BLE arbitration bit it's set with XCVR_MISC->BLE_ARB_CTRL |= XCVR_CTRL_BLE_ARB_CTRL_BLE_RELINQUISH_MASK, followed by a GENFSK_UnprotectFromXcvrInterrupt(); instruction .
  4. Before calling the Ble Avertising function, the XCVR module it's set IDLE by the following function:
    void Radio_XCVRIdle(){
          XCVR_TX_DIG->CTRL &= (XCVR_TX_DIG_CTRL_TX_DFT_EN_MASK | XCVR_TX_DIG_CTRL_LFSR_EN_MASK | XCVR_TX_DIG_CTRL_RADIO_DFT_MODE_MASK);
          XCVR_TSM->CTRL &= XCVR_TSM_CTRL_FORCE_TX_EN_MASK;
          XCVR_MISC->DTEST_CTRL &= ~XCVR_CTRL_DTEST_CTRL_DTEST_EN_MASK;
    }
  5. After this function call, the GENFSK is re-initialized at it's default values with 1Mbps datarate and then the Ble Advertising function it's called.

  6. When the radio is in BLE mode, the application runs a TMR interval timer that triggers an MWS_SignalIdle(gMWS_GENFSK_c) every 50ms. This is done because I noticed that the BLE LL releases the radio module after every BLE event, and if the GENFSK does not signal constantly that it's Layer is idle, the BLE LL never calls a MWS_Acquire() to take back the control, and a connection or communication on GAP/GATT Layers it's impossible.
  7. To turn back to GENFSK mode, every BLE event it's stopped by the application and the Radio is re-configured by a MSW_Acquire, witch re-allocate the GENFSK istance.

Now, even if this behavior works, there are two main problems:

  • Before using BLE module, the GENFSK configuration needs to be set to 1MBps datarate. If it remains to 250Kbps, when the Ble module takes the control, the advertising never works and the device is not discoverable by others. When the radio mode change, I've checked all XCVR and RSIM registers when the XCVR_ChangeMode() API it's called in the "fsl_xcvr.c" driver lib, but their values seems to be ok for both configurations, and the parameters are properly changed and re-initialized when the radio mode changes. However, the BLE works only if the GENFSK is set to 1Mbps before switch.
  • When the BLE is active, the GENFSK module have to constantly singal to MWS that the layer it's idle, in order to trigger an MWS_Acquire() by the BLE LL, otherwise the BLE is not working properly and never acquires the communication channel.

So my questions are:

  1. this is a correct way to implement a BLE and GENFSK coexistence or I miss something important? There is another way to do this stuff?
  2. Why I need to set 1Mbps datarate in GENFSK to allow BLE work properly, even if the XCVR it's re-initialized when the radio mode is changed?
  3. Why the BLE LL never acquires the radio module if the GENFSK LL doesn't call a MSW_SignalIdle() constantly?

Thanks for the help,

Domenico Virgilio

Labels (2)
0 Kudos
3 Replies

875 Views
estephania_mart
NXP TechSupport
NXP TechSupport

Hello, 

This example has not been implemented yet, so there is no guide on how to achieve that.

To develop it I would suggest you use one of the examples available as a base, remove the other protocol and add the necessary for the GFSK, it would seem that you are going on the correct path do develop it. 

Something important to notice it's that when using a hybrid example the radio will be multiplexing between Bluetooth LE and GFSK, so they can't use the radio at the same time. 

Regards ,

Estephania 

0 Kudos

875 Views
domenico_virgil
Contributor II

Still no news? Please, I really need help, it's a very urgent task.
Thank you.

0 Kudos

875 Views
domenico_virgil
Contributor II

Hi, any news?

0 Kudos