• Join
  • Sign In with my.TI Login
Texas Instruments
  • Products
  • Applications
  • Tools & Software
  • Support & Community
  • Sample & Buy
  • About TI
Sample & Purchase Cart Sample & Purchase Cart
  • Search
  • Advanced
TI E2E™ Community
  • Support Forums
  • Blogs
  • Groups
  • Videos
  • 简体中文
  • More ...
TI Home » TI E2E Community » Support Forums » Low Power RF & Wireless Connectivity » Low Power RF Bluetooth® Low Energy & ANT Forum » Custom BLE Observer
Share
Low Power RF & Wireless Connectivity
  • Forums
  • Announcements
  • Files
  • E2E Wiki
Options
  • Subscribe via RSS

Custom BLE Observer

Custom BLE Observer

This question is not answered
Dan Lewis1
Posted by Dan Lewis1
on May 21 2012 16:45 PM
Prodigy95 points

We have a specialized application for which the standard BLE stack cannot be used. 

I'm trying to set up the CC2541 radio in proprietary mode to receive advertiser packets.  I'm using chapter 25 of the CC253x/4x User's Guide (SWRU191C) for guidance.

My RF normal and RF error ISRs are working.  Tested with CMD_PING and with an illegal command.

  • My advertiser is working, sending an advertisement 1x/second.
  • My observer is working.  It works fine with the TI Simple BLE Observer and sees my advertiser.
  • The device is RX only.  After setting up interrupts and initializing the radio, I send a CMD_RX.

Settings pertinent to a receive only configuration:

  • PRF_CHAN set to 0x17 or 0x2F or 0x65.  (Channel 37/38/39)
  • PRF_TASK_CONF configured for Basic mode, variable length.
  • PRF_PKT_CONF, set AGN_EN == 0.  Also tried with AGN enabled.
  • PRF_CRC_LEN set to 3.
  • PRF_CRC_INIT set to 0x00555555.
  • PRF_W_INIT set to channel number | 0x40 per BLE spec.
  • PRF_RADIO_CONF set to 0x11;
  • Registers set per Table 25-24.  I also tried alternate values for FRMCTRL0 / MDMCTRL2 / MDMCTRL3 that appear to be used by the LLE mode.
  • SW0..3 set to 0x8E89BED6.

However, the device never obtains Rx sync.

Using the Simple BLE Observer in the debugger, I can see that the BLE stack sets up some of the XDATA registers differently for LLE mode.  In LLE mode, the RAM register area is used very differently; for example, 0x6000 (PRF_CHAN) contains the channel number, not the FREQ (f - 2379) frequency.  I can't find any other clues besides the SWRU191C User's Gude.  I've gone through the User's Guide repeatedly and can't figure out what I'm missing.

Any suggestions?  Is there any additional documentation or other resources available for proprietary mode?

Thanks

CC2541 proprietary mode radio
Report Abuse
  • Reply
You have posted to a forum that requires a moderator to approve posts before they are publicly available.
All Replies
  • hec
    Posted by hec
    on May 22 2012 03:38 AM
    Expert8040 points

    The proprietary mode radio on CC2541 can not be used to receive BLE packets with variable length, as the length field for BLE is located differently compared to proprietary mode. However, you should be able to sync to the BLE packets. If you really need to use proprietary mode to receive BLE packets, you will need to set a fixed length, and then strip off the end of the packet, doing the CRC check in software after receiving the packet. However, if possible, you should try to find another solution to your problem. If you give some more detail on what you want to achieve, we could try to advice you on the best way of doing this.

    The reason why you don't sync to the BLE packets could be that you have not set up any of the PRF_ADDR_ENTRYx registers. You must set PRF_ADDR_ENTRY0 even though you don't use an address byte. You need to set PRF_ADDR_ENTRY0.CONF.ENA0 to 1 and PRF_ADDR_ENTRY0.RXLENGTH to the length of the packets when you use fixed length (for variable length, you will need to set the maximum length, but as I said, variable length will not work for receiving BLE packets).

    As you said, to receive BLE packets, you will need different values from what is given in Table 25-24: FRMCTRL0 = 0x40; MDMCTRL2 = 0x00; (0x40 will also work). You may use MDMCTRL3 as suggested in Table 25-24, or the reset value, which is 0x60. MDMCTRL0 should be at the reset setting, 0x04, which you probably figured out already.

    You should not use AGC; it is only recommended for 2 Mbps.

    To make your SWx setting clear (the byte order is not clear from your statement), you need  to set SW0 = 0xD6; SW1 = 0xBE; SW2 = 0x89; SW3 = 0x8E;.

    Since you need to configure fixed length, the CRC calculation will normally not work. But if you know the length of the advertising packets, you can make it work. In that case, you need to set PRF_CRC_INIT to 0x55555500 (byte 0 to 0x00 and byte 1, 2, and 3 to 0x55), as opposed to what you wrote. THE BSP_Px registers should have their reset values.

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Dan Lewis1
    Posted by Dan Lewis1
    on May 22 2012 17:45 PM
    Prodigy95 points

    That's all it was.  I set up PRF_ADDR_ENTRY0 and now it's receiving valid packets.  Awesome.

    Thanks!

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
TI E2E™ Community
  • Support Forums
  • Blogs
  • Videos
  • Groups
  • Site Support & Feedback
  • Settings
TI E2E™ Community Groups
  • TI University Program
  • Make the Switch
  • Microcontroller Projects
  • Motor Drive & Control
Other Communities
  • Deyisupport
  • Designsomething.org
  • beagleboard.org
  • TI on Element 14
  • TI on TechXchangeSM
Other Technical & Support Resources
  • WEBENCH® Design Center
  • Product Information Centers
  • Technical Documents
  • TI Design Network
  • TI Technical Articles
  • TI Training

All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

Follow Us Texas Instruments on Facebook Texas Instruments on Twitter Texas Instruments on LinkedIn Texas Instruments on Google+
TI Worldwide | Contact Us | my.TI Login | Site Map | Corporate Citizenship | mobile m.ti.com (Mobile Version)

TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs and
embedded processors, along with software, tools and the industry’s largest sales/support staff.

© Copyright 1995-2013 Texas Instruments Incorporated. All rights reserved.
Trademarks | Privacy Policy | Terms of Use