• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 322 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.

CC2640R2F: ADC interrupt does not trigger after standby

Flo__
Intellectual 370 points

Part Number: CC2640R2F

Hello,

we're using a very stripped down version of SCS code to enable the chip's ADC. We then use a HWI on INT_AUX_ADC_IRQ that triggers when a measurement is done, read the value there and start the next measurement with AUXADCGenManualTrigger. Everything is working fine so far.

But as soon as the CPU goes to standby and wakes back up, the HWI will never trigger again. All used elements should be completely uninitialized before the standby starts (maybe the sensor controller isn't?) and are freshly initialized after waking up. We're using the standby in a kind of special way.

What I noticed when comparing the registers was that AUX_EVCTL.EVSTAT1.ACLK_REF is 1 all the time during the first run and right after wakeup, but will change to zero or jump around after some time. I've tried to uninitialize and initialize the sensor controller and ADC multiple times while the software was running if the ADC HWI didn't trigger for a while, but I could not get the TDC reference clock back running.

Do you have any hints what could be the problem? Thanks in advance!

  • 0
    TI__Guru**** 317180 points
    From this post it looks like you are not using the ADC driver and that you are not using the TIRTOS/ noRTOS solutions provided. Is this the case?
  • 0 in reply to TER
    Intellectual 370 points

    Yes.

    I've now rebuild everything to match the ADC driver a bit more, but we can't use blocking reads so I still have to use an interrupt to get the ADC data. This is working fine so far, but with all the deinit and reinit stuff called from the ISR, the code is too slow to use multiple ADC channels. I'm still looking for a solution for this - or for keeping the sensor controller.

  • 0 in reply to Flo__
    TI__Guru**** 317180 points
    The normal usage of the Sensor Controller is to write code using Sensor Controller Studio and call the driver.

    What is the background for writing bare metal code? We give very limited support on bare metal cases .
  • 0 in reply to TER
    Intellectual 370 points

    The reason is that the SCS code needs too much resources and the driver only supports blocking reads.

  • 0 in reply to Flo__
    TI__Guru**** 317180 points
    Could you elaborate a bit on what you need?
  • 0 in reply to TER
    Intellectual 370 points

    We need to:
    - read values from multiple or single ADC channels
    - be able to activate/deactivate some of these channels temporarily
    - read their values without halting program execution
    - read their values many times a second (start read with ADCCC26XX_SAMPLING_DURATION_5P3_US, start read again in ISR)
    - use a minimal amount of resources

    Edit: Forgot something important:

    - do all these things after a standby again

  • 0 in reply to Flo__
    TI__Guru**** 317180 points
    Based on what you write it looks like you should be able to do this in the Sensor Controller (and writing code in Sensor Controller Studio). Then most of this will be done in the RISC in the Sensor Controller and you can notify the CM3 when you have a ADC value that need processing.
  • 0 in reply to TER
    Intellectual 370 points
    As far as I know, we do not have enough flash left for the huge overhead for the SCS code. I might try it if I can't find a solution myself.
  • 0 in reply to Flo__
    TI__Guru**** 317180 points
    Meaning that you have written all code to handle to radio, power modes etc as bare metal?
  • 0 in reply to TER
    Intellectual 370 points
    We are using mostly low level APIs or modified drivers and pretty much all RTOS automatisms are turned off, so I guess yes.

    I managed to solve the problem and I would love to say "this step did it", but I fiddled around so much I'm afraid I can't. But we can now ditch the sensor controller completely and use a modified ADC driver.