• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 1519 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2530: Sleep Interrupt Key

Michael Quinn
Prodigy 40 points

Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK,

My question is in relation to a CC2530 in a low power application using Z-stack home 1.2.2a. I'm using serial UART with the CC2530 ZNP, and this won't interrupt the device from low power PM2 and PM3 mode, only SPI is supported. I know I could possibly program an interrupt, but I don't have software experience so I thought one option would be use a mosfet as a switch to power off the radio.

I have used a P-channel mosfet to switch the active to the CC2530 in a prototype and put a 10K resistor in parallel to discharge the capacitors when the mosfet is switched off. My circuit and software function fine, but I was wondering if there is any general advice you can give me about what I should be wary about when using this circuit. Should I put the RESET pin low prior to cutting power? I have attached a basic schematic of my mosfet circuit.

Alternatively if I could receive help with programming an interrupt that would be good because it will require less materials.  I have previously programmed an interrupt for another project using the samplelight example, but there were already easy to follow examples.

The z-stack znp project has the same Hal_key.c file which I know how to program an interrupt, but I'm not sure where to call the interrupt to wake and sleep the device?  I'm using the standard ZNP Z-stack home 1.2.2a which has P0_1 and P2_0 (joystick) as interrupts but I can't see any calls to the interrupts and grounding these pins does not trigger an interrupt.

Example:

if ( (keys & HAL_KEY_SW_1))

{

Wake up and go to active mode and send messages

}

if ( (keys & HAL_KEY_SW_2))

{

Go back to sleep

}

In summary

  • I'm using the CC2530 ZNP in Z-stack home 1.2.2a with UART;
  • I would like enter deep sleep PM3 and have a interrupt pin configured as a input key to wake the device, send messages, then go back to sleep.

Thanks for your time.

Regards

Quinn

  • 0
    TI__Guru**** 222697 points

    Hi Quinn,

    I can assist with the pin interrupt programming.  The ZNP already has all key configuration functions but will not execute them unless HAL_KEY is set to TRUE inside the hal_board_cfg.h file.  All Z-Stack projects use polling for key processing instead of interrupts, changing this will require setting HAL_KeyIntEnable to true in hal_key.c and using HalKeyConfig(HAL_KEY_INTERRUPT_ENABLE, OnBoard_KeyCallback); inside InitBoard from the OnBoard.c file.  Please note that sleepy ZEDs typically enter PM2 to send data requests at a determined POLL_RATE, whereas ZR/ZC devices must always be active to route packets.  Entering PM3 will disallow the servicing of UART commands that are received during this time.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 40 points

    Hi Ryan

    Thanks for that answer, it is getting me closer.  I applied those settings and I used the SYS_GPIO ZNP command to set the configurable GPIO pin P06 as an input and this interrupted the MCU and it went from sleep mode ~50uA to active ~10mA power consumption, so the interrupt worked.  But I'm not able to send or receive messages when using the interrupt. 

    I noticed if I hold the MRDY pin low it will wake the MCU and it will draw ~18mA and I can send messages over UART, but I can not receive them from the coordinator.  

    The cc2530 enters power mode correctly when set to end device, but I'm unsure how to apply the interrupt to keep the MCU awake while I send and receive messages, then trigger the input pin to allow power down sleep mode again.  Do I need to set a if (hal_key6) {} statement in hal_sleep file?

    I'm also unfortunately receiving the following warning on compile with the new settings.  Something to do with a conflict with enabling interrupts?  I don't need SPI at all as I'm using UART.

    Warning[w52]: More than one definition for the byte at address 0x2033 in common segment INTVEC. It is defined in module "znp_spi" as well as in module "hal_key"

    Thanks for your help.

    Regards

    Quinn

  • 0 in reply to Michael Quinn
    TI__Guru**** 222697 points

    Your key interrupt needs to set a flag or creates some operation that prevents the MCU from entering osal_pwrmgr_powerconserve (found in osal_run_system of OSAL.c), then you can reset the flag after finishing your communication.

    You can remove the SPI files if you don't need them, hopefully this resolves the compile warning.  But I do not think it is affecting your device's behavior.  At least make sure HAL_SPI is set to FALSE in hal_board_cfg.h

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 40 points

    Hi Ryan

    My issue is resolved.  I was able to successfully program the interrupt to wake up the CC2530 ZNP out of sleep mode.  

    Thanks for your help and the clear responses.  

    __________________________________________________________________________________________________________________

    I have another general enquiry about an end device rejoining coordinator after the coordinator has lost power.  Basically my end device will deep sleep, wake, transmit data and repeat the sequence.

    I edited the DREJOIN_SCAN 30000 (30sec) and left -DREJOIN_BACKOFF=900000 (15min) to save power if coordinator loses power. 

    My test involved:

    1. Coordinator (ZC) and End device (ZED) form network, and send messages;

    2. ZC loses power;

    3. ZED transmits data and is not received by ZC;

    4. ZC powers up and send AF_REGISTER & ZDO_STARTUP_FROM_APP;

    5. I wait here for ZED to rejoin but I found I have to send AF_REGISTER & ZDO_STARTUP_FROM_APP on ZED before I can send AF_DATA_REQUEST.

    I tried setting -DREJOIN_BACKOFF=30000 for testing but I found the cc2530 znp would be stuck in rejoin when ZC was powered off and would draw ~24mA (receiving current).  With DREJOIN_SCAN 30000 (30sec) and left -DREJOIN_BACKOFF=900000 I don't get this behaviour and the devise is effectively sleeping (~1uA) the whole time, I'm assuming because it would be in backoff most of the time.  

    Is this expected behaviour?  If it is that is fine, I will have my application processor send AF_REGISTER & ZDO_STARTUP_FROM_APP when wake up from Deep Sleep before sending AF_DATA_REQUEST, in case the ZC has been reset.  

    Regards

    Quinn

  • 0 in reply to Michael Quinn
    Prodigy 40 points

    Hi Ryan

    I think I have resolved the device rejoining issue by searching the forum and using these commands:

    osal_pwrmgr_device( PWRMGR_BATTERY ); // sets so can enter sleep even if not connected to coordinator

    I use this command to enter low power state even if the end device hasn't connect to coordinator.

    ZDApp_StopJoiningCycle();       // stops the device from joining network if loses parent

    I call this command just before osal_pwrmgr_powerconserve() to make sure to stop rejoining cycle before sleep.

    and

    ZDApp_StartJoiningCycle();      // starts joining cycle to try and join parent if connection was lost

    I call this command when I wake up from sleep to start rejoin cycle again.