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.

Power Mode Hang?

Other Parts Discussed in Thread: CC2541

I've had several CC2541 based devices that have gone faulty in the field, unable to connect.  After some weeks of operation these devices seem to stop advertising.

I've had a look at SWRZ014C and SWRZ022 errata notes for related chips.  They both describe a 'power mode hang' when the chip goes from sleep to active mode.  I'm wondering if this could be my problem.

I have managed to have a look at one on my failed devices and have found the external 32 kHz crystal running, but not the 32 MHz one, it appears to be stuck in low power mode.

1. Does the silicon in the CC2541 suffer the same power mode hang problem and if so have the suggested work arounds been implemented in the BLE stack?

2. Have the CC2541 and the BLE stack proved to be robust when running in power save mode over long time periods?

Thanks

Dan

  • Hello Dan,

    Did you determine the root causes for you issues with the devices in the field?

    Thanks,

  • No, not yet.  I've implemented the 'power mode hang' fix that's described in SWRZ014C and SWRZ022 errata notes.  Not sure if it applies to the cc2541 or not, would be nice to get input from the TI guys.

    But I've had a failure since then, required a reset to get it working again.  I've got 20 devices sitting on the bench, all working, at least since last Wednesday.  All except one. The one that failed is one of two that were potted, so I've no access to the circuit, only the programming connector.

    I would feel a lot happier if anyone could confirm that they've got the cc2541 running successfully over long periods of time using the low power mode as implemented in the TI sample code for the simple ble peripheral.

    Dan

  • Hi Dan,


    Sorry for the belated response on this. The issues described in the erratas you are referring to are fixed in the CC253x and 4x devices, so it is not necessary to implement the proposed work-arounds.

    What we have seen on the BLE devices is that the guard time when starting the 32 kHz oscillator was a bit short. This could in some situations cause problems when waking up from PM3 and then going to PM2 not too long afterwards. This is fixed in the latest release of the BLE stack (1.3.1), and also described in the readme file included in the stack.

    Could you please update to the latest stack release and see if this solves your issue. Alternatively you can implement the fix in your existing SW by inserting a 400ms delay when coming out of Power-On-Reset or PM3.

    Cheers,

    Fredrik

  • Thanks Fredrik,

    I'm not going into PM3, the device is always on, mostly just advertising at 2 second intervals.  I've had some 20 odd devices running on the bench without incidence for more than a week, the failure rate is fairly low, but seems to increase with time.  The ones that have failed are devices that have been in the field.  I suspect some issues with the clocks, but I'm not sure.  As far as I know, they have all failed when they've been in state where they're just advertising.  I know that a reset brings them back to life.

    I'm fairly happy with the layout of the clocks on the circuit board, I haven't ruled out capacitor values, but they currently conform to the specifications from the cc2541, maybe I have more/less stray capacitance than I've designed for.

    I would feel more confident that it's not a stack/silicon/software issue if anyone could confirm that they've had the chip running continually in advertising mode for long periods of time.

    Dan