Possible bug or undocumented latency in TCB synchronization to TCA. ATtiny3224. Minimal code and scope shots.

[burnsb]

ATtiny 3224 running at 20mHz.

I'm getting one cycle of latency in TCA such that when TCB is synchronized to it, the TCB pulse begins 1 cycle before TCA. TCB_SYNCUPD appears to be working correctly otherwise. The issue occurs with slew on or off, inversion on or off, different periods and pulse lengths. I can't find anything documented on this.

Minimal code and osccilloscope shots:

  #error "This sketch is written for use with TCB1 as the millis timing source" //millis and delay not used anyways
#endif


void setup() {
  pinMode(PIN_PB0, OUTPUT);   //PB1 TCA0 WO0
  pinMode(PIN_PA5, OUTPUT);   //PA5 TCB0 WO0

  takeOverTCA0();                               // this replaces disabling and resettng the timer, required previously.

  TCA0.SINGLE.CTRLB = TCA_SINGLE_CMP0EN_bm | TCA_SINGLE_WGMODE_SINGLESLOPE_gc; // Single slope PWM mode, PWM on WO0
  
  TCA0.SINGLE.PER   = 127;                   // Timer A period of 127
  TCA0.SINGLE.CMP0 = 5; // pulse width of 5
  
  TCA0.SINGLE.CTRLA = TCA_SINGLE_ENABLE_bm; // enable the timer with no prescaler

  TCB0.CTRLB = TCB_CCMPEN_bm | TCB_CNTMODE_PWM8_gc; //TCB0 8 bit PWM

  TCB0.CCMPL = 255; // Timer B period of 255
  TCB0.CCMPH = 5;  // pulse width of 5

  TCB0.CTRLA = TCB_CLKSEL_CLKTCA_gc | TCB_SYNCUPD_bm | TCB_ENABLE_bm; //Select TCA clock, set TCB to sync, enable TCB

  TCA0.SINGLE.CTRLESET = TCA_SINGLE_CMD_RESTART_gc | 0x02; // Restarts TCA0, but TCB0 precedes TCA0's pulse by one cycle
}

void loop() { 
}

TCA is channel 1 (yellow) and TCB is channel 2 (blue). Note that the cursor is measuring TCB pulse beginning 50ns before TCA. (1 cycle at 20mHz.)

Closeup with TCB period of 255:

Wide view of TCB period 255:

Startup with sync, TCB period 255:

TCB with a period of 10 closeup showing the sync occuring:

Wider view of TCB period 10:

*edit- formating

[yhay81]

The 50 ns offset is consistent with the documented peripheral behavior at 20 MHz; SYNCUPD synchronizes the counter restart, not the two waveform-output datapaths.

Two details matter here:

1. The ATtiny3224 TCA description explicitly says that an interrupt/event/waveform output change triggered by CNT reaching BOTTOM, TOP, or CMPn occurs on the next CLK_TCA cycle. With DIV1 at 20 MHz, that is exactly 50 ns.
2. TCB 8-bit PWM defines its output as being set at BOTTOM and cleared at CCMPH. Its output path is therefore one TCA clock ahead of the delayed TCA WO update even though both counters reach BOTTOM together.

So the scope trace does not show TCB counting one tick early. It shows both counters synchronized, followed by different specified output latency. Changing period, slew, or inversion would not remove that fixed one-clock relationship, which matches your tests.

There is also a separate startup trap in the final line of the sketch. The ATtiny3224/3226/3227 silicon errata says that, with TCB in SYNCUPD mode, a TCA RESTART command does not force TCB to restart; TCB restarts only at a TCA overflow (affected revisions B and C, no workaround). Therefore this line cannot be used to establish the initial phase of both counters:

TCA0.SINGLE.CTRLESET = TCA_SINGLE_CMD_RESTART_gc | 0x02;

References:

• TCB synchronized with TCA: https://onlinedocs.microchip.com/oxy/GUID-ACE76F82-8072-410B-AFA7-16B2BF7B4CBA-en-US-8/GUID-D33B7AE3-D58B-44C7-A059-A3952BF41876.html
• Silicon erratum 2.9.2: https://onlinedocs.microchip.com/oxy/GUID-10D4E736-26D8-4845-9904-9EC14D7707FA-en-US-8/GUID-2B352458-FB61-4503-926A-B9144F8FF322.html
• Datasheet (TCA functional description and TCB 8-bit PWM): https://www.microchip.com/content/dam/mchp/documents/MCU08/ProductDocuments/DataSheets/ATtiny3224-3226-3227-Data-Sheet-DS40002345A.pdf

Practical consequences:

• If you only need repeatable counter phase, enable TCB before TCA and let the first real TCA overflow perform the documented synchronization; ignore the first cycle while settling.
• If the pins' rising edges must be coincident, SYNCUPD alone cannot guarantee that. Generate both edges through the same output path (for example two TCA WO channels when a common period is acceptable), or use EVSYS/CCL/external logic to add the required one-clock delay to the TCB-derived signal.
• Adjusting CCMPH can move TCB's falling edge, but it will not move the PWM8 rising edge because that edge is fixed at BOTTOM.

Thus I would classify this as a documented one-clock output-path latency plus a relevant silicon erratum, not a megaTinyCore synchronization bug.

[burnsb]

Thank you kindly for your thorough response! I didn't think it was megaTinyCore, but I was really hoping I'd found a silicon bug in the wild. That would have been pretty neat.

I do agree that this is a documented one-clock output-path latency and that you are correct.

In regards to the erratum, I saw that but it doesn't seem to be affecting this chip and doesn't apply to it according to 322X errata. Microchip didn't update their online documents, I guess.

If I understand this correctly, output from pymcuprog with -v info, relevant porttion:

pymcuprog.serialupdi.application - INFO - Device ID from serialupdi = '1E9528' rev 'A'

So I think that means this is a REV A ATtiny 3224.

The pdf of Silicon Errata and Data Sheet Clarifications ATtiny3224/3226/3227 Rev C 3-2026 doesn't mention that bug. Per your link to Series 2 errata, at the bottom of the page, "The online versions of the documents are provided as a courtesy. Verify all content and data in the device’s PDF documentation found on the device product page." It only shows a 16bit register problem on TCB. So, I think the pdf errata for the 322X parts takes precedence over the 2 series errata Microchip gives online.

If I understand this correctly, testing also bears out that the bug isn't present in these chips. I modified the code from my initial post: changed the periods around a little, added enable/disable of TCB, delays, TCA reset, and nops into main. It's ugly but I can capture the reset's effect on TCB.

#ifndef MILLIS_USE_TIMERB1
  #error "This sketch is written for use with TCB1 as the millis timing source" //millis and delay not used anyways
#endif


void setup() {
  pinMode(PIN_PB0, OUTPUT);   //PB1 TCA0 WO0
  pinMode(PIN_PA5, OUTPUT);   //PA5 TCB0 WO0

  takeOverTCA0();                               // this replaces disabling and resettng the timer, required previously.

  TCA0.SINGLE.CTRLB = TCA_SINGLE_CMP0EN_bm | TCA_SINGLE_WGMODE_SINGLESLOPE_gc; // Single slope PWM mode, PWM on WO0
  
  TCA0.SINGLE.PER   = 246;                   // Timer A period of 127
  TCA0.SINGLE.CMP0 = 5; // pulse width of 5
  
  TCA0.SINGLE.CTRLA = TCA_SINGLE_ENABLE_bm; // enable the timer with no prescaler

  TCB0.CTRLB = TCB_CCMPEN_bm | TCB_CNTMODE_PWM8_gc; //TCB0 8 bit PWM

  TCB0.CCMPL = 10; // Timer B period of 255
  TCB0.CCMPH = 5;  // pulse width of 5

  TCB0.CTRLA = TCB_CLKSEL_CLKTCA_gc | TCB_SYNCUPD_bm | TCB_ENABLE_bm; //Select TCA clock, set TCB to sync, enable TCB

  TCA0.SINGLE.CTRLESET = TCA_SINGLE_CMD_RESTART_gc | 0x02; // Restarts TCA0, but TCB0 precedes TCA0's pulse by one cycle
}

void loop() { 
TCB0.CTRLA ^= (TCB_ENABLE_bm);
delay(500);
TCB0.CTRLA ^= (TCB_ENABLE_bm);
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
__asm__ __volatile__ ("nop");
TCA0.SINGLE.CTRLESET = TCA_SINGLE_CMD_RESTART_gc | 0x02;
delay(500);

//TCA0.SINGLE.CTRLESET = TCA_SINGLE_CMD_RESTART_gc | 0x02;

}

Wide view of the above code, TCB starts up within the low of TCA. 30 or so NOPS/Cycles later, TCA is reset. TCB synchronizes with a visible discontinuity. When TCA overflows towards the right edge of the screen, you can see TCB sync again with a discontinuity:

Closer view of the TCA reset and TCB sync.

At least I think this is what is going on. I'm not in any way an expert and am happy to be corrected. Ultimately, I can work around the cycle of latency in TCA. I just thought it was interesting.

Thank you again for taking the time to look at this and respond. It is appreciated.