Clarification of nRF52832 PAN 89

RE: Clarification of nRF52832 PAN 89

Jeff4BLE — Thu, 21 Feb 2019 17:42:01 GMT

Thanks.

I am sure this will be appreciated information.

Cheers,

Jeff

RE: Clarification of nRF52832 PAN 89

Stian Røed Hafskjold — Tue, 19 Feb 2019 16:21:27 GMT

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

Yes, I agree, we should make this post public

RE: Clarification of nRF52832 PAN 89

Jeff4BLE — Fri, 15 Feb 2019 17:04:22 GMT

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

RE: Clarification of nRF52832 PAN 89

Stian Røed Hafskjold — Fri, 15 Feb 2019 08:23:36 GMT

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.