• 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

Parents
  • +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.

Reply
  • +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.

Children
No Data
Related