jota_1939431 will be looking into this with the developers next week and will let you know if he is able to determine the root cause.
You may also want to take a look at this thread: BCM20736S Sleep Example Firmware
I know that we found instances where P0 was also triggering HIDOFF and preventing the device from remaining asleep, but I cannot find samples to those threads to reference. I think here, it was beneficial to connect P0 to a pullup if not used.
I was aware of the issue with P0 and in fact we have a pull-up on that line.
I had run into the failure to enter HIDoff for this reason previously, leading us to add the pull-up.
However, this seems to be a different situation because it really DOES enter HIDoff, for 6 seconds.. that is, the processor really is off and current drops to a few microamps for a fairly long time, before getting into this state.
I believe I have tracked down the source of this problem.
My board has a flash chip with an active-low chip select line.
Before entering HIDoff, I make sure to set this line to be high (i.e. to keep the chip off).
It appears that sometime after I enter HIDoff, the line goes low and the flash turns on.
I am using P8 for the chip select.
I am not sure whether other pins behave the same way or not.
This is the code I use to configure and drive the GPIO:
#define __SLAVE1_CS_PORT 0
#define __SLAVE1_CS_PIN 8
// configure flash CS line
gpio_configurePinWithSingleBytePortPinNum(8, GPIO_OUTPUT_ENABLE, 1);
// disable flash CS (active low)
gpio_setPinOutput(__SLAVE1_CS_PORT, __SLAVE1_CS_PIN, 1);
On the 20732S, GPIO state definitely was retained during HIDoff, and I assume it should be on the 20736S as well?
Yes, it should be maintained. Can you try input and output disabling P33?
I just tried this, but it did not seem to help:
// enter deep sleep
gpio_configurePin(2,1,GPIO_OUTPUT_DISABLE | GPIO_INPUT_DISABLE, 0);
Broadcom support suggested adding the following to the end of the app_create() function. This seems to fix the issue.
In application_create(), register for callbacks that are invoked before entering hid-off/deep-sleep (yes, they are the same).
...... all other initialization here....
Then implement the callbacks as a NOP:
// Do nothing
// Do nothing
Leaving app_enter_hidoff() and app_abort_hidoff() NOP, is this requisite or optional? Is it OK to print some debug trace inside?
Please create a new thread as nobody on the AE team is looking for new questions added to closed/answered threads.