• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 242 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC1352R: BLE Observer + SubGHz proprietary stack: DMM not working

Lorenzo Venturelli
Intellectual 345 points
Part Number: CC1352R
Other Parts Discussed in Thread: SYSCONFIG

Hi,

I am developing a new device based on CC1352 MCU and SimpleLink SDK version 4.40.

I have developed a variety of application with this configuration in the past, implementing the TI DMM stack to support both our proprietary SubGHz stack (868 MHz radio used to communicate with our devices) and the BLE5 stack in Peripheral role, in order to interface with a smartphone. For this puprose the TI DMM stack worked just fine.

Now we are developing a product that will act as BLE beacon sniffer, so I am trying to change the BLE role from Peripheral to Observer, keeping the support for our SubGHz stack. I have tested the BLE Observer role in a separated project that only implement that funcionality (without TI DMM nor SubGHz stack) and it works perfectly.

However, when I implement it into my actual project, with TI DMM and SubGHz stack, it blocks (iCall spin forever) when I try to start the BLE scan. All the BLE initializations works with no errors but the scan blocks.

The method I call to start scanning is 

GapScan_enable(0, DEFAULT_SCAN_DURATION, 0);
  and in the test project work, actually starting the scan.

I would like to ask if there is any solution to keep both radio stacks working, eventually removing the TI DMM...

Thank you in advance.

Lorenzo Venturelli

  • 0
    TI__Mastermind 25810 points

    Hey Lorenzo,

    Can you provide some details on how you handle the BLE scanning? Have you created a new project or just modified the remote_display file? Have you modified any predefines in the project to enable the scanning side of things? If the feature is not enabled by the predefines, perhaps this is the cause of this error. At the moment I don't recall if SDK version 4.40 has SysConfig enabled. If it doesn't, then you essentially need to modify the predefine symbol HOST_CONFIG and add in CENTRAL_CFG as follows:

    /* BLE Host Build Configurations */
-DHOST_CONFIG=PERIPHERAL_CFG+CENTRAL_CFG

    I hope this helps. Please note that since this configuration is not provided in the SDK, it has not been tested and thus is not supported. That being said, you are free to try this out and I can help out (to an extent), where necessary.

    Lorenzo Venturelli said:
    I would like to ask if there is any solution to keep both radio stacks working, eventually removing the TI DMM...

    I don't think this is supported. DMM is essentially required to manage access to the radio especially when it comes to handling conflicting RF scheduling.

    EDIT: Added some explicit clarification.

  • 0 in reply to Ammar N
    Intellectual 345 points

    Hi Ammar,

    thank you for your answer. I have changed the predefines in order to have:

    -DHOST_CONFIG=OBSERVER_CFG

    as I am implementing the observer role.

    The scan is handled quite simply by initializing the GAP layer with:

    GAP_DeviceInit(GAP_PROFILE_OBSERVER, selfEntity, addrMode, &pRandomAddress);

    and then, after having initialized the HCI layer, with a call to:

    GapScan_enable(0, DEFAULT_SCAN_DURATION, 0);

    This call is the one which fail, trapping into ROM_spin function, that is a while(1) which blocks everything.

    As I said in the first post, this exact way to do things works in a modified "simple_central" project which I have used to test the scan behaviour (I have changed that project to Observer role through SysConfig).

    The main project do not use SysConfig for legacy reasons and it derives from dmm_simple_peripherals_wsn_node project.

  • 0 in reply to Lorenzo Venturelli
    TI__Mastermind 25810 points

    Hey Lorenzo,

    The reason we're seeing the ROM_spin is due to some unremoved simple_peripheral based API call that remains. It is likely trying to resolve the API to a symbol that is no longer define since we removed the PERIPHERAL_CFG.

    I would suggest trying to narrow down which API call in the init function is causing this behavior. As a temporary workaround to unblock your development, you can keep PERIPHERAL_CFG enabled and just add in OBSERVER_CFG.

    -DHOST_CONFIG=PERIPHERAL_CFG+OBSERVER_CFG