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.

GPTimer/PWM Beta driver on CC2640

Other Parts Discussed in Thread: BLE-STACK, CC2640, CC2650

Hello Bluetooth devs,

I did a few thorough searches, but couldn't find anyone else that has run into this situation.

I've developed a custom embedded application using the SensorTag board as my reference platform that uses BLE-STACK 2.1, and the beta GPTimer/PWM driver. Everything works as expected, but now that I've received my custom CC2640 board, my application hangs at any of the calls to GPTimerCC26XX_start(). If I remove all usage of the GPTimer/PWM drivers, everything runs fine.

I can post more details if necessary, but do the beta GPTimer/PWM drivers work on the CC2640, or am I in trouble?

If anyone has any information, please let me know.

Thanks!

-Ben

  • Can you post your schematics and layout so we can have our HW expert to take a look at it?

    Have you checked out our wiki page for debugging:

    The pre-release driver should not be the problem as you mentioned it worked on sensortag board.

  • Thanks for getting back so quickly Christin.

    I talked to my business partner that designed the hardware, and he said he'd be willing to post the schematic if I can't figure out what the problem is. I did check out the wiki link you posted, and I've run through all the suggested steps with no luck.

    Any call to GPTimerCC26XX_start() causes the debugger to run and never stop again (stepping over the line with the debugger causes this behavior.) My code uses both the GPTimers and the PWM driver, and if I comment out the calls to GPTimerCC26XX_start() and let my code get to PWM_start() something interesting happens. The PWMPIN that I have defined transitions from low to high, and then gets stuck at the high value.

    Another interesting note is that I can't set breakpoints inside of GPTimerCC26XX_start() as CCS says that there is no corresponding debuggable code there. Even though the function is small, it'd be interesting to see where it fails.

    Are there any differences between the 2640 and 2650 that I'm missing? Again, everything I've read says they're code compatible, but do the drivers or peripherals require different initialization or something?

    I'll get back to you with a schematic as soon as I clear it with my business partner.

    Thanks!

    -Ben

  • No, the driver and peripherals are the same, so if it works for CC2650, it will also work on CC2640.

    Have you checked if you got valid handle value when you called GPTimerCC26XX_open?
  • Ugh.

    You're right again Christin. My calls to the GPTimerCC26XX_start() were being kicked off in a button interrupt handler,  but my code that initializes the timer handles was getting hung up at a call to GPTimerCC26XX_registerInterrupt() and was thus never correctly initializing the timer handles before they were used.

    Now I just need to figure out why that call fails. It's still weird that this all works on the SensorTag and not this custom board. The only changes made are in the radio configuration and the button/board configuration.  The application code is identical between the two boards. I'll check that out tonight and report back.

    Thanks again!

    -Ben

  • If you want, you can post your custom board files here, we can take a look at it.
  • Sorry it took me so long to reply, Christin.

    I was really trying to figure this out on my own, but am up against a wall, yet again. I'm going to post our schematic/source as soon as my partner clears it. He was hoping I'd figure it out, but my limited knowledge of TI parts/software has me somewhat cornered. In the meantime, I'll ask one more set of questions...

    My calls to open a PWM port seem to be successful, but when PWM_start is called, the PWM pin just transitions from low to high, and stays there. (And unfortunately burned out a FET on my board before I noticed this ;P )

    I also did some more hunting inside of GPTimerCC26XX_registerInterrupt() to see where exactly it gets stuck, and its this line:

    Hwi_construct(pHwi , hwAttrs->intNum, GPTimerCC26XXHwiFxn, &hp, NULL);

    In the debugger, all of the variables passed seem to be valid, so I'm still not sure whats causing this.

    Hopefully by tomorrow I can post the schematic/source, but if you have ANY pointers, or something obvious I haven't tried, please let me know.

    Thanks!

    -Ben

  • You can take a look at our software developer's guide section 9.8 to see what's causing the program hangs.
  • Thanks again Christin,

    I got the schematic/artwork from my business partner, but he'd prefer I share them and the code privately if that's possible?  I can set up a private repository or zip them up and send them directly if that helps?

    I'm the meantime, I'm working through the sections in the software manual you pointed me towards.

    Let me know!

    -Ben

  • You can send it to my E2E msg box. I will forward your schematic and layout to our HW experts.
  • For anyone interested, my problem was that I had a PWM Output and an Input Capture Timer both running on TIMER0A by accident. All I did to fix it was move the Input Capture Timer to TIMER1A, and all is well.

    I just couldn't understand why it hung, but now it makes total sense.

    Hope this helps someone else!

    -Ben

  • Glad you solve the problem!