• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 350 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.

CC1352P: DMM priority- is it working?

radar
Expert 3540 points
Part Number: CC1352P
Other Parts Discussed in Thread: SYSCONFIG

Champs,

So I am building off of the dmm_wsnnode_ble_sp_app_CC1352P_2_LAUNCHXL_tirtos_ccs_syscfg base project from the TI SDK.  I can tell you it's been a long a winding road; but I have things working decently after a lot of work (because of my system; not your demo per se); but I have run into a snag that I could use some guidance on.  

The issue I think I have is that I don't think the DMM priority is working/being honored properly; or it's pilot error and I don't know what I'm doing.  What I changed was the table I found in dmm_priority_ble_wsn.c which I think I understood to be the thing the DMM uses to figure out what to do when 2 things compete.  

What I want to have happen is that the WSN/Sub1GHz network always have priority over the BLE.  Now I think that's not exactly going to work, because BLE was designed by committee and whilst it allows you to specify a number of missed connection events; no phone manufacturer seems to really let you specify any number other than 0.... but for the moment lets just focus on advertsiing, since for 99.8% of its life the product doesn't have a BLE connection.  So I want all my WSN activity to be higher priority than BLE- and if i miss an advertising event so be it.  This is what I set up:

/* Global Priority Table: BLE connection lower than WSN data */
StackActivity activityBLE_bleLwsnH[ACTIVITY_NUM_BLE*PRIORITY_NUM] =
{
/*do not change the activity order */
DMM_GLOBAL_PRIORITY(DMM_BLE_CONNECTION, DMM_StackPNormal, 80),
DMM_GLOBAL_PRIORITY(DMM_BLE_CONNECTION, DMM_StackPHigh, 170),
DMM_GLOBAL_PRIORITY(DMM_BLE_CONNECTION, DMM_StackPUrgent, 250),

DMM_GLOBAL_PRIORITY(DMM_BLE_CON_EST, DMM_StackPNormal, 100),
DMM_GLOBAL_PRIORITY(DMM_BLE_CON_EST, DMM_StackPHigh, 200),
DMM_GLOBAL_PRIORITY(DMM_BLE_CON_EST, DMM_StackPUrgent, 220),

DMM_GLOBAL_PRIORITY(DMM_BLE_BROADCASTING, DMM_StackPNormal, 70),
DMM_GLOBAL_PRIORITY(DMM_BLE_BROADCASTING, DMM_StackPHigh, 160),
DMM_GLOBAL_PRIORITY(DMM_BLE_BROADCASTING, DMM_StackPUrgent, 210),

DMM_GLOBAL_PRIORITY(DMM_BLE_OBSERVING, DMM_StackPNormal, 70),
DMM_GLOBAL_PRIORITY(DMM_BLE_OBSERVING, DMM_StackPHigh, 160),
DMM_GLOBAL_PRIORITY(DMM_BLE_OBSERVING, DMM_StackPUrgent, 210),
};

StackActivity activityWSN_bleLwsnH[ACTIVITY_NUM_WSN*PRIORITY_NUM] =
{
/*do not change the activity order */
DMM_GLOBAL_PRIORITY(DMM_WSN_RETRANSMIT, DMM_StackPNormal, 90),
DMM_GLOBAL_PRIORITY(DMM_WSN_RETRANSMIT, DMM_StackPHigh, 180),
DMM_GLOBAL_PRIORITY(DMM_WSN_RETRANSMIT, DMM_StackPUrgent, 240),

DMM_GLOBAL_PRIORITY(DMM_WSN_TRANSMIT, DMM_StackPNormal, 90),
DMM_GLOBAL_PRIORITY(DMM_WSN_TRANSMIT, DMM_StackPHigh, 180),
DMM_GLOBAL_PRIORITY(DMM_WSN_TRANSMIT, DMM_StackPUrgent, 240),

// DC testing; this was 90
DMM_GLOBAL_PRIORITY(DMM_WSN_RECEIVE, DMM_StackPNormal, 170),
DMM_GLOBAL_PRIORITY(DMM_WSN_RECEIVE, DMM_StackPHigh, 180),
DMM_GLOBAL_PRIORITY(DMM_WSN_RECEIVE, DMM_StackPUrgent, 240),
};

So I at least have all the DMM TX/RX higher for each priority level than the BLE advertising; though what I see happening is that BLE advertising packets are still interrupting my TX or RX events.  And from what I can tell; those advertising events are happening at exactly the 100ms advertising interval (+/- entropy); which would imply to me that they're not getting elevated to a higher level and being retried; lest they'd be temporally displaced by some time; it more seems to me  the DMM just isn't paying attention to this table (or again, pilot error)  Now I could go and set ALL the priority numbers for WSN higher than the highest BLE advertising number (or lower all the advertising priority numbers I guess); but I wanted an opinion first because my whole system has a lot of nodes; and changing it takes a little time/effort to debug again. 

BTW, if there were an API that would disable advertising and then one to re-enable it quickly; I could do that.  In my system, and I suspect  this is true of many customers systems; the WSN bandwidth/usage is really pretty low; mine for example only takes ~40ms out of every 30s; so if I just DIDN'T do that one advertisement that happened to potentially be in the way; it would be fine.

  • 0
    TI__Guru** 101450 points

    Hi,

    I will assign an expert to comment.

    In the meantime, can you specify which SDK version you are using?

    Thanks and regards,

  • 0
    TI__Guru 58425 points

    Hi Radar,

    Maybe you could elaborate a bit on the SysConfig side of your setup? There is no issues with priority from my experience, but the latest introduction of "StackActivity" complexes the DMM setup some what. You now have priority on two levels, application an stack. Shortly put, the final priority is application + stack.

    In some simple use-cases, you might not need any application priorities (application states) at all, you could simply rely on the StackActivity priorities, meaning there is no need to "jump states" in application.This is further described in the DMM User's Guide.

    The values you are toying with here is the priority weight applied based on the stack activity and urgency. This will add to any application state you might use. Take the BLE broadcasting weights for example, you can see that as soon as the urgency rise, it will triumph the normal WSN TX etc. As you do not control what the stack consider normal/urgent/high, you need to consider this when setting the priorities. For example, if you do not want any advertisements to interrupt the WSN side, put down broadcast priority for all three level of urgency so that they never win over the WSN.

  • 0 in reply to IUsedToBeARealPerson (M-W)
    TI__Expert 3540 points

    So.... maybe this is what's happening; though if it is then the entire notion of having the priorities seems somewhat less useful than I would have thought.  So I made the BLE broadcast priorities all really low; like 40/50/60 for low/med/high priority; and it made no difference whatsoever from the application/end use experience.  But I think I might see why now- it's because in order to do anything with the sub-1GHz piece, you have to go into/out of TX/RX at times (eg even your demo app does this; sends packet and waits for an ACK- I totally revamped all of that but it's not an uncommon use case).  But given that; as soon as you change the operation, which internally (not sure if this is CM3 or the the radio processor actually but either way)  I'm sure involves stopping one operation to load the next; it's looking at other things pending and so it can schedule something low priority in that small window.  AND once it starts (advertising at least); it runs to completion; so the fact that you had it at lower priority really made no difference from the "i needed operation not interrupted" perspective.  

    Now, the good news is, I found a workaround that works pretty well; so I'll post it here for the benefit of others.  This is most applicable when you have a WSN network that's similar to mine anyhow; wherein the sensor talks kind of infrequently and pretty small data chunks (which would be.... well, probably 99% of them).  But it was really easy to surround my WSN operations with a small bit of code that enabled/disabled BLE advertising; and that solves the issue; allowing my WSN network to operate unimpeded when it needs to talk/listen.  For the reader needing such a solution; be aware that generally your WSN task can't directly make BLE calls to enable/disable advertising (you might be able to fix this by registering the task with ICALL, but I didn't try); but its very simple to have your WSN task signal an event to the BLE SP task; response to that event in the BLE SP would be to enque a message; and the handler for said message then would enable/disable advertising with calls to  GapAdv_enable/GapAdv_disable as appropriate.  It's a little involved bu that's just how the BLE stack works in the TI SDK; but it is efficient and the entire call/message/enque/dequeu/enable takes less than a few hundred uS.

  • 0 in reply to radar
    TI__Guru 58425 points

    Hi Radar,

    The DMM actually aborts commands as needed, if a higher priority command wants to run, the low-priority one will get aborted when running. Without knowing how you re-vamped your application, it is hard to say why you are having your issues. A few things to consider is for example scheduling headroom. If you schedule new commands very close into the future, there might not be enough time for the radio to actually turn around, abort, re-patch (when needed) and start the new command. 

    If you want, feel free to reach out to me internally to share the project if you want a second set of eyes on it.