CC2640R2F: Frequency offset failure

Hi Aichi,

Which package size are you using 7x7 or 4x4?

Best regards,

Bun

we are using CC2640R2FRHBR，these fail IC date code is 2307/2310

The customer is asking these questions too:

The Date Code is 2324, is that safe to use?

Hi Aichi,

If the customer is using a differential (4XD) configuration, please flash this file unto a failed board and see if it fixes the issue.

ble5_host_test_cc2640r2lp_app_4XD.hex

Best regards,

Bun

Are you sure the ICs are programmed with the same cap-array configuration in CCFG? And are you sure there are none, or the same external load capacitors on both boards?

Hi Bun, why would that make a difference?

Hi Fredrik,

There were differences between the default SDK's radio settings and the one's the validation team used. In the default SDK, some radio setting were not set which sometimes causes frequency deviation to fail including frequency offset. This file corrects this issue. I will have to follow up with software app for the exact details if you are interested.

Best regards,

Bun

Hi Ben, thanks for the explanation. You are saying that if the customer is using the default SDK configuration they may "sometimes" see frequency offsets? Of about 60 ppm? Depending on what "sometimes" mean I guess it could explain what they are seeing. Providing some more explanation and not just a seemingly random hex file is definitely helpful here :-)

For this:"Are you sure the ICs are programmed with the same cap-array configuration in CCFG? And are you sure there are none, or the same external load capacitors on both boards?"

Basically, i think the software configuration are correct. Actually this is just an MP project for serveral years. Just somehow it has high fail rate.
I will double confirm with customer and we are not using 4x4, CC2640R2FRHBR should be 5x5.

Hi Bun,

Per your saying, "some radio setting were not set which sometimes causes frequency deviation to fail including frequency offset. This file corrects this issue."
Any patch to fix this? Or have been in latest SDK? or can u share hex by RHBR package?

Thanks.

HI Aichi,

We are still vetting these new settings so it has not been released yet. We are currently making a 5x5 differential version (5XD) with the updated settings. I will send it by tomorrow after we verify it works.

Best regards,

Bun

Hi Fredrick,

This is correct and thank you for the suggestion will do that next time.

Best regards,

Bun

Hi Aichi,

Just a follow-up, I will need to place an order for the 5x5 IC and have it mounted, which can take up to 2 weeks before I can report back results.

I have attached the firmware image I plan on using here if you want to test it in the meantime. It uses the same radio settings as the 4XD, which seems to correct the frequency deviation failures on our end, but please note that these radio settings changes are typically accompanied with an updated PA table. However, an updated PA table will need support from the software and validation team, which may take some time.

ble5_host_test_cc2640r2lp_app_5XD_FlashROM_StackLibrary_Validation.hex

Best regards,

Bun

Hi Bun, Can you ellaborate on what these radio settings specifically are and how they affect the frequency offset? Considering how long the CC2640R2F has been available I am finding it hard to believe that "incorrect" settings have existed this long. Or are you simply talking about a misalignment between the caparray and actual HW config on the evaluation boards?

Hi Fredrick,

The differences is between what validation team used/updated and what was released. I'll bring this up with the software team and loop you in.

Best regards,

Bun