• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 535 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 Advertises OK but does not respond

Tony Green1
Prodigy 165 points
Other Parts Discussed in Thread: CC2541

We are using CC2541 based Pan1721 module in a lighting application.  It works well 99% of the time, but we have occasional issues where we cannot connect to a device that appears to be advertising OK.  It will run OK for weeks but when this occurs we can no longer connect and  have to cycle power to reset the device.

We are using stack version 1.3.1. We use the UART extensively, and the SPI port.  It is a mains powered application so POWER SAVING is disabled.  It is a module so we should not have crystal/timing issues.


Are there any known issues with the stack that could cause this issue?  Any known issues with the Panasonic BLE modules based on the CC2541?
The problem is very intermittent but may be triggered by a disconnect from the client iPad app??

Any thoughts?

Regards


Tony

  • 0
    TI__Guru** 105180 points
    Hi,

    Given that the problem is so infrequent, it may be difficult to make a conclusion from the description. Also, since you are not enabling sleep / PM, you are removing a lot of complexities that exist with connections. Have you verified that your RF / RX path is in spec?

    Perhaps others who have used this Panasonic module can chime in. I would also suggest moving to v1.4.0, although I don't have any specific fix in that release that addresses the issue as you have described it.

    Best wishes
  • 0 in reply to JXS
    Prodigy 165 points
    Thanks for responding quickly JSX.

    The module has an on board antenna and Panasonic have approved our PCB layout to I think we're OK with the RF/RX path. The issue doesn't seem to be range related either.
    Still trying to get a unit to 'hang' with the debugger attached so that I can offer a bit more relevant information. Is there anything in particular I should be looking for?
    I will port our code to v1.4 but its not an insignificant task, and offers limited chance of any improvement and it also requires significant investment in a new IAR license. Can v1.4 be successfully compiled on IAR ver.8.10?

    Cheers

    Tony
  • 0 in reply to Tony Green1
    Genius 4470 points

    Hi Tony,

    How did you verify that device is advertising OK? Please check whether device is actually advertising or not using BLE Packet Sniffer.

    Thanks,

    Dhaval

  • 0 in reply to Dhaval V
    Genius 4470 points
    Hi Tony,

    Did you get any lead on this issue? Please update.

    Thanks,
    Dhaval
  • 0 in reply to Dhaval V
    Prodigy 165 points

    We still don't know the exact cause, but we replaced the UART interrupt routines with polled UART routines and the problem disappeared.  We concluded that the a coincidental UART interrupt event was preventing the BLE stack from disconnecting cleanly, and although it continued to advertise correctly no connection could be established.

    The occurrence of the 'lock-up' was rare but enough to spook our client into a product recall.  We would still like to learn the exact mechanism of the fault if anyone can shed any further light on the issue.  Unfortunately it proved very difficult to recreate the issue on the bench with the cc debugger attached, so its all still a bit of a mystery.

    Best Regards

    Tony