• State
  • Locked Locked
  • Replies 19 replies
  • Subscribers 52 subscribers
  • Views 2675 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.

CC2541 SPI Network Processor Power Savings Issue

Nathan Conrad
Prodigy 240 points
Other Parts Discussed in Thread: CC2541, CC2540, MSP-TS430RGZ48C, MSP430FR5969

Hello,

I am using a CC2541 with version 1.4 of the stack in SPI network processor mode with power savings enabled. I am using the HostTestRelease project CC2541SPI build configuration with near minimal modifications other than adding the GATT_DB_OFF_CHIP and SPI slave mode preprocessor configurations. The SPI slave configurations may have already been selected. The power source is derived directly from the battery with additional capacitance without an external DC/DC converter.

We've been seeing problems with the CC2541 draining batteries excessively when they should not be. We've narrowed it down to the point where it looks like if we do SPI transactions during a point of activity such as a advertising or connection event, the CC2541 does not return to low power mode as it should.

Below is the easiest example which I can replicate over of a period of about 10 minutes, but I am sure they may be other cases which cause a similar issue. In this example, I am making the device discoverable then ending discovery a couple seconds later (the time varies slightly).

I first do the standard initialization of the device and GAP and then run a cycle of enabling and disabling advertising. Each cycle, whether the CC2541 fails to enter low power mode or not, results in the exact same SPI transactions below:

  1. Send GAP Make Discoverable (0xfe06) with connectable undirected advertisements on all channels, a public address, and allowing scan requests from anybody.
    1. In hex: fe.0e.01.06.fe.0a.00.00.00.00.00.00.00.00.07.00.fa
  2. Receive a Command Status (0x067f) of success for opcode 0xfe06
    1. In hex: 00.fe.09.04.ff.06.7f.06.00.06.fe.00.75
  3. Receive a GAP Make Discoverable Done (0x0603) with a success status
    1. In hex: 00.fe.08.04.ff.05.03.06.00.0c.00.ff
  4. A few seconds later send a GAP end discoverable (0x0604)
    1. In hex: fe.04.01.08.fe.00.f3
  5. Receive a Command Status (0x067f) of success for opcode 0xfe08
    1. In hex: 00.fe.09.04.ff.06.7f.06.00.08.fe.00.7b
  6. Receive a GAP End Discoverable Done (0x0604) with a success status
    1. In hex: 00.fe.06.04.ff.03.04.06.00.fc

In these scope traces, you can see the normal operation. Channel 1 is the CC2541 current and the 3 SPI transactions in the zoom are the GAP End Discoverable command and responses as notated above.

Then about once every 10 minutes, at random occurance, we see an event like below where the CC2541 does not go to sleep. Every time this occurs, the SPI transaction occurs almost exactly where one would expect the next advertising event (100ms interval).


Because the SPI transactions are always the same, the network processor has no way of knowing this even occurred. To us, this indicates there is a problem with the either the power savings, SPI driver, or BLE stack on the CC2541.

Could you help us resolve this issue as it is a definite show-stopper for our product?

Thanks,
Nathan

  • 0
    TI__Guru** 105180 points
    Hi Nathan,

    We'll take a look and let you know if anything further is required.

    Best wishes
  • 0 in reply to JXS
    TI__Mastermind 34660 points

    Hello Nathan. Have you replicated this with TI hardware (SmartRF05 + EM, keyfob, etc)? Also, can you list all changes that you have made to the HostTestRelease project, especially the preprocessor definitions you are using?

  • 0 in reply to Tim C
    Prodigy 240 points
    Hello Tim,

    I added the hex and source for the CC2541. I would need to whittle down the external processor code MSP430fr59xx to get rid of all of our IP in order to get that to you. I am also triggering the cycles using a feature unique to our hardware which I would need to setup with a timer or something.

    I have replicated on our hardware as it was the easiest for the moment. We have CC2540 EMs available but not CC2541's. We also have sensor tags but getting at the SPI pins on that may be more difficult. We also have LSR TiWi-uB1 EMs which is pretty similar to the 2541 EM.

    For reference, in our configuration:
    MRDY/CS/SS = P0.4
    SRDY = P0.1
    CLK = P0.5
    MISO = P0.2
    MOSI = P0.3

    I will try to have our FAE set up a call so we can get on the same page.

    Thanks,
    Nathan
  • 0 in reply to Nathan Conrad
    TI__Mastermind 34660 points
    I compared your source code to the default 1.4.0 install and do not see anything that should be causing a problem.
    We have tested the SPI driver very thoroughly and until we can replicate this on TI hardware, I do not think there is a driver issue. I will attempt to set up a similar test to replicate this on the SmartRF05 + CC254x EM.
    At this point, this looks like either a hardware issue or a protocol / handshaking problem.
    Have you had your schematic / layout reviewed by TI?
    Also, can you send a logic analyzer capture of the entire SPI communication where this error occurs?
  • 0 in reply to Tim C
    Prodigy 240 points

    Hi Tim,

    We had our schematic and layout reviewed by TI before our last hardware revision.  There were some changes to the antenna and better grounding but the SPI wasn't a concern.  Our board is really small and the two processors are pretty close together.

    I find it suspicious that every single time this happens, the SPI transaction occurs around 100ms after the last advertising event.  To me, that makes it seem like there is some sort of race condition between the HCI and the BLE events.  It is hard to trigger on this event because the main thing going on to show it is happening is the current isn't returning to near zero.  It is also hard to trigger on a long pulse of current because every time we start advertising the CC2541 stays out of low power mode to start the low frequency oscillator for 400ms (https://e2e.ti.com/support/wireless_connectivity/f/538/t/404038).  The hex listed above was pulled using a Total Phase SPI analyser and there was no difference in the SPI for either good or bad cases.  If there was a problem with the handshaking I wouldn't expect the proper statuses and command responses to come back.  I will try to get a better scope capture that shows this though.

    Thanks again for your help,

    Nathan

  • 0 in reply to Nathan Conrad
    TI__Mastermind 34660 points
    Ok well I guess we can assume at this point that the SPI transaction / handshaking is correct then. We still need to replicate this on TI hardware or have you send us a set of your hardware in order to debug the problem.

    One thing you can do to provide another data point is to, upon initialization, send the HCI_EXT_MapPmInOutPortCmd to the CC2541 and capture the output with the SPI and current. This command will toggle the GPIO output on the pin you choose to be high on wake, and low upon entering sleep (based on what the software is setting). If this matches the error case you are seeing (current staying high), then there is definitely a bug as you are suggesting.

    You can find more info about this command in the HCI Vendor Specific Guide. Here is an example using P0_6:
    cc2541 rx: 01 12 fc 02 00 06
    cc2541 tx: 04 ff 05 12 04 00 12 fc
  • 0 in reply to Tim C
    TI__Mastermind 34660 points
    Also, when the error occurs, do you see the CC2541 eventually go back to sleep or does it stay awake infinitely?
  • 0 in reply to Nathan Conrad
    Prodigy 240 points

    Hi again Tim,

    Here is a trace of the SPI where the CC2541 did not sleep.  I verified manually that it matched the hex messages above.

    Thanks,

    Nathan

    no_sleep_spi.zip

  • 0 in reply to Tim C
    Prodigy 240 points
    I will try the PM pin thing.

    We've seen it stay awake for a really long time >30s at random times, however it hard to determine that from this example because it takes fast cycling to get it to occur and the next cycle will break the state.

    Nathan
  • 0 in reply to Nathan Conrad
    TI__Mastermind 34660 points

    I've set up a test to replicate this and have not been able to. I've attached the logic capture here. The exact case you are performing (SPI transaction at advertising event) occurs several times, for example at 31.006343 seconds. This is using your modifications to HostTestRelease. Note that the tx/rx signals are coming from the HCI Extension Extend RF Range command.

    Is this a sufficient test? If so, since I can't replicate this on TI hardware, can you? I think we need to prove this.

    The software to open this file can be found here: http://support.saleae.com/hc/en-us/articles/201589175

    /cfs-file/__key/communityserver-discussions-components-files/538/test-capture.zip

  • 0 in reply to Tim C
    Prodigy 240 points
    Tim,

    We too see cases where they collide and nothing bad happens, see our 3rd trace from the first post. What we don't see is it being anywhere other than around the expected interval event when it fails to sleep. Also when it fails to sleep we never see the Rx and Tx like your 31s case. Your 31s case looks like our 3rd trace to me.

    Few questions:

    1. Did you only run once? In our case it sometimes takes many more samples than this.
    2. Is there something weird going on with your handshake? Sometimes it looks like a command is started without SRDY being pulled. e.g. The 31s case.
    3. Is the sleep_n just the PM pin you mentioned? Have you tried a current measurement on the scope and looking for a break in the pattern?
    4. Can you get a hold of MSP-TS430RGZ48C and an MSP430FR5969? If so I can probably move my code over to that and a SmartRF5. Our FAE will be dropping one off sometime this week.

    Thanks again,
    Nathan
  • 0 in reply to Nathan Conrad
    TI__Mastermind 34660 points
    Hello.
    1. No I ran for around 30 minutes without issue. I'm also sending SPI data more frequently than you are.
    2. No, that is because my sampling frequency is too low to capture the SRDY toggle. This was so that I could get a long capture.
    3. Yes it is. No I haven't tried with an oscilloscope. The sleep pin will always match the current level. I was waiting to see if this was the case in your setup. Really all this would have done is pointed to a hardware issue if they didn't match. I can set up an oscilloscope when I get a chance.
    4. I can probably get a hold of these although I'm not sure how quickly.
  • 0 in reply to Tim C
    Prodigy 240 points

    Ok, thanks for the responses.

    I will go through everything one more time to make sure there isn't something hiding in plain sight.  Then I will move my exact code to the TI hardware mentioned, verify I can still reproduce.  If so, I'll whittle it down to the bare essential and verify.

    I'll let you know what I find along the way.

    Thanks,

    Nathan

  • 0 in reply to Nathan Conrad
    Prodigy 240 points

    Same issue with an MSP-TS430RGZ48C w/ MSP430FR5969 connected to an LSR TiWi-UB1 (pretty much a TI CC2541 EM).

    Nathan

  • 0 in reply to Nathan Conrad
    Prodigy 240 points

    Here's the other way we see issues:

    Advertising in general discovery with a 20ms interval.  Nothing going on with SPI.  The radio seems to hang on third Rx and the micro doesn't return to sleep at all.  This is an even more major issue for us.

    1. I'm guessing this is deep in the TI controller library/binary?
    2. Nobody else has seen anything like this?
    3. Any idea what could be the cause?

    Thanks again,

    Nathan

  • 0 in reply to Nathan Conrad
    Prodigy 240 points

    I forgot to mention that for the second issue, that trace came from our own hardware.  We are trying to reproduce on the eval boards now.  As such, I don't think we can rule out hardware for the second issue just yet.  I'll let you know if this changes.  In the meantime, if there are any known hardware conditions/definciencies which could cause something like this, it would be helpful for troubleshooting.

    Thanks again,

    Nathan

  • 0 in reply to Nathan Conrad
    Prodigy 240 points

    Occurred on the eval boards.  Will send code to reproduce via email

    .

    As you can see, it is happening on the Rx.  This time it occurred on the second channel, held for a while, finished the last channel, and neglected to sleep.

    Thanks,

    Nathan