• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 3 answers
  • Subscribers 53 subscribers
  • Views 615 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.

CC2640: CC2640: Background details on fixed bugs in BLE Stack v2.2.2

Matthias Schmitt
Expert 5820 points

Part Number: CC2640

Dear all,

my customer is looking for more detailed descriptions on some of the fixed Bugs we refer to in the release notes.

Is there any chance to get more background details on the fixed bugs?

They are specifically interested in details on the following fixed bugs:

  • BLESTACK-1129
  • BLESTACK-1133
  • BLESTACK-2261
  • BLESTACK-2626
  • BLESTACK-1405

Thanks,

Best Regards,
Matthias

  • 0
    TI__Guru 57525 points
    Hi Matthias,

    I will provide the detail asap. I am curious why they are concerning about these in the production?
  • 0 in reply to Christin Lee
    TI__Expert 5820 points

    Hi Cristin,

    the customer wants to get an idea, if this bug fixes may help them to solve some issues in their system. Therefore they need to get a better understanding of the bug descriptions and fixes. So any details we can provide are highly appreciated.

    Thanks

    BR

    Matthias

  • 0 in reply to Matthias Schmitt
    TI__Guru 57525 points
    BLESTACK-1129: I think this one is fairly straightforward. Now the device should always comes back to standby after done with adv/connection events.
    BLESTACK-1133: ADV stops unexpectedly due to conflict with CM0 and CM3 when using simple_peripheral RCOSC build config
    BLESTACK-2261: The symptom after the failure is that osal_run_system keeps signalling the stack task because osal_qHead != NULL. And it stays like that, so no other tasks can run.
    BLESTACK-2626: Only applied to standalone controller in test configurations, did not apply to the full BLE stack
    BLESTACK-1405: There are two versions of ECC_initialize() that exist, one in driverlib which takes a single arg, and one in ble_sdk_2_02_01_18\src\rom\enc_lib. This caused sample apps using secure connections will not build out of the box on TI ARM Compiler versions later than 5.2.6

    Let me know if there is still anything not clear to you.
  • 0 in reply to Christin Lee
    Prodigy 30 points

    Hi Christin,

    we have currently the situation that the battery of some ble beacons (using ble stack 2.2.1) are already empty but we calculated much more lifetime of the ble beacons (based on precise current consumption measurements over 4h). I am interested in the issues which would increase the average current consumption unexpectedly over longer time:

    BLESTACK-1129: what was the percentage which it was not going to standby? when its not going to standby it was staying in idle?
    BLESTACK-1133: I think it would rather lower the current consumption, when it was happening, right?
    BLESTACK-2261: failure of which HW error? how often was it happening?

    Best regards,
    Musti

  • 0 in reply to user5084772
    TI__Guru 57525 points
    Hi,

    If the device is still functional just without short battery life, then BLESTACK-2261 is not the bug you have encountered.
    When the device enters the state described in BLESTACK-2261, the device is hang and only a hard reset can recover it.

    Your situation is most likely cause by BLESTACK-1129 and BLESTACK-1133.

    I would highly recommend you to migrate to the BLESTACK 2.2.2
  • 0 in reply to Christin Lee
    Prodigy 30 points

    Since the battery was already down and the device was still functional after battery replace, I think BLESTACK-2261 could still be a cause for our short battery lifetime situation. We also observed sometimes that data what we wrote before with osal_snv_write (with our configuration) could not be read anymore and fell back to the default configuration. Because of this I was asking more about BLESTACK-2261.

    Some of our beacons in the field will still run with BLESTACK-2.2.1 for a few months. I need first some analysis if an update to BLESTACK-2.2.2 will solve our problems or if there is still some other bug.

    Is there some known problem with osal_snv_read/write in BLESTACK-2.2.1+?

  • 0 in reply to user5084772
    TI__Guru 57525 points
    Hi,

    Did you do check in the software when you perform and osal_snv_write?

    I am not aware of osal_snv_read/write bug in BLESTACK-2.2.1.
  • 0 in reply to Christin Lee
    Prodigy 30 points
    osal_snv_read/write is checked with SUCCESS. if osal_snv_read != SUCCESS the default configuration is taken. What could be the reason that osal_snv_read/write returns sometimes not SUCCESS? could it be triggering somehow BLESTACK-2261?
  • 0 in reply to user5084772
    TI__Guru 57525 points
    The best to verify is to just move to the newest SDK. If we still have same problem, then we will be able to at least rule out the bugs in BLE 2.2.1.

    I am not able to give you an answer with respect to which bug is actually making the device draining more current.
    All the bugs you are wondering are fixed in BLE 2.2.2, so I would suggest moving to BLE 2.2.2 STACK.