• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 747 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.

Generating high-freq PWM (20+ kHz) causing sluggish BLE performance

Prashant Vaibhav
Intellectual 370 points
Other Parts Discussed in Thread: CC2541

Hello engineers,

I am trying to generate a high-frequency PWM signal using Timers 1 and 3 on the CC2541. Above 20kHz is required because below that is audible and very irritating :)

I programmed timers 1 and 3 to generate 32 and 64 kHz respectively, which works, I get a stable pwm signal on the oscilloscope. However, the BLE performance suffers tremendously. I am transferring the duty cycle of both signals over BLE, at approximately 30-50 Hz. This works very well when PWM frequency is 500 Hz for both timers. However, when I change the pwm freq to 32 kHz, there is significant lag between me sending a dutycycle change (a slider on the app) and the change actually happening on the device. The lag is of the order of several seconds.

I have tried reducing the 'active clock tick' by using a scaler (e.g. for Timer 1, /4 scaling and modulo mode with ch0 = 256, giving 32 kHz), but this seems to have no effect. It seems what is causing the sluggishness is the frequency at which the GPIO is toggled.

So I would like to ask:

- how many clock ticks does it take to toggle a GPIO set to timer output?

- What is the most efficient way to generate a 32 kHz pwm signal with 7 or 8bit dutycycle resolution?

- Is it normal that generating 2 or 3 signals at 32 kHz will cause BLE performance to become so sluggish that it can't transfer a few bytes every 20 ms?

Thanks in advance!

  • 0
    TI__Expert 6995 points

    Hi Prashant,

    This does sound strange. What hardware do you have available? I'm wondering if you can sniff the BLE traffic to see what happens there? It can be done with most of our develoment kit hardware and the Packet Sniffer PC tool. Can you reduce the update frequency to approx 10 hz to see if that makes a difference?

    What are you driving with the PWM? Any chance it's in turn introducing noise into the power supply of the CC2541?

    Peder

     

  • 0 in reply to Peder
    Intellectual 370 points

    Thanks for the response Peder.

    I do have a USB dongle with the packet sniffer firmware so I will check that out. Also with reduced frequency.

    However, what caught my eye is your latter suggestion about introducing noise in the power supply. I think that could very well be the reason. I am driving a DC motor and a magnetic coil actuator. The actuator draws only about 50 mA, but the motor draws up to 500 mA. (The power supply is a 3.7 V LiPo which can easily provide 600+ mA.)

    I did notice that the effect is most apparent when the motor is being controlled. The actuator itself appears responsive as long as the motor is not turned on.

    Could it be due to the fact that the motor is drawing several hundred mA current at 30-60 kHz? If yes, do you have any suggestions on how to mitigate this (without changing the hardware)? Apologies if these questions are naive, I'm mostly a software guy with only basic electronics knowledge.

  • 0 in reply to Prashant Vaibhav
    TI__Expert 6995 points

    Hi Prashant,

    Any chance the the CC2541 is actually getting reset by the power dips created by the motor peak currents? One way to check would be to have firmware initiate an unused GPIO on a test point to output low and then see if it ever changes state to input with pullup which is the reset state.

    Other than that, noise on the analog power supplies that supply the PA, LNA and ADC etc. can cause a significant dip in RF performance depending on how degraded the supply is. Some frequencies are worse than others. A potential software-based improvement could be to just shift the frequencies a bit and see if the noise moves out of some more sensitive area for one of the RF components.

    Peder