• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 770 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.

CCS/LAUNCHXL-CC1352R1: Combining Example code

spanky
Expert 2710 points
Part Number: LAUNCHXL-CC1352R1
Other Parts Discussed in Thread: CC1310

Tool/software: Code Composer Studio

Hi all,

I am trying to construct a project that combines concepts from a number of examples. Most of the example code in the subghz world is reasonably straightforward. Unfortunately I need to leverage the BLE example code, which is incredibly complex and fragile.

Here's what I want to do:
I have 2 devices plus a BLE phone - a remote cc1310, and a cc1352

The cc1310 is acting as a remote battery powered sensor and will transmit small packets via easylink to the 1352.

The cc1352 will receive the subghz packets, but I also want to allow concurrent BLE connections to this device. The 1352 has the dual mode manager, so this setup seems reasonable (although I'm having a rough time tweaking the example code to passively/perpetually listen for subghz and still advertise on the BLE)

I also want to do OAD via BLE to the 1352, and also upload a 1310 image to the 1352, which will then be OAD'd down to the 1310.

I have the following examples that need to be merged for the 1352:
    ble5_simple_peripheral_oad_offchip
    dmm_wsnnode_remote_display
And then
    rfWsnConcentratorOadServer

Each of these 3 example projects utilize a different linked project (the stacks for the BLE stuff and the tirtos for the concentrator). My thoughts are to start with the ble5_simple_peripheral_oad_offchip example as its stack project seems to be the most complex, and presumably covers the other 2 (?).

As far as modifications, I'm not quite sure where to start. My thoughts at this point are to have 2 "modes" on the 1352 - "normal" mode where the 1352 is listening for subghz packets and ble. When someone connects via BLE they would trigger "OAD" mode which would then spool down the normal mode (DMM) stacks and start up some fresh stacks with just the OAD code running in a single mode BLE. After some inactivity timeout, it would revert to normal mode.

Is that a reasonable approach?

Can the OAD code run in DMM mode? If so, how would one go about implementing that?

  • 0
    TI__Mastermind 23196 points
    Hello Spanky,

    I would start by understanding how all of these examples work by themselves and modifying them to do what you need them to do without concurrency. As far as to which one to start with, I would suggest to start with the ble OaD and WsnConcentratorOadServer ones as these are the most complex .

    As far as running OAD in DMM mode it should be possible to do. Let me do some digging and I will get back to you with more information on this.

    Regards,
    AB
  • 0 in reply to AB
    Expert 2710 points
    For simplicity (at least from my perspective given how fragile the example code is), it seems like it might be easier to leave the existing code in tact and just switch from one task to another. Unfortunately there is no shutdown code in the examples.

    Going through the ble5_simple_peripheral_oad_offchip code, it looks like the call to OAD_open() at the end of SimplePeripheral_init() (in simple_peripheral_oad_offchip.c) registers the service and gets things going. If I want to "stop" the OAD service, it "seems" I could just call OAD_cancel() and OAD_close(), but of course when I do that, the device stops advertising altogether. I would think the other characteristics and simple_peripheral service would continue to run, but the documentation is no help.

    dev.ti.com/.../group___o_a_d___p_r_o_f_i_l_e.html

    It does say you should only call OAD_open() once, but then what does OAD_close() do?

    On a side note, this functionality would also be useful as a security measure... i.e. press a physical button to enable OAD and disable OAD completely after some period.
  • 0 in reply to spanky
    Expert 2710 points

    Hi AB,

    Any luck investigating the DMM OAD? I switched over to the projectzero example because that appears to be a bit more straightforward. I still don't understand why so many files in CCS are linked straight to the SDK files and not copied.

    I managed to merge the projectzero and dmm_wsnnode examples and it seems to be "mostly" working. I can view and interact with the individual services... the problem is when I go to "sensor view" in the TI app, the project crashes and it looks like its from a Hwi with no decipherable information:

    [Cortex_M4_0] sFault: IMPRECISERR: Delayed Bus Fault, exact addr unknown, address: e000ed38
Exception occurred in background thread at PC = 0x00029e4c.
Core 0: Exception occurred in ThreadType_Task.
Task name: {unknown-instance-name}, handle: 0x20002c88.
Task stack base: 0x20002cf0.
Task stack size: 0x1000.
R0 = 0x00000000  R8  = 0x00000000
R1 = 0x00000008  R9  = 0x00000000
R2 = 0x00000006  R10 = 0x00008000
R3 = 0x0000ffff  R11 = 0x20002938
R4 = 0x00000001  R12 = 0x000240bd
R5 = 0x00000001  SP(R13) = 0x20003bc8
R6 = 0x00000000  LR(R14) = 0x00029e3f
R7 = 0x20003bf0  PC(R15) = 0x00029e4c
PSR = 0x61005000
ICSR = 0x00400803
MMFSR = 0x00
BFSR = 0x04
UFSR = 0x0000
HFSR = 0x40000000
DFSR = 0x00000001
MMAR = 0xe000ed34
BFAR = 0xe000ed38
AFSR = 0x00000000
Terminating execution...

  • 0 in reply to spanky
    Expert 2710 points
    Well, it looks like this is from my attempt at integrating the battservice code. It works fine in regular mode, but not with the DMM. If I comment out my call to Batt_AddService(), it works (or at least doesnt crash with the DMM when entering service explorer from the phone app... I have yet to fully confirm it actually works all around)