• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 51 subscribers
  • Views 455 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.

eHCILL problem: RTS high for > inactivity time & causes lock up of CC2564B (init script: v1.0 spec 4.1)

Matthias Ringwald
Expert 1475 points


Hi there. I've run into the following problem which looks like it's a bug/corner case in the eHCILL implementation of the current CC2564B 1.0 v4.1 implementation.

The sequences to trigger this is:

  • Bluetooth init, setup LE, wait for incoming connection. During service discovery the app does some debug output which causes RTS to be high for longer than the ehCILL inactivity timeout (default 100 ms as far as I know).

  • after inactivity timeout (default 100 ms), baseband controller should decide to go into sleep mode and send SLEEP_IND, but as the as RTS is still  high, it cannot start sending it

  • now, before the host release RTS, it starts sending an ACL packet (it didn't receive the SLEEP_IND yet)

  • after a few bytes of the outgoing data, hosts receives SLEEP_IND

  • hosts finishes sending packet

  • hosts sends SLEEP_ACK after the ACL packet

After this, no further communication arises as the host went into sleep mode, but the CC256x doesn't raise CTS.

Now.. here's another test. If the host waits after sending the packet for some time (it was 30 ms, but can also much longer), everything is fine and the CC246x later wakes the host again when it has data for it.

To me, it looks like receiving data after deciding to send SLEEP_IND gets the CC256x into some weird state, but it's interesting that a delay would help with it. Obviously, this wouldn't happen if the host wouldn't raise the RTS line for so long, but there's also no reasons why this shouldn't just work (without an addition delay).

I've integrated an additional delay into BTstack's HCI Transport implementation here for now: https://code.google.com/p/btstack/source/browse/trunk/src/hci_transport_h4_ehcill_dma.c

Here are logs from my Salea Logic 16 for both cases

(Logic is a free download for all platforms https://www.saleae.com/downloads): 

If needed, I can also provide other forms of debug output. If this is too detailed for a public forum, please contact me directly at matthias@bluekitchen-gmbh.com

Thanks!
  Matthias
  • 0
    TI__Mastermind 32615 points

    Hi,

    Thanks for the inputs.

    Could you please let me know why host is holding the RTS high, when the device is not in sleep mode?

    Do you mean you are not releasing the RTS, when there is a wakeup indication. Because when the host wants to send data first it has to wake up the controller (if in sleep mode), If not the RTS should be low.

    Please see http://processors.wiki.ti.com/index.php/CC256x_eHCILL_Low_Power_Protocol

  • 0 in reply to Sundeep Javvaji
    Expert 1475 points

    Hi

    in this particular setup, RTS was high while the app was doing some synchronous debug output (without any buffers, at 9600 as the dev board I was using didn't support faster debug output), so the RTS was high while the host was busy processing data and just not ready to receive data from the Bluetooth chip.

    So, the host is just busy and keeps RTS high while the controller might decided to enter sleep mode and would like to send the sleep indication.

    Thanks for the eHCILL link in the docu, I'm glad TI made it public eventually.

    Best

     Matthias