Hello,
I have the CC2530ZNP mini development kit. It comes with some example applications to build simple Zigbee networks and so on. These applications use a common library. The function znpReset(), which is of course very important throughout all apps, toggles a DEBUG signal which, as I found out the hard way, has a very important effect on the power management of the CC2530 but I do not know why or what it is.
unsigned char* znpReset()
{
RADIO_OFF();
DEBUG_OFF(); //what is this?
delayMs(1);
RADIO_ON();
DEBUG_ON(); //
znpResult = spiPoll(); //Note: this will be different if UART
return (znpBuf+SRSP_PAYLOAD_START); //the beginning of the reset indication string
}
The debug pin is connected to port 4.4, as defined in hal_cc2530znp_target_board.h
#define DEBUG_ON() (P4OUT |= BIT4)
#define DEBUG_OFF() (P4OUT &= BIT4)
The problem is that looking at the schematic of the ZNP mini PCB which I attached for easy reference 4718.CC2530_ZNP_Schematic.pdf, port 4.4 does not seem connected to anything.
Is the schematic wrong or am I missing something? In case you wonder why I am so concerned about this signal, please read below:
I am trying to build a Zigbee end device and I need it to go into very low power mode. I found that the examples that come with the ZNP mini software bundle never put the end device in very low power mode, but the current was always at least about 0.4mA . The only application I found that put the CC2530 in very low power mode (about 0.01mA) was the Sensor Demo Network which comes in a different software bundle, also from TI. So I spent a huge amount of time trying to figure out what the Sensor Demo Network was doing so magical that puts the CC2530 in very low power mode (the code uses some pretty complex state machines which are not easy to wrap your head around), but in the end I found the answer: It is the DEBUG signal that I asked about at the beginning of this post. The znpReset function used by the Sensor Demo Network is similar but it just does not toggle the DEBUG message.
Removing the DEBUG calls from an application that did not go to very low power caused it to go to very low power so indeed the "trick" seems to be this DEBUG signal. Problem is, this is not documented anywhere and I'd like to understand what this signal is.
Best regards,
Florin