• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 51 subscribers
  • Views 2232 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Custom BLE Observer

Dan Lewis1
Intellectual 265 points
Other Parts Discussed in Thread: CC2541

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

  • 0
    TI__Genius 10955 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.

  • 0 in reply to hec
    Intellectual 265 points

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

    Thanks!