try to changing pwm frequency on PIN_PD2

[cybermatrix84]

thankyou so much for great core, im using avr128da32 for control motor, i designed my pcb with PIN_PD2 to provide PWM to control speed of motor. my motor make noise because the low frequency, i did read about taking over tca0 but i cant get it right can you give the example to change pwm frequency.

sorry im new on programming, so really helpful if you can give example to change pwm frequency on PIN_PD2. thankyou so much

[SpenceKonde]

Changing the frequency by factors of 4 is very easy, since you can just change the TCA prescaler - we default it to 64 at most clock speeds., It can be turned down to 16, 8, 4, 2 or 1. That's also the only setting on TCA that you can change without taking over TCA0, and using analogWrite. (please refer to the examples included (they're listed in sketch -> examples -> DxCore) on taking over TCA for examples where you do take over analogWrite for full control and can set any frequency, and the document on TakingOverTCA0 - I have no examples beyond those.

However, there is a reason we target 1 kHz. How is the motor being driven? If you are directly driving the gate of a power MOSFET to switch the load, 1kHz is the highest frequency you can assume will work for PWM. Above that, you need to run the numbers and make sure you are turning the FET on and off quickly enough. As F_PWM increases, the FET will spend a larger and larger portion of it's time switching, (when power dissipation in the FET is highest) and less either on (where power dissipation is very low) or off (where power dissipation is 0) the pin can't supply current sufficient to quickly switch the gate. In extreme cases, including some where I was asked why FETs rated for much higher loads were burning out, and questioning revealed that they were trying to eliminate audible components from a motor, and were trying to switch so fast that the FET never got to turn on or off, and was just running back and forth on the miller plateau, never reaching either end of it, stuck in a regime where significant current is flowing, but the Rds is ohms or tens of ohms instead of milliohms.. I review this problem in more detail, link a spreadsheet you can use to calculate safe pwm frequencies for any MOSFET when directly driven based on Rgate and the pin driver strength and the components of gate charge, which are what define the shape of that graph of Qgate vs Vgs - as you can see in the datasheet for your MOSFET, it starts with one slope (before the miller plateau, then goes horizontal, as current starts to flow, because there is also capacitance between the gate and the drain, and as the FET turns on, the drain voltage starts to fall, and being capacitively coupled to the gate, this effect works against your attempt to drive the gate voltage higher to turn the fet fully on. Reverse happens when turning off.

And you can't solve the problem by using a beefier fet, because beefier fets have more gate capacitance, either - it can even make the problem worse.

The solution when you need faster PWM than can be done directly driving the gate is to use what is called a gate driver - specialized (but not hard to source - many companies make near identical pin compatible ones). Whereas a microcontroller pin is going to supply 20-40mA, the gate drivers are designed to provide a very brief pulse of current, typically several AMPS, slamming the mosfet on and off on the order of 100x faster or more.

(description assumed an n-channel fet, p-channel fets are the opposite way around but otherwise the same problem is present, except there are not readily available drivers that are easy to use for P-channel fets like there are for N-channel ones.)

See the https://github.com/SpenceKonde/ProductInfo/blob/master/MOSFETs/Guide.md MOSFET guide that I wrote, which covers this is more detail. All I'd be doing answering further is saying the same things I say there.

[cybermatrix84]

thankyou so much for the reply. where i can change setting without taking over TCA0

im using pololu motor driver Pololu G2 High-Power Motor Driver 18v25 https://www.pololu.com/product/2994

thankyou so much

[SpenceKonde]

Nice, yeah, that even specs the max pwm speed for you.

[cybermatrix84]

so im still not understand where i can change TCA prescaler. if you said that default is the most high frequency which is targeted 1Khz and then i cannot go more than 1Khz without taking over the TCA0

[SpenceKonde]

We target "around 1 kHz". Depending on the clock speed, due to tjthe limited granularity of the prescalar setting - the worst case speeds range from 490 Hz on the low side, to 1400-something at most I think before we swap to the next prescaler setting. (the default frequencies can be found in the core documentation, Ref_Timers.md)

That document also mentions that basically the only things you can change without breaking PWM via analogWrite are the PORTMUX (analogWrite and digitalWrite are PORTMUX aware) and the prescaler - more than that and you need to take it over. The same discussion (which is much longer) for TCD is in REF_TCD.md.

Prescaler is bits 1-3 of TCA0.SPLIT.CTRL:A/TCA0.SINGLE.CTRLA. They are set according to the table, found in chapter 21 of the AVR128DA datasheet.

typedef enum TCA_SPLIT_CLKSEL_enum
{
    TCA_SPLIT_CLKSEL_DIV1_gc = (0x00<<1),  /* System Clock */
    TCA_SPLIT_CLKSEL_DIV2_gc = (0x01<<1),  /* System Clock / 2 */
    TCA_SPLIT_CLKSEL_DIV4_gc = (0x02<<1),  /* System Clock / 4 */
    TCA_SPLIT_CLKSEL_DIV8_gc = (0x03<<1),  /* System Clock / 8 */
    TCA_SPLIT_CLKSEL_DIV16_gc = (0x04<<1),  /* System Clock / 16 */
    TCA_SPLIT_CLKSEL_DIV64_gc = (0x05<<1),  /* System Clock / 64 */
    TCA_SPLIT_CLKSEL_DIV256_gc = (0x06<<1),  /* System Clock / 256 */
    TCA_SPLIT_CLKSEL_DIV1024_gc = (0x07<<1)  /* System Clock / 1024 */
} TCA_SPLIT_CLKSEL_t;

TCA_SPLIT_CLKSEL_gm is also defined, so it's a bog standard RMW to an SFR;

// disable interrupts if any of your interrupts *write* to this register and you currently
// are not (or don't know) if you're in an interrupt. If you *are* in an interrupt, no extra step
// is needed unless you're using a level 1 interrupt, and it is *not* this one, and that lvl1 int
// is the one that writes to TCA0.*.CTRLA 
// If you don't know what that is, you're neither using nor in one.
// uint8_t oldsreg = SREG;
// cli();
uint8_t temp = TCA0.SPLIT.CTRLA;
temp &= ~TCA_SPLIT_CLKSEL_gm; // we've cleared the current setting
temp |= TCA_SPLIT_CLKSEL_DIV(divisor goes here);
TCA0.SPLIT.CTRLA = temp;
// if interrupts needed to be disabled
// SREG = oldsreg; // reenable them

(TCA0.SINGLE.CTRLA and TCA0.SPLIT.CTRLA are the same memory address. That whole unholy rigamarole is implemented, in the C representation provided by the headers, as a union of single and split versions of the peripheral. So TCA0.SINGLE and TCA0.SPLIT are pointing at the same chunk of memory, but using different names to refer to a different subset of them, and with the 16-bit registers being treated as pairs of 8-bit ones in split mode - which are not subject to "accessing 16-bit registers" per uh, like any modern avr datasheet).

(note that on the TCA, it works; the TCB is supposed to do that too when in 8-bit pwm mode (the only pwm mode it has), but only the latest parts actually do this right (see errata). The naive TCB millis used in the official "megaavr" and the analogWrite it came with would together set the duty cycle by writing the high byte of CCMP, which triggered temp being copied to the low byte, which still has the same value we put into it so whatever.... until you called micros(). That would trigger 16-bit access on cnt, meaning the high byte was copied to temp. This being 8-bit mode, the high byte is going to be 0.... so... now temp holds 0, and the next analogWrite() kills all PWM. How bad hardware and bad software combine to reach new levels of astonishment in their finders. This is "time" bomb was originally in uno wifi rev2/nano every official - they use TCB for millis and PWM and in the relevant case are using PWM from the same TCB as millis. Everything worked fine until you had called micros() - from then on, the next time you change the duty cycle with analogWrite() in that implementation, instead pwm output would just stop and not come back - and could also get broken in various non-useful ways,

And it was never noticed on my cores before the fix was known, almost every time it happens it was micros/millis and pwm - and I decided to prohibit PWM on the millis TCB on my cores, in order to get more accurate millis timing, less time spent in ISR and faster returns on millis and micros. Oh, and I made millis and micros work at all clock speeds, as in give accurate and consistent results. (stock core only worked where F_CPU = 1,000,000 * 2ⁿ)