TCB CCMP ignoring upper 8 bits

[SimonMerrett]

I've been looking at porting my "arbitrary" clock divider code across from ATtiny3227 to AVR128DB48 (in preparation for another move with AVR DD but just practising with Dxcore - even though I know it is in megaTinyCore). It fell over quite quickly and working back, I seem to have isolated it to the TCB1 not setting it's CCMP register(s) to anything higher than 0xFF.

void TCB1_MSB_init(void)
{
  TCB1.CTRLA = 0;
  TCB1.CNT = 0;
  TCB1.CCMP = 0xFFFF;                            /* Compare */
  //TCB1.CCMPL = 0xFF;                            /* Compare */
  //TCB1.CCMPH = 0xFF;                            /* Compare */
  TCB1.EVCTRL = 0 << TCB_CAPTEI_bp                  /* Event Input Enable: disabled */
                | 0 << TCB_EDGE_bp                  /* Event Edge: disabled. We only want one input edge to trigger a pulse */
                | 0 << TCB_FILTER_bp;               /* Input Capture Noise Cancellation Filter: disabled */
  TCB1.CTRLA = TCB_CLKSEL_DIV1_gc                  /* Use the peripheral clock with no prescaler */
               | 1 << TCB_ENABLE_bp;                /* Enable: enabled. Turn the timer on! */
}

Results in a pulse period (ie the time between the rising edge of two sequential pulses, not the width of the pulse when in high logic state) the same as if you write TCB1.CCMP = 0xFF; From my calcs and measuring the period between EVOUT pulses on my scope, only the least significant 8 bits of TCBn.CCMP are getting counted before the pulse fires.

Can anyone please comment, tell me I should be doing something different for the AVR128DB48 from the ATtiny3227 or show me how to "properly" set the 16 bit CCMP registers if I have done it unreliably above?

[SimonMerrett]

Aha, adding TCB1.CTRLB = 0; seemed to do the trick. Does the core take over TCB1 for 8 bit PWM in a way I missed in megaTinyCore?

[SimonMerrett]

See below but @SpenceKonde has confirmed it was the core initialising TCB1 to PWM mode and me not resetting that mode when I took over the timer, which was causing my trouble.

[SpenceKonde]

See the errata, cmpl/h is always treated as a 16 bit register as described in the accessing 16-nitregisters secttion of the datasheet, regardless of mode

…

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: ***@***.***

On Thu, Dec 1, 2022, 21:02 SimonMerrett ***@***.***> wrote: Aha, adding TCB1.CTRLB = 0; seemed to do the trick. Does the core take over TCB1 for 8 bit PWM in a way I missed in megaTinyCore? — Reply to this email directly, view it on GitHub <#372 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW42HPGFIHNPM7QDVRTWLFKDTANCNFSM6AAAAAASRND3WA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[SimonMerrett]

Please could you give a bit of a hint where to look for known-good examples code if my two lines above aren't best practice? https://microchipsupport.force.com/s/article/Accessing-16-bit-registers-in-8-bit-AVR-devices seems to not go any further than the image from the datasheet above. Modulate.ino seems to do it the same way as I did:

DxCore/megaavr/libraries/Logic/examples/Modulate/Modulate.ino

Line 75 in 3699dea

TCB0.CCMPL = 255; // 255 counts

From looking at the core though, I think all the otherwise-uncommited-TCBns are set to PWM mode, which would explain why I only got the expected result when I set TCB1.CTRLB = 0. See

DxCore/megaavr/cores/dxcore/wiring.c

Line 1987 in b36ff40

timer_B->CTRLB = (TCB_CNTMODE_PWM8_gc);

for where I think it happens.

[SpenceKonde]

On a 16-bit register, writing the low byte alone doesn't change the value of the register - it just sets the temp register, expecting you to follow with a write of the other byte of the register at which point it writes the high byte to the value you supplied, and copies the temp register to the real low byte of the target register.

While this is more or less transparent to C most of the time, when accessing the bytes separately while the hardware is treating them as being a single 16-bit register (particularly when it's not supposed to be, though this problem with PWM mode may be fixed on DD-series parts, finally) the results can be perverse and mystifying, especially if you access other 16-bit registers in the same peripheral:

• You can set CCMPL (or the low byte in any 16-bit register) to whatever you want all day long and the timer (or other peripheral with a 16-bit register) won't see a thing until you write the high byte.
• If you read or write a 16-bit register in the same peripheral, whether or not it's the same register, the same TEMP register is reused.
• A maximally perplexing scenario is something like

TCB0.CCMPL = 254; // this happens during core initialization for non-millis timers)
// TEMP is now 254
TCB0.CCMPH = 128; // say, we configure it to count to 254 and assign a 50% duty cycle, as is done for the TCBs that may be used for PWM. 
//later
TCB0.CCMPH = newduty; // Everything looks okay....  But if the erratum is present, both high and low bytes of CCMP are being written.
// the only reason it works is that the value currently in the temp register is the one you want to have stored to the low byte of CCMP. 
// If one then does something like innocently printing the current timer count:
Serial.print("Timer count is ");
Serial.printHexln(TCB0.CNT); 
// the temp register is reused for the high byte of the count (so you can't read the timer count at a bad moment and get the low byte before an increment and the high byte from after. 
// in fact since the timer is only counting up to 254, the high byte of the count, well that'd have to be 0 right? 
// So now TEMP = 0.
// If the 8-bit PWM mode worked correctly this would still work: 
  TCB0.CCMPH = newduty2;
// but if instead 8-bit PWM mode has the silicon erratum  present,  this will execute a 16-bit write, copying the temp register to CCMPL.
// except now, instead of the value that we happened to want in the low byte, temp contains the value 0. 
// So writing CCMPH = 5
// could result in CCMP = 0x0005; 
// Which would result in all PWM output ceasing, because the period was set to the minimum, while the duty cycle of, say, 5, is higher than the period, so the compare value will never be matched and the pin will never turn on. 

[SpenceKonde]

We do set all TCBs that might potentially be used to output PWM via analogWrite to single PWM mode during initialization, correct. You want to be able to use them to output PWM right?

analogWrite() does verify that the timer in question is in 8-bit PWM mode before proceeding to set the duty cycle or enable output - if it isn't, it does not attempt to change that, on the grounds that the one way that it could be in a mode other than 8-bit PWM)

[SimonMerrett]

Glad I have some DD parts in the shopping basket!

I can see now how the temp reuse could cause a great deal of confusion. But it seems not to be at the cause of my issue (now fixed by resetting TCBn.CTRLB). Thank you for explaining the mess one can get into. I'll go and fix my ATtiny3227 version to only write to TCBn.CCMPL, then TCBn.CCMPH and never to write to TCBn.CCMP.

[SpenceKonde]

Writing to CCMP is fine. The compiler, given a value to write to a 16-bit register, will always write the low byte first.

Your solution for the impacted parts is IMHO practically backwards.... on parts with this erratum, really what you should do is absolutely never explicitly reference CCMPL or CCMPH. There is no such register! There is only one register, CCMP!, and ONLY access CCMP. That way you're forced to deal with the fact that you need to write all 16 bits even if you only want to change 8 of them.

Final note: This impacts all post-revolutionary (2016) AVRs up until the AVR DD-series. The DD-series engineering work would appear to have been centered around fixing all the bloody bugs. They're down to like 5 errata from on the first wave of DDs, and 3 on the second wave (they fixed two errata relating to HV UPDI programming (which unfortunately make it harder to HV program them. You need to get a KEY entered within 50ms or something of the hv pulse, so what you used to be able to do on tinyAVRs won't work on second wave dd's (with a 12v doorbell battery, a resistor, and nerves of steel to trigger the hv override, then connect the UPDI programmer and program normally)

The timer-counter erratum is the longest lived on modern AVRs other than the TCD ones, which weren't discovered until well into the DD development. The other ones that were tied with it got fixed in the 2-series (this would be the pin override stuff for I2C and USART)