[K32W041/K32W061] Bug in undocumented power saving with SYSCON_CPUCTRL ?

[ckielstra]

Most wireless examples in the K32W061 SDK (at least v2.6.5 to v2.6.11) contain a line for power optimization by setting a bit in the SYSCON_CPUCTRL register. I think there is a bug here, can this be confirmed?

The code is:

#define SYSCON_CPUCTRL (*(volatile uint32_t *)(0x40000800))
...
SYSCON_CPUCTRL &= ~BIT(3); /* power optimization */

This register is not documented in the K32W061/K32W041 Register Manual UM11323 v1.2, but I assume it is identical to the register with same name and address that we find in other ARM based processors like the LPC5411x. When correct, then resetting BIT3 will have the effect of disabling a second CPU. Since we have no second CPU in the K32W0x1, I can imagine this saves a little bit of power. This should have been listed in the chip errata, but perhaps this isn't published yet?

Now the assumed bug: The LPC54111x manual states that the write only has effect when the upper 2 bytes contain an unlock code 0xC0C4. So I think the correct code should be:

uint32_t tmp = SYSCON_CPUCTRL & 0xFFFF;
tmp &= ~BIT(3);  /* Power optimization by disabling the clock for non-present second CPU */
SYSCON_CPUCTRL = 0xC0C40000 | tmp;  /* Requires unlock code 0xC0C4 to have effect */

Am I correct that this is how it should have been implemented?

[yyjdelete]

Is the change really right?

@ckielstra Can you check whether the below work for you? 

I try to apply this on QN9090(which is almost the same registers as K32W061), and I found MCU can't no longer be reboot by 
`__NVIC_SystemReset()` or `RESET_ArmReset()` after apply the change.

[ckielstra]

@yyjdelete My code example is wrong, I experienced similar problems after a reset but I don't know why. I didn't spend more time looking into this as I suspect the power saving is minimal and in our project we have more urgent issues to attend to first.

[Ricardo_Zamora · Accepted solution]

Hello,

Hope you are doing well. I apologize for a late reply. You are right. Must be written 0xC0C4 for the write to have effect.

I got the confirmation that this will be modified in a future SDK.

Have a nice day!

Regards,

Ricardo