• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 168 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-CC26X2R1: Start/stop BLE once booted and running, I.E. the "airplane mode"?

Marc Yaxley
Expert 1105 points
Part Number: LAUNCHXL-CC26X2R1


My client requires that the BLE stack be paused/stopped/muted when needed as

required by safety in mining applications around explosive devices.

I need in my application to be able to basically set an air plane like mode where the

transmitter is not turned on until an operator action in the GUI.  The receiver might

as well be turned off too.

I've scoured many doc's so far for BLE5.0 and not found any clear are talking about

this sort of ability.  I'm sure I'm not the first one needing this but so far have not come

up with the right forum search terms to pop out the details I need to know?

Please point me to the doc's and functions/code/demo/examples which would show

this radio muting function?

Thx, MY

  • 0
    TI__Guru** 101460 points

    Hi,

    Generally speaking, no RF operation should occur if the three following bullets are true:

    • no connection is active
    • no advertising is active
    • no scanning is active

    You can refer to the User's Guide for more details.

    Best regards,

  • 0
    Expert 1105 points

    Thanks for the reply.  Then you are stating that if I set these 3 'bullets', well more specifically stop

    the advertising active and scanning active modes using the BLE API there "should" be no RF TX

    emissions.  I'm not sure if I gave that explanation to my client (and thus the Coast Guard) this

    would be accepted as the statement is not 100% that RF emissions are prevented.  I was looking

    for either a software switch API or hardware bit that I could toss which would guarantee no RF emissions.

    I know the Cortex-M0 sub processor is actually in control of the radio hardware, isn't there a "mailbox"

    command which tells it to shut down and go into a hold pattern with it's activities?

    Can we be more specific and certain on this issue?

    Thanks in advance,

    Marc Y.

  • 0 in reply to Marc Yaxley
    TI__Guru** 101460 points

    Hi Marc,

    I may have sound a bit unsure of myself by choosing certain words (like "should"). However, you can take these affirmations as 100% sure. This is only my way of writing Slight smile 

    Let me provide a bit more details.

    • We strongly discourage to access the radio core (M0) directly when using the BLE stack
    • There is no way to pause or stop the execution of the BLE stack. In other words, the BLE stack is made to be started once and never stopped. If it works for you, you could consider reset the device and not start the execution of the BLE stack when you need to be in "Fly mode"

    I understand you need to prove to the authorities no RF signal will go out of the system when "fly mode" is enabled. So why don't consider one of the two options:

    • use an RF switch to disconnect the antenna in the case you need to be in fly mode.
    • turn off the CC26xx device when needed to be in fly mode

    To finish, I have a more "creative" solution for you (I haven't tested this myself). You could consider re-purposing the Coexistence (coex) feature of our stack. Using some smart ways, you could stop all the RF transmissions by setting a pin. I guess the application could handle this pin. I assume there might be some RF transmissions timeout to handle but it might worth trying.

    Best regards,

  • 0 in reply to Clément
    Expert 1105 points

    Thanks again for the reply and further information.

    I am thinking of taking the "reset" option you pointed out by using the WDT to cause a

    hardware reset which I assume would also reset the M0-radio CPU as well.  Then using

    a flag in one of my I2C EEP devices know that the reset was caused by my firmware and

    thus not start up the sort of tasks found in "ProjectZero_init(void)" which appear to configure

    and start the BLE services.  Once up, then clear that flag in EEP so next reboot will enable

    the BLE and possible OAD and user configuration data.

    I'm not sure what the M0 CPU is doing after booting when those functions that are

    in "ProjectZero_init(void)" are not called, I would think is just sits there mute waiting

    for initialization commands to be sent via. the M4 BLE side of the stack, which I would

    not call in this no RF transmission mode.

    As you recommend I do not want to even look at the M0 itself or mess with it directly.

    I'll also look into the "coex" subject, once I find where it is documented at in the PDFs.

    Cheers, Marc Y.

  • +1 in reply to Marc Yaxley
    TI__Guru** 101460 points

    Hi Marc,

    Your understanding is correct, the M0 does nothing by default.

    To be more specific, the tasks handling BLE (i.e. potentially triggering RF commands) are created by calling the function ICall_createRemoteTasks(). All the tasks get started when executing BIOS_start();

    However, by default, no BLE command can be sent by the application before executing ProjectZero_init() (or SimplePeripheral_init for simple_peripheral example).

    If needed, here the coexistence documentation. You may also want to review the corresponding SimpleLink Academy module.

    Best regards,