• State Verified Answer
  • Replies 4 replies
  • Subscribers 64 subscribers
  • Views 2123 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 222608
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Clarification of nRF52832 PAN 89

Jeff4BLE

This PAN states:

"Conditions
• GPIOTE is configured in event mode
• TWIM/SPIM utilizes EasyDMA"

What is not completely clear are these two separate conditions? Or do both conditions need to be met to experience the excessive current? In addition, if there are other conditions that result in the same how do we get them added to the erratum/PAN?

This is important question for a medical device manufacture that may get questioned in the FDA approval process. 

Our customer is seeing this condition under the following conditions. SPIS is using EasyDMA, TWIM has been enabled and disabled, GPIOTE is not used in this application and is not configured in event mode.

However, they are have a similar current issue and implementing this workaround resolves it. Unfortunately, this is not enough for them to comfortably use this device in their application. I have also note a number of cases on Devzone where this workaround is recommended and has worked, but the conditions are not as the erratum has called out. It seem to me that the PAN needs to be expanded?

If any of this needs to be addressed outside of the DevZone, please let me know.

Best regards,

Jeff

  • +1

    The reason for the high current consumption is that the HF clock is left running after the peripheral is stopped. The intended behavior is that the peripheral requests the HF clock when needed and then releases the HF clock afterwards. This is typically at the start and end of a transaction. If the peripheral fails to release the clock then it will continue running and consume current.

    There can be several reasons why the clock is never released. Some are hardware bugs (PAN 89) and some are software bugs. E.g. disabling a peripheral without stopping it first can cause this behavior. And, since this is not the intended way of using the peripheral, it's a software bug.

    PAN 89 is for one specific HW bug where TWI/SPI together with GPIOTE will cause the clock not to be released.

    The reason why the workaround works in most cases where the clock is stuck is because it does a simple power cycle of the peripheral. It will always release the clock.

    My point is that even though the PAN 89 workaround seems to resolve issues where the conditions are not met, it doesn't mean that we have another "variation" of the HW bug.

    However, I agree that it seems to be a lot of issues with this, and I will go through all the material on devzone and JIRA and see if there are reasons to include another PAN, or maybe we need a guide on how to avoid this/how to debug it, or similar.

  • 0

    Thanks Stain,

    This is good and clear information.

    We are currently working with a customer that has used this workaround to resolve a high current issue with SPIS. The product specification, states the the HFLCK is used for the SPIM baud rate generator. There is no mention of the HFLCK under SPIS section of the production specification. Does the SPIS use the HFCLK?

    Empirically, this is obvious. But before we proceed, I want to be sure.

    Once this is answered, I think this would be a good public post. Do you agree? Do you think there would be any objections to this?

    Best regards,

    Jeff

  • +1

    The SPIS starts the HFCLK when the CSN line goes low.

    Yes, I agree, we should make this post public

  • 0 in reply to Stian Røed Hafskjold

    Thanks.

    I am sure this will be appreciated information. 

    Cheers,

    Jeff

Related