• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 52 subscribers
  • Views 1270 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.

CC2540: Certification under ETSI EN 300 328 Blocking Test

Harold Lind
Prodigy 110 points
Part Number: CC2540
Other Parts Discussed in Thread: CC2640

We have a product based on the CC2540 processor.  We would like to get it certified in the EU, but there is an RX Blocking test that is required.  I have been researching this and also have the CC2640, which I can connect an XDS200 to and perform the test directly from the SmartRF 7 Studio.  But it is my understanding that the CC2540 does not have direct access to the radio (like you do with the CC2640), so this test cannot be accomplished with the SmartRF Studio.  I am also familiar with the various RX/TX Modem tests that can be performed with the CC2540, but the RX Blocking does not appear to be implemented in those tests.

Is there a way to modify the FW to perform the RX Blocking test and report the error packet % for a given BLE frequency?  I know I can get the error packet back with an HCI call, but it appears that you must be connected to a central device in order to get the info, which is lost after disconnecting the device.

Does anyone have examples on how this might be accomplished?  Or is the CC2540 unable to perform this test and therefor not certifiable in the EU?

Thanks,

Harold M Lind

  • 0
    TI__Guru**** 317180 points
    By using a CCDebugger you can access the radio on CC2540.

    As processors.wiki.ti.com/.../How_to_Certify_your_Bluetooth_product point out, the method described in
    www.ti.com/.../swra536.pdf can also be used for CC254x.
  • 0 in reply to TER
    Prodigy 110 points

    I had tried that before and it didn't work.  I am trying it again.

    I have our device connected to the ccdebugger.  It is a cc2540.  I launch the SmartRF Studio 7 (2.9.0).

    I select 2.4GHz.  I can see in the list of devices I have CC Debugger (USB device ID=0943, FW version 0044).  I am connected.

    In the Device Control Panel I have:

    Whitening off.  BLE Channel set to 0.  Frequency shows up as 2404MHz. 

    Packet RX tab is selected.  Sequence number not selected.  Access addr at 0x71764129.  Expected Packet Count 100.

    I click start and see the packet animation between tx and rx.

    Not receiving anything.

    Then I have another CC2540 device that can run the modem tests.  I have it set to a duration of 60 seconds.  Channel 0.  Running the TX Direct Test Mode.  Payload type PRBS15.  Payload size 37.

    I start the test and the device transmits for a minute.  But the other device that is running the RX test on the SmartRF 7 never receives anything.

    I did this same test with another device we have that is cc2640 based (with the xds200).  When I had it as the receiver and did the same DTM TX test from a cc2540, it was able to see the packets.

    Can you see if I am doing anything wrong?  Or if you need more information.

  • 0 in reply to Harold Lind
    TI__Guru**** 317180 points
    When you do the test with CC2540 as receiver, what do you use as TX?
  • 0 in reply to TER
    Prodigy 110 points

    For transmitter I am using another cc2540 using the DTM modem test.  Payload type PRBS15, payload size 37.  I went back and connected to my xds200 on the cc2640 and ran the RX Packet Test on the SmartRF Studio 7 on channel 10.  Infinite.  And when the cc2540 started transmitting, I saw the packet count start going up on the SmartRF display.  So the cc2640 on xds200 works with the cc2540 as TX.

    I went back and connected to the cc2540 as RX packet on channel 10 and did the same test, but got nothing.

    What is the Access Addr for?  It is set to 0x8E89BED6 on the cc2540 and 0x8e89bed6 (the same) on the cc2640 test as well.

    Thanks,

  • 0 in reply to Harold Lind
    Prodigy 110 points

    One other thing I wanted to mention was the connection from the ccdebugger to our device (cc2540).  The EE's created a custom connector on our device.  It is only 5 pins.  The pins are VCC, DC, DD/Key, RESET, and Gnd.  Not sure if that is enough to flash the device, but needs other pins to perform the RX/TX testing with the SmartRF Studio 7.

    Do you think that is possible?

    Thanks,

  • 0 in reply to Harold Lind
    TI__Guru**** 317180 points
    According to fig 6 in www.ti.com/.../swru197h.pdf 5 pins is enough. I have to check with someone with more BLE knowledge about what you see.
  • 0 in reply to Harold Lind
    TI__Guru 56590 points

    Hello Harold,

    The Access Address is equivalent to the radio sync word and is explained in the Bluetooth Core Spec section 2.1.2  Access Address.

    Try to use PRBS9 for the wanted signal and PRBS15 for the interferer. HCI_DIRECT_TEST_PAYLOAD_PRBS15 does not seem to be implemented in CC254x BLE stack.

    From BT Core spec:

    4.1.7  Reference Signal Definition

    A Bluetooth modulated interfering signal shall be defined as:

    Modulation = GFSK

    Modulation index = 0.32±1%

    BT= 0.5±1%

    Bit Rate = 1 Mb/s ±1 ppm

    Modulating Data for wanted signal = PRBS9

    Modulating Data for interfering signal = PRBS15

    Frequency accuracy better than ±1 ppm.

  • 0 in reply to Eirik V
    Prodigy 110 points

    Hi,

    I have a few things to ponder on this issue:

    First, actually, the PRBS15 and PRBS9 options are available for use on the CC2540.  I can see the constants defined in the source (unless it's defined but really doesn't work).

    I was finally able to get the CC2540 to see packets in RX Packet mode on the SmartRF Studio 7 application, though it wasn't the way I had intended:

    I had started out trying to use another CC2540 to transmit the packets on specific BLE channels.  I had written the modem test software prior to the EU cert for USA FCC certs.  It had TX Transmit, TX DTM, and Continuous DTM.  On the first two I could specify the channel.  The continuous appears to transmit on all channels arbitrarily.  On the DTM, you can specify the packet format (PRBS15, PRBS9, and others).

    I had tried to perform the testing on various channels, mostly on 10, but the receiving CC2540 never received the packets.

    As I had said before, when I had the CC2640 running with the SmartRF Studio with RX Packets, it would receive the packets from the above transmitting CC2540.

    As I also said, I had my RF analyzer in waterfall mode and saw the frequency stripe in the correct position for the frequency when transmitting with the CC2540.

    Here's what worked:

    I used the CC2640 on the studio in TX Packet mode.  Channel set to 10.  When I ran that, the CC2540 in RX Packet mode on channel 10, it was able to see the packets.  In looking at my RF Analyzer, I didn't see the channel 10 band, even though I had the CC2640 device sitting on my receiver antenna.  So not sure why that was happening.  It also worked on the channels that would actually be used in the EU cert, 37 and 39 (2402/2480MHz).

    So one question is if the CC2640 is in TX Packet mode on studio transmitting on channel 10, why don't I see that band on the waterfall of  my RFA?  Is it not only transmitting on 10?  It didn't look like it was transmitting at all, actually.  So strange.  Though the CC2540 which was probably about 4 inches away from the CC2640 transmitter was receiving the packets.

    So anyway, I think I am in business, just not sure why some of the above was happening.  One other thing, which is probably explainable, is with subsequent testing on the CC2540/CC2640 setup, it stopped working.  I had to reboot the BLE processors and restart the studio application.  Not sure if the devices kind of get hung up and need to reboot or what.  Has anyone else seen this?  Kind of like when you do an OAD download on the CC2540 dongle, you have to reset it, or you will have trouble performing normal HCI commands to BLE devices.

    Thanks for your help.