• State Suggested Answer
  • +1 person also asked this people also asked this
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 76 subscribers
  • Views 3332 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 205251
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Error 102/106/107 in Engineering C Errata

Ralph

Hi,

We're using SR3 v1.1 for several BLE R/C.

Early this month, we received information of Engineering C Errata.

It suggests that we upgrade to SR3 v1.2 for fixing some errors relative to RADIO issues (error 102/106/107).

After comparing these two version of codes, we think it is not possible for us to complete the upgrade and verification before the date of  mass-production.

Instead of upgrading to SR3 v1.2, we think that we could fix these errors only  in current code based on SR3 v1.1.

Studying the errata, we still no clue about how to fix them.

We are in a hurry to catch the mass-production date!

Can anyone tell how to fix these errors clearly?

Thanks!

Parents
  • 0

    Hi,

    Thanks for your replay. Below are answers and questions for you.

    1. I don't know what reversion of nRF52832 will be used in production. Got no answer when I asked people who are in charge of purchase and sales the chip. So no matter what reversion will be used in production, we have to make sure it will be OK.

    2. Is it OK for using SoftDevice reversion other than 3.0.0 in SR3 v1.1?

       Or, Can I use SoftDevice 4.0.2 or later in SR3 v1.1?

    3. In the errata workaround sections, it mentions using ESB and Gazell libraries of SDK 14.0.0 or later. Does it mean that I need copy them from SDK14 and paste onto SR3 v1.1? 

    Thanks!

  • 0 in reply to Ralph

    Hi,

    Ralph said:
    Or, Can I use SoftDevice 4.0.2 or later in SR3 v1.1?

    Yes, you can migrate the SR v1.1 code to use SoftDevice v.4.0.2 or later. But it will require work. We have migration documents in the SoftDevice .zip, found here. Depending on how you have structured your application, it could be easier to port your application to the SR3 v1.2 code-base. But it could also easier to migrate to SD v.4.0.2 from your SR v1.1 application project.

    Ralph said:
    . In the errata workaround sections, it mentions using ESB and Gazell libraries of SDK 14.0.0 or later. Does it mean that I need copy them from SDK14 and paste onto SR3 v1.1? 

    ESB and Gazell are Nordic proprietary radio protocols. SR3 uses Bluetooth low energy. ESB and Gazell are not used in SR3. So if you are not using ESB and Gazell in your application, you can ignore that section, and you don't need to copy anything.

  • 0 in reply to Sigurd

    Hi,

    Thanks for your clear answer.

    We'd like to confirm something.

    As you mentioned above, using old SoftDevice with new chip(Rev. 2) the chip will behave equal to a Rev. 1 chip. We have questions in this:

    1. Are the results of using SR3v1.1 on both Rev.1 and Rev. 2 chips the same?
    2. Are the errors 102/106/107 corrected in old SR3v1.1with Rev 1 chip or not?
  • 0 in reply to Ralph

    Hi,

    Ralph said:
    Are the results of using SR3v1.1 on both Rev.1 and Rev. 2 chips the same?

    Yes, they will behave the same.

    Ralph said:
    Are the errors 102/106/107 corrected in old SR3v1.1with Rev 1 chip or not?

    They are not corrected in SR3v1.1, because SRv1.1 uses S132 v3.(fix was first added in S132 v4)

    Some comments on the erratas:

    102: The frequency at which this occurs is low (<0.1% of packets).

    106: 1 in 1600 (<0.07%) randomly generated BLE addresses  are affected.

    107: BLE addresses are not affected.

  • 0 in reply to Sigurd

    Hi, Sigurd

    "In the case you want erratums #102, #106, #107 fixed, on either revision 1 or revision 2, you need to use one of these softdevices:

    • S132 v4 or v5
    • S132 v6 (applies #182 for revision 2 devices, which enables a hardware fix for #102/106/107)

    "

    So S132 v4 or v5  works around issues #102, #106, #107 for revision 1 chip and revision 2 chip.

    S132 v6 uses HW fix by setting a register only for revision 2 devices? What if we use it for revision 1 chip, the issues won't be fixed? 

    Is that correct? 

    Thanks.

  • 0 in reply to Ralph

    Hi Ralph,

    Ralph said:
    So S132 v4 or v5  works around issues #102, #106, #107 for revision 1 chip and revision 2 chip.

    Correct.

    Ralph said:
    S132 v6 uses HW fix by setting a register only for revision 2 devices? What if we use it for revision 1 chip, the issues won't be fixed? 

    S132 v6 will automatically detect if it’s being used on a rev1 or rev2 chip.

    If it detect a rev 1 device, it will apply the workaround for #102,#106 and #107

    If it detect a rev 2 device, it will instead enable the HW fix(#182)

  • 0 in reply to Sigurd

    Hi Sigurd,

    Excellent.

    Thanks for your explanation .

Reply Children
No Data
Related
Terms of service