CC2642R: connection_monitor turns on Bluetooth broadcasting

Hi !

The connection monitor example uses the micro-BLE stack. Unlike the regular BLE stack, it has limited capabilities, which you seem to be aware of since you're specifying non-connectable advertising. You can find the documentation about this micro-BLE stack here : https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_8_32_00_07/docs/ble5stack/ble_user_guide/html/u-stack/overview.html

According to this documentation, you can enter the broadcasting state by using the ugap_bcastStart function. This function accepts a number of advertisements being sent before the micro-BLE stack automatically changes states is IDLE. This function is defined inside C:\ti\simplelink_cc13xx_cc26xx_source_sdk_8_33_00_16\source\ti\ble5stack\microstack\ugap.c

In practice, this means that you would call ugap_bcastStart, listen for a UGB_EVT_STATE_CHANGE event, and then call ugap_scanInit to enter the monitoring mode. Another option would be to call the ugap_bcastSetDuty function, which will advertise on and off.

Kind regards,
Lea

Question: uBLE Broadcaster (ugap_bcastStart) never transmits on CC26X2R1 / SDK 8.32 (RF_MULTIMODE)

Setup: CC26X2R1, simplelink_cc13xx_cc26xx_sdk 8.32.00.07, official connection_monitor example (Micro BLE stack), RF_MULTIMODE defined, FEATURE_ADVERTISER + FEATURE_BROADCASTER enabled. Flow per u-stack docs: ugap_bcastInit → uble_setParameter (ADVTYPE=ADV_NONCONN_IND, ADVINTERVAL=160, ADVCHANMAP=ALL, ADVDATA) → ugap_bcastStart(0).

Symptom: The state machine enters Advertising correctly, but the advertising command is never actually executed by the radio — no RF done/abort event ever arrives; only the uLL watchdog timer (cAdvInt) keeps expiring, so every event is reported as FAILURE, ~13 ms apart, and never SUCCESS.

What we already found and fixed locally:

uble.c: initializer .advData[UBLE_MAX_ADVDATA_LEN] is out-of-bounds (array has 31 elements) — fails to compile as soon as FEATURE_ADVERTISER is enabled.
ugap.c: broadcaster event dispatch still reads &(pEvtMsg->msg) while in SDK 8.32 msg is a pointer (monitor dispatch was migrated to dereferencing, broadcaster was not) — payload reads garbage.
ull.c: the ADV RF_scheduleCmd subscribes only RF_EventInternalError, so neither completion nor abort events ever invoke the callback (contradicts Table 36 in the u-stack user guide).
After the fixes above the symptom is unchanged: the advertising command scheduled via RF_scheduleCmd is never executed by the RF core. For comparison, Connection Monitor RX commands on the same handle use the same RF_scheduleCmd and work fine; if the same advertising chain is posted with RF_postCmd + TRIG_NOW it transmits correctly (visible on a scanner).

Question: Why is an advertising (TX) command never dispatched under the multimode RF scheduler? What is the correct way / required precondition to advertise with the documented uGAP API? If RF_scheduleCmd is not usable for advertising TX, what is the recommended approach to transmit ADV_NONCONN_IND every 100 ms?

Hi !

Could you try to change inside C:\ti\simplelink_cc13xx_cc26xx_sdk_8_33_00_16\source\ti\ble5stack\microstack\ull.c :

  urfiAdvHandle = RF_scheduleCmd(urfiHandle, (RF_Op*) &urfiAdvCmd[0],
                                 &cmdParams, ull_advDoneCb,
                                 RF_EventInternalError);

to :

  urfiAdvHandle = RF_scheduleCmd(urfiHandle, (RF_Op*) &urfiAdvCmd[0],
                                 &cmdParams, ull_advDoneCb,
                                 (RF_EventInternalError | RF_EventLastCmdDone | RF_EventTxEntryDone));

Kind regards,
Lea

Sounds great ! 

Would you be okay with sharing the code fix that you implemented so that we can solve this in the next SDK release ?