Erratic BLE, pairing problematic, connection flakey

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Renate
Level 3
Level 3
25 replies posted 25 sign-ins 10 replies posted

I've been working on this for a week, learned some, so let me restate my case. I'm using brand new, US big-name distributor, sealed CYBLE-012011-00 modules on two different perfboarded prototypes of different layouts.

I can program them with the downloaded hex file of EZ-Serial and they behave properly, visible under any OS, pair instantly. I have tried three different examples (only modified for switch/LED pin assignments) BLE_HID_Keyboard, BLE_HID_Mouse, BLE_Heart_Monitor. All of them program and verify correctly. All of them only pair with difficulty (hitting pair 50 times). All of the HID examples are not even visible under Windows. On the occasions that I have got the Keyboard to pair with Android it has worked functionally correct, but balky, with latency problems and the connection dropping. The power is good (batteries, different power supplies) and the layout keeps out of the antenna area. The distance is two feet.

What is going on? Could somebody post a hex file (with BLE) for the CYBLE-012011-00 so I can have a reality check? I'm running on the 3.66 BLE version, although I have tried 3.50 also. When I have added user parts to the code those parts have operated correctly within the constraints of the BLE part flakey.

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.
Renate
Level 3
Level 3
25 replies posted 25 sign-ins 10 replies posted

With all the trademark names flying around it's easy to overlook that a CYBLE-012011-00 is not just a PSoC4BLE but is also an EZ-BLE.

Since PSoC Creator knows the target that I am using, why can't it set this properly itself? Why is this critical info in an add-on KBA? I haven't run into anywhere where they spell out the exact meaning of "ECO".

So, I get it. The master 24 MHz crystal oscillator needs trimming of the parallel caps for startup, stability and frequency accuracy. I don't see any procedure for verification/testing  of these values.

Finally, the clock dialog uses a setting in picofarads. That's hard to correlate with the suggested hex values. Do I have to adjust in pF, build, check what hex values it's using then circle back until I get it right? Apparently.

Edit: For the CYBLE-012011-00 suggested value of 0xbcbc, use 17.8 pF, 17.8 pF

The conversion uses two overlapping ranges depending on the MSB. The lower range is pf = hex/10+3.7 The upper range is pf = hex/10-1.0

View solution in original post

0 Likes
3 Replies
Renate
Level 3
Level 3
25 replies posted 25 sign-ins 10 replies posted

Ok, jolly joke on me.

For older BLE components, the ECO capacitance trim values were automatically set in the generated source, hence all the projects worked as expected. It is mandatory to manually set the ECO capacitance trim value in the firmware or clock settings...
 
case CYBLE_EVT_STACK_ON:
    CY_SET_XTND_REG32((void CYFAR *)(CYREG_BLE_BLERD_BB_XO_CAPTRIM), 0xBCBC);

 

Yes, that's the correct stuff for CYBLE-012011. I love the explanation that the ECO capacitance trim trims the value of capacitance for the ECO. Maybe tell us what the heck oscillator, what frequency and why? Does the wrong value cause off-frequency or a PLL to not lock up? And why isn't this set in our "EZ" examples, or at least a warning or a comment?

Edit: I can't find any mention of this in the TRM. I find that the previous value gets set in cyfitter_cfg.c:

CY_SET_REG32((void *)(CYREG_BLE_BLERD_BB_XO_CAPTRIM), 0x00002D6Au);

Where do they get that value and why?

If this is such a big "gotcha" and a show-stopper why isn't it more documented? Why isn't it more known?

Wouldn't it be better to correctly set this value before the PLL locks up? Hmm?

0 Likes
Yugandhar
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 5 likes given

Hello,

ECO capacitance trim is required to supply the correct capacitance load to achive 0 ppm for the ECO. By default, the ECO capacitance trim values are set to the trim values of PSoC 4 BLE/PRoC® 4 BLE modules. If any other BLE module is used (such as, EZ-BLE module), the trim values should be changed to the values provided by that module’s datasheet. Please refer to the Page 12 in BLE component datasheet.
Please refer to the below KBA for CAPTRIM value of ble modules.
https://community.cypress.com/t5/Knowledge-Base-Articles/ECO-Capacitance-Trim-Values-for-EZ-BLE-Modu...

Thanks,
P Yugandhar.

0 Likes
lock attach
Attachments are accessible only for community members.
Renate
Level 3
Level 3
25 replies posted 25 sign-ins 10 replies posted

With all the trademark names flying around it's easy to overlook that a CYBLE-012011-00 is not just a PSoC4BLE but is also an EZ-BLE.

Since PSoC Creator knows the target that I am using, why can't it set this properly itself? Why is this critical info in an add-on KBA? I haven't run into anywhere where they spell out the exact meaning of "ECO".

So, I get it. The master 24 MHz crystal oscillator needs trimming of the parallel caps for startup, stability and frequency accuracy. I don't see any procedure for verification/testing  of these values.

Finally, the clock dialog uses a setting in picofarads. That's hard to correlate with the suggested hex values. Do I have to adjust in pF, build, check what hex values it's using then circle back until I get it right? Apparently.

Edit: For the CYBLE-012011-00 suggested value of 0xbcbc, use 17.8 pF, 17.8 pF

The conversion uses two overlapping ranges depending on the MSB. The lower range is pf = hex/10+3.7 The upper range is pf = hex/10-1.0

0 Likes