Puzzling PWM Problems

[mborgerson]

I'm working on a document describing a satellite ELINT system from the 1970's (That's old enough that I can actually find declassified technical information.) I want to simulate the display the ground station operators would see if they were receiving two channels of data from each of two satellites. The timing of the intercepted radar pulses could be used with Differential Time Of Arrival (DTOA) techniques to locate the emitting radars. When I set up T4.1 with 4 PWM outputs from pins 14, 15, 18 and 19, I got some puzzling results. (Those pins use channels 0,1,2, and 3 of quad timer TMR3.) Since I set up and started all the PWM outputs in quick sequence, I expected all the outputs to rise within a few microseconds of each other. No Such Luck! All the falling edges were lined up! I found that inserting some delays between initializations would result in a fairly close line up of the leading edges. However, the values and positions of the delays don't seem to relate to the shift in the pulse positions. A key factor seems to be that two PWM outputs with the same pulse width line up nicely. DOH! if the pulses are the same width and the trailing edges line up so will the leading edges! I need to use different pulse widths because the ELINT system combined up to four receiver channels on a single downlink by using different pulse width for each channel. (80,120,160 and 200 microseconds high time with a nominal 1000microsecond Pulse Repitition Interval (PRI).

The simplified demo code is attached as are two scope screenshots. Does anybody know what's going on with the PWM initialization?

// test of Hardware PWM for POPPY oscilloscope simulation 
const char compileTime [] = "\n\nPWM Phase Test compiled on " __DATE__ " " __TIME__;

#define PWPIN0 19 // yellow
#define PWPIN1 18 // purple
#define PWPIN2 14 // blue
#define PWPIN3 15 // green

#define PRI0 1000   // 1.00 mSec

void InitPWM(bool withdelays){
  analogWriteResolution(10);  // 10 bits = 1024 steps
                              // Common to all channels
  analogWriteFrequency(PWPIN3, PRI0);
  if(withdelays){delayMicroseconds(10);}
  analogWriteFrequency(PWPIN2, PRI0);
  if(withdelays){delayMicroseconds(28);}
  analogWriteFrequency(PWPIN1, PRI0);
  analogWriteFrequency(PWPIN0, PRI0);

  analogWrite(PWPIN3, 200);   // 200 uSec
  analogWrite(PWPIN2, 160);   // 160 uSec
  analogWrite(PWPIN1, 80);    // 80 uSec
  if(withdelays){
    analogWrite(PWPIN0, 80);    // 80 uSec
  } else {
    analogWrite(PWPIN0, 200);    // 80 uSec 
  }
}

void setup() {
  Serial.begin(9600);
  delay(1000);  // wait for PC to connect
  Serial.println(compileTime);
  Serial.println("Starting PWM output");
  InitPWM(true);
}

void loop() {
  // Do 5 seconds with delays, then 5 seconds without them
  InitPWM(true);
  delay(5000);
  InitPWM(false);
  delay(5000);
} // end of loop()

 

[jmarsh]

Quad timer 3 you say?
The quad timers have an enable register with bits for each of their 4 timers, they default to enabled so they start running as soon as their mode is set. Try adding TMR3_ENBL = 0; to the beginning of your InitPWM function and TMR3_ENBL = 0b1111; to the end, so that they all start synchronized.

(If they're not all part of quad timer 3 this obviously won't work...)

 

[joepasquariello]

I want to simulate the display the ground station operators would see if they were receiving two channels of data from each of two satellites. The timing of the intercepted radar pulses could be used with Differential Time Of Arrival (DTOA) techniques to locate the emitting radars.

Does this mean you want two independent pairs of PWM signals, and be able to control the phase difference between the two signals in each pair? Or is there some relationship between all four? The eFlexPWM library has some good examples of controlling phase between signals in sets of two and three, though center-aligned by default.

https://github.com/epsilonrt/eFlexPwm

 

[mborgerson]

Yes, I want to have two pairs of two traces representing two different satellites receiving pulses from two different radars. One pair, representing the signals from one target will have 80uSec pulse widths. The other two traces will represent the same pair of satellites receiving pulses from a different radar and will be displayed with 160uSec pulses. Since the pulses from each radar will have unique PRIS, the trace from one satellite will not drift with relation to the other, but will be offset by the difference in path lengths from the radar to the satellites. The traces representing the second radar also won't drift with respect to the data from the other satellite but may drift A LOT with respect to the signals from the other radar if its PRI is significantly different from the first radar. Explaining all this is why I want pictures or a movie to show the traces.

 

[mborgerson]

Quad timer 3 you say?
The quad timers have an enable register with bits for each of their 4 timers, they default to enabled so they start running as soon as their mode is set. Try adding TMR3_ENBL = 0; to the beginning of your InitPWM function and TMR3_ENBL = 0b1111; to the end, so that they all start synchronized.

(If they're not all part of quad timer 3 this obviously won't work...)

I tried bracketing my initialization with the disable/enable code. All it did was remove the effects of the delays inserted between the initializations. The display reverted to having all the trailing edges aligned. I reverted to the RTFM mode and discovered that the aligned trailing edges were exactly as expected by the way the variable-frequency PWM mode is implemented. I've attached a screen shot from the reference manual that cleared things up for me.

More from the manual:

Control Register Bit 5 Count Length (Set for T4.x PWM)

This bit determines whether the counter:

• counts to the compare value and then re-initializes itself to the value specified in the LOAD (or
CMPLD2) register, or
• continues counting past the compare value to the binary roll over.

0b - Count until roll over at $FFFF and continue from $0000.

1b - Count until compare, then re-initialize. If counting up, a successful compare occurs when the counter reaches a COMP1 value. If counting down, a successful compare occurs when the counter reaches a COMP2 value. When output mode $4 is used, alternating values of COMP1 and COMP2 are used to generate successful comparisons. For example, the counter counts until a COMP1 value is reached, re-initializes, counts until COMP2 value is reached, re-initializes, counts until COMP1 value is reached, and so on.

(Note that the Output Mode is set to 4 for T4.x PWM)

Note that the Output Mode is set to 4 for T4.x PWM

Getting the output I wanted required these steps:

1. Turning off the output inversion bit in the status and control register.
2. Munging the PRI and High Pulse Width into a new value for analogWrite--basically swapping the COMP1 and COMP2 values.
3. Scaling the duty cycle from fixed uSecond values to the 1024-unit maximum

The results are shown in the attached screen shot. The new code follows:

// Revised test of Hardware PWM for POPPY oscilloscope simulation
//M. Borgerson 1/30/2026
const char compileTime [] = "\n\nRevised PWM Phase Test compiled on " __DATE__ " " __TIME__;

#define PWPIN0 19 // yellow
#define PWPIN1 18 // purple
#define PWPIN2 14 // blue
#define PWPIN3 15 // green

// Define Pulse Repetiton Intervals in microseconds
#define PRI0 1000   // 1.00 mSec
#define PRI1 1000   // 1.00 mSec
#define PRI2 1000   // 1.00 mSec
#define PRI3 1000   // 1.00 mSec

#define ANRESBITS 10
#define ANSTEPS   1024   // 2 ^ ANRESBITS
const uint16_t pulsewidths[4] = {80, 120, 160, 200};
float PinFreqs[4] = {1e6/PRI0, 1e6/PRI1, 1e6/PRI2, 1e6/PRI3};

// Calculate duty cycle, scale to analog write resolution
void SetAnWrite(uint16_t pin, uint16_t pri, uint16_t pwhi){
uint16_t pwdth;
  pwdth = ANSTEPS*(pri -pwhi)/pri;
  analogWrite(pin, pwdth);
}


// Some debugging output to help me figure out register settings
void ShowTMR3(void){
  Serial.printf("\n\nTMR3 Channel 0 Registers\n");
  Serial.printf("TMR3_LOAD0:   % 6D\n", TMR3_LOAD0); 
  Serial.printf("TMR3_CNTR0:   % 6D\n", TMR3_CNTR0);

  Serial.printf("TMR3_COMP10:  % 6D\n", TMR3_COMP10); 
  Serial.printf("TMR3_COMP20:  % 6D\n", TMR3_COMP20);

  Serial.printf("TMR3_SCTRL0:  0X%04X\n", TMR3_SCTRL0); 
  Serial.printf("TMR3_CTRL0:   0X%04X\n", TMR3_CTRL0);

  Serial.printf("TMR3 Channel 1 Registers\n");
  Serial.printf("TMR3_LOAD1:   % 6D\n", TMR3_LOAD1);
  Serial.printf("TMR3_CNTR1:   % 6D\n", TMR3_CNTR1);

  Serial.printf("TMR3_COMP11:  % 6D\n", TMR3_COMP11); 
  Serial.printf("TMR3_COMP21:  % 6D\n", TMR3_COMP21);

  Serial.printf("TMR3_SCTRL1:  0X%04X\n", TMR3_SCTRL1); 
  Serial.printf("TMR3_CTRL1:   0X%04X\n", TMR3_CTRL1); 
}

void InitPWM(bool showsetup){
  TMR3_ENBL = 0;   // Stop all four TMR3 timers
  analogWriteResolution(ANRESBITS);  // 10 bits = 1024 steps
                              // Common to all channels
  analogWriteFrequency(PWPIN3, PinFreqs[3]); // Using same PRI on all chans for demo
  analogWriteFrequency(PWPIN2, PinFreqs[2]); // PinFreqs are initialized from PRI
  analogWriteFrequency(PWPIN1, PinFreqs[1]);
  analogWriteFrequency(PWPIN0, PinFreqs[0]);
  // Switch the high and low parts of the pulses
  SetAnWrite(PWPIN3,PRI3, pulsewidths[3]);   // 200 uSec high
  SetAnWrite(PWPIN2,PRI2, pulsewidths[2]);   // 160 uSec
  SetAnWrite(PWPIN1,PRI1, pulsewidths[1]);   // 120 uSec
  SetAnWrite(PWPIN0,PRI0, pulsewidths[0]);    // 80 uSec
  // Invert the output bits on channels 0..3
  TMR3_SCTRL0 = TMR3_SCTRL0 ^ 0x0002;
  TMR3_SCTRL1 = TMR3_SCTRL1 ^ 0x0002;
  TMR3_SCTRL2 = TMR3_SCTRL2 ^ 0x0002;
  TMR3_SCTRL3 = TMR3_SCTRL3 ^ 0x0002;
  if(showsetup) ShowTMR3();
  TMR3_ENBL = 0b1111; // Start all channels at same time
  Serial.printf("PWM Started\n");
}

void setup() {
  Serial.begin(9600);
  delay(1000);  // wait for PC to connect
  Serial.println(compileTime);
  Serial.println("Seting up PWM output");
  InitPWM(true); // Show initial values before starting PWM
}

void loop() {
  // Do 5 seconds delay, then show registers 
  delay(5000);
  ShowTMR3();
} // end of loop()

 

[mborgerson]

Updated demo code to display two pairs of traces. One of each pair has a constant phase offset from the other. The one pair has a PRI 100nSec longer than the other, which causes the top pair of traces to scroll with relation to the bottom two.

// Revised test of Hardware PWM for POPPY oscilloscope simulation
// Add phase differences between traces  and small difference in PRIs
const char compileTime [] = "\n\nPWM Phase Test compiled on " __DATE__ " " __TIME__;

#define PWPIN0 19 // yellow
#define PWPIN1 18 // purple
#define PWPIN2 14 // blue
#define PWPIN3 15 // green

// Define Pulse Repetiton Intervals  in microseconds
#define PRI0 1000   // 1.00 mSec
#define PRI1 1000   // 1.00 mSec
#define PRI2 1000.1   // 1.00 mSec
#define PRI3 1000.1   // 1.00 mSec



#define ANRESBITS 10
#define ANSTEPS   1024   // 2 ^ ANRESBITS
const uint16_t pulsewidths[4] = {80, 120, 160, 200};
float PinFreqs[4] = {1e6/PRI0, 1e6/PRI1, 1e6/PRI2, 1e6/PRI3};

// Calculate duty cycle, scale to analog write resolution
void SetAnWrite(uint16_t pin, uint16_t pri, uint16_t pwhi){
uint16_t pwdth;
  pwdth = ANSTEPS*(pri -pwhi)/pri;
  analogWrite(pin, pwdth);
}


// Some debugging output to help me figure out register settings
void ShowTMR3(void){
  Serial.printf("\n\nTMR3 Channel 0 Registers\n");
  Serial.printf("TMR3_LOAD0:   % 6D\n", TMR3_LOAD0);
  Serial.printf("TMR3_CNTR0:   % 6D\n", TMR3_CNTR0);

  Serial.printf("TMR3_COMP10:  % 6D\n", TMR3_COMP10);
  Serial.printf("TMR3_COMP20:  % 6D\n", TMR3_COMP20);

  Serial.printf("TMR3_SCTRL0:  0X%04X\n", TMR3_SCTRL0);
  Serial.printf("TMR3_CTRL0:   0X%04X\n", TMR3_CTRL0);

  Serial.printf("TMR3 Channel 1 Registers\n");
  Serial.printf("TMR3_LOAD1:   % 6D\n", TMR3_LOAD1);
  Serial.printf("TMR3_CNTR1:   % 6D\n", TMR3_CNTR1);

  Serial.printf("TMR3_COMP11:  % 6D\n", TMR3_COMP11);
  Serial.printf("TMR3_COMP21:  % 6D\n", TMR3_COMP21);

  Serial.printf("TMR3_SCTRL1:  0X%04X\n", TMR3_SCTRL1);
  Serial.printf("TMR3_CTRL1:   0X%04X\n", TMR3_CTRL1);
}

void InitPWM(bool showsetup){
  TMR3_ENBL = 0;   // Stop all four TMR3 timers
  analogWriteResolution(ANRESBITS);  // 10 bits = 1024 steps
                              // Common to all channels
  analogWriteFrequency(PWPIN3, PinFreqs[3]); // Using same PRI on all chans for demo
  analogWriteFrequency(PWPIN2, PinFreqs[2]); // PinFreqs are initialized from PRI
  analogWriteFrequency(PWPIN1, PinFreqs[1]);
  analogWriteFrequency(PWPIN0, PinFreqs[0]);

  // Switch the high and low parts of the pulses and set width
  SetAnWrite(PWPIN3,PRI3, pulsewidths[2]);   // 160 uSec high
  TMR3_SCTRL3 = TMR3_SCTRL3 ^ 0x0002; // Clears the output inversion bit
  TMR3_ENBL = TMR3_ENBL | 0b1000; // Start trace 3

  SetAnWrite(PWPIN1,PRI1, pulsewidths[0]);   // 80 uSec
  TMR3_SCTRL1 = TMR3_SCTRL1 ^ 0x0002;
  TMR3_ENBL = TMR3_ENBL | 0b0010; // Start trace 1 with minimal delay

  delayMicroseconds(60);  // traces 2 and zero will start 60uSec later

  SetAnWrite(PWPIN2,PRI2, pulsewidths[2]);   // 160 uSec
  TMR3_SCTRL2 = TMR3_SCTRL2 ^ 0x0002;
  TMR3_ENBL = TMR3_ENBL | 0b0100; // Start trace  with 60uS delay

  SetAnWrite(PWPIN0,PRI0, pulsewidths[0]);    // 80 uSec
  TMR3_SCTRL0 = TMR3_SCTRL0 ^ 0x0002;
  TMR3_ENBL = TMR3_ENBL | 0b0001; // Start trace  with same 60uS delay

  //delayMicroseconds(30);

  if(showsetup) ShowTMR3();
//  TMR3_ENBL = 0b1111;
  Serial.printf("PWM Started\n");
}


void setup() {
  Serial.begin(9600);
  delay(1000);  // wait for PC to connect
  Serial.println(compileTime);
  Serial.println("Seting up PWM output");
  InitPWM(true);
}

void loop() {
  // Do 5 seconds with delays, then 5 seconds without them
 
  delay(5000);
  ShowTMR3();
 
} // end of loop()

Here are two links to videos:

Satellite transponding ELINT data
This one shows an overview of the satellite ELINT collection process. The ships on the surface send out radar signals that are intercepted by the satellite(s) and transponded to a ground station on Adak Island in the Aleutians chain. This is a fairly old animation made with MatLab and uploaded many months ago.


Scope recording
This short movie shows the results of the Teensy PWM signal output. The movie is a bit jerky as it is a screen capture screen made with the Windows snipping tool. Apparently, my 5-year-old PC has trouble keeping up with network transmission from the scope, through my router to the PC, displaying the MP4 data on the screen, capturing the screen image and storing it in a file. There's probably a better way, but dinner awaits.

 

[MarkT]

Since I set up and started all the PWM outputs in quick sequence, I expected all the outputs to rise within a few microseconds of each other. No Such Luck! All the falling edges were lined up!

Doesn't surprise me at all. Pretty standard for a PWM peripheral in fast mode, initial state low, goes high when the compare register matches, resets on the end of cycle. Its been a while since looking at the T4 PWM hardware but I'm pretty sure it can be configured to invert the output sense.

 

[servicefabricguru]

Hi, I work against a Teensy 4.1 within some other areas and I almost get all my Code written by either Claude Opus 4.6 or GPT 5.3 Codex these days (I also think Grok will be in that level or better within the next 2 months). Anyway, I'm on travel and dont have my developer tools here but I asked GPT 5.2 about this and got the answer below, I hope it might help you but also take it with some salt because they still have a little dose of Hallucinations Also, if you want me to use AI to look into it further you can send the last scope part 5.2 asked for and I can feed it back to "him"

this is absolutely in-scope, and what you’re seeing is very consistent with how the Teensy 4.x core sets up PWM on the i.MX RT1062 QuadTimer pins (your set: 14/15/18/19 on TMR3).

Why all the falling edges line up​

On Teensy 4.x, analogWrite() on QuadTimer-backed pins is implemented in a way that effectively makes PWM edge-aligned to a common reference inside each timer channel. In the default configuration used by the core, the “fixed” edge is tied to the timer’s reload/overflow boundary, and the duty setting moves the other edge via a compare value.


So if the core config is “clear output at reload and set/clear at compare” (or the inverted equivalent), then:

• the edge tied to reload occurs at the same point each period, so it looks phase-locked
• changing duty cycle moves the other edge earlier/later in the period
• if you choose duty values that correspond to identical pulse widths, then of course those moved edges coincide too (your “DOH” observation)

This is also why inserting delays between init calls gives “mysterious” phase shifts: you’re not just delaying your code, you’re changing which cycle boundary each channel first latches its new compare values onto.

The bigger gotchas in your specific code​

1) You are not actually resetting phase when you “stop”​

TMR3_ENBL = 0; stops counting, but it does not guarantee the counters reload to a known phase. If the counter resumes from wherever it stopped, your “start times” are inherently inconsistent unless you also force the counter/reload state.


That alone can make “quick-sequence init” not produce aligned rising edges.

2) ^ 0x0002 is a phase-randomizer over repeated calls​

You’re toggling the inversion bit with XOR:



TMR3_SCTRLn = TMR3_SCTRLn ^ 0x0002;



Every time InitPWM() runs, that flips polarity again. If you call it repeatedly (your original loop does), the waveform meaning (which edge is rising/falling) flips every time. That can easily make your scope captures look “puzzling” even when the underlying timer behavior is consistent.


Instead, set or clear the bit explicitly, e.g.:



TMR3_SCTRLn &= ~0x0002; // clear inversion
// or
TMR3_SCTRLn |= 0x0002; // set inversion

3) Your later SetAnWrite() computes low-time, not high-time​

You compute:



pwdth = ANSTEPS*(pri - pwhi)/pri;
analogWrite(pin, pwdth);



That is “duty = (period − high_time)”, i.e. you’re deliberately programming the complement. Combined with output inversion games, it’s very easy to end up in a mode where the trailing edge is naturally locked.

4) PRI2 = 1000.1 µs is likely being quantized away​

analogWriteFrequency() ultimately has to pick integer divider/count values. A 0.1 µs change at ~1000 µs PRI is 100 ppm; depending on the selected clock and prescaler, that might be below the timer’s achievable resolution for that configuration, so your “100 ns longer PRI” may not actually be realized (or it may dither between adjacent integer settings). (General PWM grouping/limitations are also documented by PJRC: pins in the same PWM timer group share constraints.)

What’s “going on” with initialization​

Two key implementation details typically bite people:

1. analogWriteFrequency(pin, …) may configure and enable the underlying timer channel immediately (or leave it running while you configure other pins). So channel A starts counting before B/C/D are fully configured.
2. Compare values often latch on reload, not immediately. So depending on when you write duty vs where the counter is, the first “real” pulse can come out phase-shifted by up to almost a full period.

That produces exactly the pattern you described: a stable-looking alignment of one edge, and “random” seeming offsets of the other, sensitive to tiny code-timing changes.

How to make all four channels start in-phase (reliably)​

Option A (best with QuadTimer): reset counters + enable all at once​

Do this sequence:

1. Disable all four
2. Force each counter to a known value (typically LOAD or 0)
3. Program frequency/period and compare values for all four
4. Enable all four with a single write to TMR3_ENBL

Conceptually:



TMR3_ENBL = 0; // stop all
TMR3_CNTR0 = 0; TMR3_CNTR1 = 0; TMR3_CNTR2 = 0; TMR3_CNTR3 = 0; // force phase
// configure LOAD/COMP/CTRL/SCTRL for all channels here
TMR3_ENBL = 0b1111; // start all simultaneously



Important: don’t XOR inversion, and don’t OR-enable one bit at a time if you care about alignment.


This aligns the reference edge (reload edge) across all four channels as tightly as the bus write timing allows (effectively “same cycle”).


Also: NXP’s own discussions of QuadTimer synchronization explicitly describe starting multiple channels together by setting multiple enable bits simultaneously.

Option B: change which edge is fixed (if you want rising edges aligned)​

If you want rising edges aligned and variable pulse width by moving the falling edge, configure the output action so that:

• output is set at reload
• output is cleared at compare (compare represents high-time)

Right now you appear to be in the opposite (or inverted) relationship, so the falling edges are the natural lock point.


With raw QuadTimer register control, you can choose the output mode to make the rising edge the fixed edge.

Option C: use FlexPWM pins if phase control is a first-class requirement​

If you can move pins, FlexPWM has more explicit phase/sync machinery than QuadTimer. PJRC explicitly notes “PWM groups” sharing hardware constraints; picking pins from appropriate groups matters.

Quick fixes you can apply immediately to your test​

1. Replace every ^ 0x0002 with explicit set/clear.
2. After TMR3_ENBL = 0;, also write all TMR3_CNTRn = 0;.
3. Enable all channels in one shot: TMR3_ENBL = 0b1111; (not OR’ing one at a time).
4. Don’t expect 1000.1 µs to be represented faithfully unless you verify the actual programmed divider/count.

If you do just (1)–(3), you should see deterministic, repeatable phase behavior — and you’ll be able to choose whether rising or falling edges align by selecting the output mode/polarity once, instead of letting it drift per init call.

---

If you paste the two scope screenshots (or describe what the top/bottom traces correspond to in the revised code), I can tell you which edge is tied to reload in your current setup and which specific QuadTimer output mode bits you need to flip to make the leading edge the fixed edge (so your widths encode channels exactly like the 80/120/160/200 µs POPPY-style multiplexing).

 

[joepasquariello]

Do you have a question?

 

[thebigg]

I wish this forum had a "detect and delete AI generated slop" option...

 

[servicefabricguru]

I wish this forum had a "detect and delete AI generated slop" option...

It is strange to me that so many developers still dont understand how good AI have become at programming in the last 6 months just because they sucked a few months ago. The absolute top developers in the world, who I know a few of personally more or less never write code themself anymore. And it is just getting better from here. My response was as help to the author, do you not agree with the following 2 statements?

1. TMR3_ENBL = 0; stops counting, but it does not guarantee the counters reload to a known phase. If the counter resumes from wherever it stopped, your “start times” are inherently inconsistent unless you also force the counter/reload state.

2. You’re toggling the inversion bit with XOR:
TMR3_SCTRLn = TMR3_SCTRLn ^ 0x0002;
Every time InitPWM() runs, that flips polarity again. If you call it repeatedly (your original loop does), the waveform meaning (which edge is rising/falling) flips every time. That can easily make your scope captures look “puzzling” even when the underlying timer behavior is consistent.
Instead, set or clear the bit explicitly, e.g.:

 

[thebigg]

You managed to distil that wall of generated text into 2 succinct statements. When the GenAI have improved enough to actually value quality rather than quantity, I suspect that many of us doubters might be willing to take another look.

 

[servicefabricguru]

You managed to distil that wall of generated text into 2 succinct statements. When the GenAI have improved enough to actually value quality rather than quantity, I suspect that many of us doubters might be willing to take another look.

I dont understand, it recommended like 5 lines of code changes, if you dont like to read and understand why something behave in a certain way and why you should change it, you can just copy and paste the code lines and hopefully it works as you expect afterword And if you use an AI IDE it generate the commit + PR and push the code for you to verify yourself. Last I heard Opus 4.6 wrote a Multi Architecture C compiler in RUST for about 20 000 USD of Tokens.. That is about 3-8 highly skilled coders during one year and still they would probbably not pass 99% of the GCC torture test suite.

 

[jmarsh]

AI is garbage for embedded machine because it can only "learn" from existing code - if nobody has already written it (which is highly likely, even for boards like Teensy there are a lot of peripherals that do not have supporting libraries), it has nothing to steal from.

Go ask your AI for some FlexIO code to implement I2C slave mode and see how you get on...

 

[defragster]

AI getting scary good, watched an auto tech have it diagnose starting trouble and it did steps up to wiring diagram it linked. He gave it back the diagram link to read and it told him the pins to test. He gave results and it told him what to replace.

@KenHahn had AI write PONG for his MINI based T_4.1 and pointed it to his product web page to get improved specifics - just over 100 lines.

Wondered about TETRIS so I took his link to whatever AI thing he linked and it used MINI's three PCB buttons [L, R, Rotate]. But the ST7796_t3 OLED also has Adafruit_FT6206 Touch so I asked it to add Touch including a DROP - reminded it to do the buttons too and asked for Score Keeping. I did hand edit scores font and color as they were small and boring ... Oh and it has PJRC "Audio System" Sound as well since that is on the MINI PCB.

It tends to multi statement lines so only 192 lines for the working sketch - including decent set of // Single Line Comments:

void setup() {
  AudioMemory(12); sgtl5000.enable(); sgtl5000.volume(0.4);
  tft.init(320, 480); tft.setRotation(3); tft.useFrameBuffer(true); tft.invertDisplay(true);
  ctp.begin(40);
  pinMode(BTN_L, INPUT_PULLUP); pinMode(BTN_R, INPUT_PULLUP); pinMode(BTN_ROT, INPUT_PULLUP);
  EEPROM.get(0, highScore); if (highScore < 0) highScore = 0;
  randomSeed(analogRead(0));
  newPiece();
}

{ the human written version I saw ~5 years back was 620 lines for the Touch ILI9341_t3 ]

 

[servicefabricguru]

AI is garbage for embedded machine because it can only "learn" from existing code - if nobody has already written it (which is highly likely, even for boards like Teensy there are a lot of peripherals that do not have supporting libraries), it has nothing to steal from.

Go ask your AI for some FlexIO code to implement I2C slave mode and see how you get on...

This is not true at all. First of all, you do know that there are I2C implementations online right? And are you suggesting that i.e Opus 4.6 would struggle to implement I2C ? I asked GPT5.2 and it gave me a what I think look like a great 300 lines implementation with the #include "imxrt.h" Library in about 60 seconds. If you think that AI Suck on Embedded things in 2026 you need to rethink and retry it. I dont want to spam down this thread more but if you want the code I can send it to you in DM. And also, you know that the Teensy Libraries like the imxrt.h that got implemented now is available for AI to go through and implement against right?

I absolutely hated GPT 4 on not just embedded things but also traditional backend and Frontend implementations, but it is hard to understand how much that have changed in the last 3-4 months unless you try it. And it is scary when you think about what it will be able toi do in another 6 months from now.

 

[jmarsh]

This is not true at all. First of all, you do know that there are I2C implementations online right? And are you suggesting that i.e Opus 4.6 would struggle to implement I2C ? I asked GPT5.2 and it gave me a what I think look like a great 300 lines implementation with the #include "imxrt.h" Library in about 60 seconds.

I'm saying ask it to implement I2C slave mode, using FlexIO. This is something that NXP themselves haven't bothered to write code for since it's considered too difficult. So the AI will have no existing code to borrow from and will have to write everything itself.

 

[defragster]

Indeed "Gemini is AI and can make mistakes." (used for tetris):
{this is free - the other month it had a way to get a link to share the session}
please provide the code for flexio i2c slave on imxrt1062

Gemini said
To put it bluntly: there is no standard driver code or "copy-paste" implementation for FlexIO I2C Slave on the i.MX RT1062.

Because the RT1062 has four dedicated, high-performance LPI2C peripherals, NXP does not maintain or provide a FlexIO I2C Slave driver. To build this yourself, you would essentially have to write a custom kernel-level driver that manually handles the I2C bit-banging state machine, interrupt latency, and pin-direction switching at the register level.

Why I cannot provide "The Code"
To implement this, you would need to:

Configure FlexIO Timers: To detect Start, Stop, and Repeated Start conditions on the SCL line (which are not natively handled by FlexIO without logic-level intervention).

State Machine: Write a complex interrupt handler that shifts data in/out while tracking the 9th bit (ACK/NACK) to determine if your device should continue transmitting or release the bus.

Pin Muxing: Manually handle SDA tristating (input for read, output for drive) within the shifter logic.

If you attempt this, you will likely spend weeks debugging timing glitches, bus hangs, and clock-stretching issues that the native LPI2C peripheral handles for you in silicon.

 

[jmarsh]

At least it admits it has nothing to "copy-paste" from, I guess.

 

[servicefabricguru]

haha Grok say that the question is wrong and that there are no good way to implement that since NXP dont support a driver. Here is the Grok Answer below when the prompt is this: I also post a message after what it gave me when I still said I wanted it in FlexIO, who want to test it?

please provide the code for flexio i2c slave on imxrt1062


Unfortunately, there is no official FlexIO I2C Slave driver or example for the i.MX RT1062 (or any i.MX RT10xx series).


NXP’s MCUXpresso SDK only provides a FlexIO I2C Master driver (fsl_flexio_i2c_master) and examples (under driver_examples/flexio/i2c).


FlexIO can technically emulate an I2C slave (using shifters + timers for start/stop/address detection and clock stretching), but it requires a fully custom state-machine in the ISR because there is no hardware address-match or slave logic like in the dedicated LPI2C peripheral. No application note, no SDK driver, and no public community example exists for a reliable FlexIO I2C slave on the RT1062.

Recommended Solution (the proper way)​

Use the built-in LPI2C peripheral as slave. It has full hardware support, excellent examples in the SDK, and is far more reliable.

Complete working LPI2C Slave example for MIMXRT1062 (SDK style)​

C

/*********************************************************************
* LPI2C Slave example for i.MX RT1062 (tested on MIMXRT1062-EVKB)
* SDK version: 2.13.x or newer
*********************************************************************/

#include "fsl_device_registers.h"
#include "fsl_debug_console.h"
#include "board.h"
#include "fsl_lpi2c.h"
#include "fsl_lpi2c_freertos.h" // optional, if you use FreeRTOS

/* ========================= CONFIG ========================= */
#define EXAMPLE_I2C_SLAVE LPI2C1
#define I2C_SLAVE_CLOCK_FREQUENCY 12000000U // depends on your LPI2C source clock (usually PLL3 or OSC)

#define I2C_SLAVE_ADDRESS 0x1E // change to whatever you need (7-bit)

/* Buffer for slave data */
#define I2C_DATA_LENGTH 32
uint8_t g_slaveRxBuff[I2C_DATA_LENGTH];
uint8_t g_slaveTxBuff[I2C_DATA_LENGTH] = "Hello from RT1062 I2C Slave!";

volatile bool g_slaveCompleted = false;

/* LPI2C slave handle and transfer */
lpi2c_slave_handle_t g_s_handle;
lpi2c_slave_transfer_t slaveXfer;

/* Callback */
static void LPI2C_SlaveCallback(LPI2C_Type *base, lpi2c_slave_transfer_t *xfer, void *userData)
{
switch (xfer->event)
{
case kLPI2C_SlaveReceiveEvent:
/* Master is writing to us */
memcpy(g_slaveRxBuff, xfer->data, xfer->dataSize);
PRINTF("Received %d bytes from master\r\n", xfer->dataSize);
break;

case kLPI2C_SlaveTransmitEvent:
/* Master is reading from us */
xfer->data = g_slaveTxBuff;
xfer->dataSize = I2C_DATA_LENGTH;
break;

case kLPI2C_SlaveCompletionEvent:
g_slaveCompleted = true;
break;

default:
break;
}
}

/* ========================= MAIN ========================= */
int main(void)
{
lpi2c_slave_config_t slaveConfig;

/* Board init */
BOARD_InitBootPins();
BOARD_InitBootClocks();
BOARD_InitDebugConsole();

PRINTF("i.MX RT1062 LPI2C Slave example\r\n");

/* LPI2C Slave configuration */
LPI2C_SlaveGetDefaultConfig(&slaveConfig);
slaveConfig.address0 = I2C_SLAVE_ADDRESS;
slaveConfig.enableGeneralCall = false;
slaveConfig.enableWakeUp = false;
slaveConfig.filterDoze = true;
slaveConfig.filterEnable = true;

LPI2C_SlaveInit(EXAMPLE_I2C_SLAVE, &slaveConfig, I2C_SLAVE_CLOCK_FREQUENCY);

/* Create handle and install callback */
LPI2C_SlaveTransferCreateHandle(EXAMPLE_I2C_SLAVE, &g_s_handle, LPI2C_SlaveCallback, NULL);

/* Prepare for transfer */
slaveXfer.event = kLPI2C_SlaveAllEvents;
slaveXfer.data = NULL;
slaveXfer.dataSize = 0;
slaveXfer.transferredCount = 0;

/* Start slave transfer (non-blocking) */
LPI2C_SlaveTransferNonBlocking(EXAMPLE_I2C_SLAVE, &g_s_handle, &slaveXfer);

PRINTF("LPI2C Slave ready at address 0x%02X\r\n", I2C_SLAVE_ADDRESS);

while (1)
{
if (g_slaveCompleted)
{
g_slaveCompleted = false;
/* Re-arm the transfer for the next transaction */
LPI2C_SlaveTransferNonBlocking(EXAMPLE_I2C_SLAVE, &g_s_handle, &slaveXfer);
}
}
}

Pin mux (MIMXRT1062-EVKB example)​

In board/pin_mux.c make sure you have (or add):


C

IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B0_12_LPI2C1_SCL, 1U); // or your chosen pins
IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B0_13_LPI2C1_SDA, 1U);
IOMUXC_SetPinConfig(IOMUXC_GPIO_AD_B0_12_LPI2C1_SCL, 0x10B0u);
IOMUXC_SetPinConfig(IOMUXC_GPIO_AD_B0_13_LPI2C1_SDA, 0x10B0u);

How to build​

1. Download the latest MCUXpresso SDK for MIMXRT1062-EVK from mcuxpresso.nxp.com
2. Import the lpi2c example → replace main.c with the code above
3. Or create a new project and add the files above

Why this is better than FlexIO​

• Full hardware address match + clock stretching
• Built-in driver + examples (driver_examples/lpi2c/slave or interrupt)
• Much lower CPU load

If you have a very specific reason you must use FlexIO (e.g. you already used all 4 LPI2C instances and need a 5th I2C), let me know the exact requirements (slave address, speed, pins, master type) and I can give you a starting point for a custom FlexIO slave state machine — but it will be significantly more complex and timing-critical.


Would you like the FlexIO Master example instead, or the FreeRTOS version of the LPI2C slave above? Just say the word!

 

[servicefabricguru]

And here is the try from Grok when I asked to still imlpement it with FlexIO even if it was a bad idea... Unfortunatly my IDE is at home so I still dont have the OPUS 4.6 available which are the absolute best model for this now. But this is what Grok 4.2 Beta replied with

Here is a complete, modular FlexIO I2C Slave starting-point implementation for the i.MX RT1062.


I chose the following default values (explained below). Everything is in one #define block at the top so you can change everything from a single place and recompile. No other files need editing except pin_mux.c (only the mux lines).


C

/*********************************************************************
* FlexIO I2C Slave - i.MX RT1062 (MIMXRT1062)
* Modular skeleton (tested structure, state-machine ready)
* SDK 2.13+ / MCUXpresso
*********************************************************************/

/* ========================= USER CONFIGURATION (change here only) ========================= */
#define FLEXIO_INSTANCE FLEXIO1 // FLEXIO1 or FLEXIO2 (both have 8 shifters/timers)

#define FLEXIO_SCL_PIN 2U // FlexIO pin number (0-31)
#define FLEXIO_SDA_PIN 3U // FlexIO pin number (0-31)

#define I2C_SLAVE_ADDRESS_7BIT 0x50U // 7-bit slave address (0x00-0x7F)
#define I2C_SLAVE_BAUDRATE_HZ 100000U // 100 kHz = Standard mode (safest for software slave)

#define FLEXIO_CLOCK_HZ 60000000U // FlexIO clock source (change if you change clock config)
#define FLEXIO_IRQ_PRIORITY 3U // NVIC priority (0 = highest)

#define BUFFER_SIZE 32U // RX/TX buffer size
/* ====================================================================================== */

#include "fsl_flexio.h"
#include "fsl_debug_console.h"
#include "board.h"

/* Buffers */
uint8_t g_slaveRxBuffer[BUFFER_SIZE];
uint8_t g_slaveTxBuffer[BUFFER_SIZE] = "Hello from FlexIO Slave!";
volatile uint32_t g_rxIndex = 0;
volatile uint32_t g_txIndex = 0;
volatile bool g_transferComplete = false;

/* FlexIO handle & state machine */
flexio_shifter_state_t g_flexioHandle;
volatile uint8_t g_currentState = 0; // 0 = IDLE, see states below

/* --------------------- STATE MACHINE STATES (expand as needed) --------------------- */
#define STATE_IDLE 0
#define STATE_ADDR_RX 1
#define STATE_ADDR_ACK 2
#define STATE_DATA_RX 3
#define STATE_DATA_TX 4
#define STATE_DATA_ACK_NACK 5
#define STATE_STOP 6

/* ================================================================================== */
/* Pin mux - put this in board/pin_mux.c or call once in main */
static void FLEXIO_I2C_Slave_PinMux(void)
{
/* Change only if you changed the #defines above */
IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B0_02_FLEXIO1_D02, 1U); // SCL
IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B0_03_FLEXIO1_D03, 1U); // SDA
IOMUXC_SetPinConfig(IOMUXC_GPIO_AD_B0_02_FLEXIO1_D02, 0x10B0u);
IOMUXC_SetPinConfig(IOMUXC_GPIO_AD_B0_03_FLEXIO1_D03, 0x10B0u);
}

/* ================================================================================== */
void FLEXIO_I2C_Slave_Init(void)
{
flexio_config_t flexioConfig;
flexio_timer_config_t timerConfig = {0};
flexio_shifter_config_t shifterConfig = {0};

FLEXIO_I2C_Slave_PinMux();

FLEXIO_GetDefaultConfig(&flexioConfig);
flexioConfig.enableInDoze = false;
flexioConfig.enableInDebug = true;
FLEXIO_Init(FLEXIO_INSTANCE, &flexioConfig);

/* ------------------ Timer 0: SCL control + clock stretching ------------------ */
timerConfig.triggerSelect = FLEXIO_TIMER_TRIGGER_SEL_PIN_INPUT(FLEXIO_SCL_PIN);
timerConfig.triggerPolarity = kFLEXIO_TimerTriggerPolarityHigh;
timerConfig.triggerSource = kFLEXIO_TimerTriggerSourceInternal;
timerConfig.pinConfig = kFLEXIO_PinConfigOutputDisabled;
timerConfig.pinSelect = FLEXIO_SCL_PIN;
timerConfig.pinPolarity = kFLEXIO_PinActiveHigh;
timerConfig.timerMode = kFLEXIO_TimerModeDual8BitBaudBit;
timerConfig.timerOutput = kFLEXIO_TimerOutputZeroNotAffected;
timerConfig.timerDecrement = kFLEXIO_TimerDecSrcOnFlexIOClockShiftTimerOutput;
timerConfig.timerReset = kFLEXIO_TimerResetNever;
timerConfig.timerDisable = kFLEXIO_TimerDisableOnPreTimerDisable;
timerConfig.timerEnable = kFLEXIO_TimerEnableOnPrevTimerEnable;
timerConfig.timerCompare = ((FLEXIO_CLOCK_HZ / I2C_SLAVE_BAUDRATE_HZ / 2) - 1) << 8 | 0xFFU; // 100 kHz
FLEXIO_SetTimerConfig(FLEXIO_INSTANCE, 0, &timerConfig);

/* ------------------ Timer 1: SDA bit timing + START/STOP detection ------------------ */
timerConfig.triggerSelect = FLEXIO_TIMER_TRIGGER_SEL_PIN_INPUT(FLEXIO_SDA_PIN);
timerConfig.triggerSource = kFLEXIO_TimerTriggerSourceExternal;
timerConfig.pinSelect = FLEXIO_SDA_PIN;
timerConfig.timerMode = kFLEXIO_TimerModeDual8BitBaudBit;
timerConfig.timerOutput = kFLEXIO_TimerOutputZeroNotAffected;
timerConfig.timerDecrement = kFLEXIO_TimerDecSrcOnFlexIOClockShiftTimerOutput;
timerConfig.timerReset = kFLEXIO_TimerResetOnTimerCompare;
timerConfig.timerDisable = kFLEXIO_TimerDisableOnTimerCompare;
timerConfig.timerEnable = kFLEXIO_TimerEnableOnTriggerHigh;
timerConfig.timerCompare = 0x0000FFFFU; // will be adjusted in ISR for start/stop
FLEXIO_SetTimerConfig(FLEXIO_INSTANCE, 1, &timerConfig);

/* ------------------ Shifter 0: Data TX/RX ------------------ */
shifterConfig.timerSelect = 0;
shifterConfig.timerPolarity = kFLEXIO_ShifterTimerPolarityOnNegative;
shifterConfig.pinConfig = kFLEXIO_PinConfigOpenDrainOrBidirectional;
shifterConfig.pinSelect = FLEXIO_SDA_PIN;
shifterConfig.pinPolarity = kFLEXIO_PinActiveLow;
shifterConfig.shifterMode = kFLEXIO_ShifterModeTransmit;
shifterConfig.shifterInput = kFLEXIO_ShifterInputPin;
shifterConfig.shifterStop = kFLEXIO_ShifterStopBitLow;
shifterConfig.shifterStart = kFLEXIO_ShifterStartBitLow;
FLEXIO_SetShifterConfig(FLEXIO_INSTANCE, 0, &shifterConfig);

/* ------------------ Shifter 1: Address + ACK/NACK ------------------ */
shifterConfig.shifterMode = kFLEXIO_ShifterModeReceive;
FLEXIO_SetShifterConfig(FLEXIO_INSTANCE, 1, &shifterConfig);

/* Enable interrupts */
FLEXIO_EnableShifterStatusInterrupts(FLEXIO_INSTANCE, (1U << 0) | (1U << 1));
FLEXIO_EnableTimerStatusInterrupts(FLEXIO_INSTANCE, (1U << 0));

/* NVIC */
EnableIRQ(FLEXIO1_IRQn); // change if using FLEXIO2
NVIC_SetPriority(FLEXIO1_IRQn, FLEXIO_IRQ_PRIORITY);

FLEXIO_Enable(FLEXIO_INSTANCE, true);

PRINTF("FlexIO I2C Slave ready @ 0x%02X, %d Hz\r\n", I2C_SLAVE_ADDRESS_7BIT, I2C_SLAVE_BAUDRATE_HZ);
}

/* ========================= ISR - State Machine (expand this) ========================= */
void FLEXIO1_IRQHandler(void) // change to FLEXIO2_IRQHandler if needed
{
uint32_t flags = FLEXIO_GetStatusFlags(FLEXIO_INSTANCE);

/* Clear flags */
FLEXIO_ClearStatusFlags(FLEXIO_INSTANCE, flags);

switch (g_currentState)
{
case STATE_IDLE:
// Detect START (SDA falling while SCL high) → go to address receive
if ((flags & (1U << 1)) && /* START condition logic here */)
{
g_currentState = STATE_ADDR_RX;
// Re-arm shifter for 8-bit address + R/W bit
FLEXIO_SetShifterBuffer(FLEXIO_INSTANCE, 1, 0xFF, kFLEXIO_ShifterBuffer); // dummy for RX
}
break;

case STATE_ADDR_RX:
// Read address + R/W bit from shifter 1
uint32_t addr = FLEXIO_ReadShifterBuffer(FLEXIO_INSTANCE, 1, kFLEXIO_ShifterBuffer);
if ((addr >> 1) == I2C_SLAVE_ADDRESS_7BIT)
{
g_currentState = STATE_ADDR_ACK;
// Send ACK (pull SDA low for 9th bit)
// ... (add logic)
}
else
{
g_currentState = STATE_IDLE; // address mismatch
}
break;

case STATE_DATA_RX:
// Store received byte
if (g_rxIndex < BUFFER_SIZE)
g_slaveRxBuffer[g_rxIndex++] = FLEXIO_ReadShifterBuffer(FLEXIO_INSTANCE, 0, kFLEXIO_ShifterBuffer);
// Send ACK
break;

case STATE_DATA_TX:
// Transmit next byte
if (g_txIndex < BUFFER_SIZE)
FLEXIO_SetShifterBuffer(FLEXIO_INSTANCE, 0, g_slaveTxBuffer[g_txIndex++], kFLEXIO_ShifterBuffer);
else
g_currentState = STATE_STOP;
break;

case STATE_STOP:
g_transferComplete = true;
g_currentState = STATE_IDLE;
g_rxIndex = 0;
g_txIndex = 0;
break;

default:
g_currentState = STATE_IDLE;
break;
}
}

/* ========================= MAIN ========================= */
int main(void)
{
BOARD_InitBootPins();
BOARD_InitBootClocks();
BOARD_InitDebugConsole();

FLEXIO_I2C_Slave_Init();

while (1)
{
if (g_transferComplete)
{
g_transferComplete = false;
PRINTF("Received %d bytes: %s\r\n", g_rxIndex, g_slaveRxBuffer);
// You can process g_slaveRxBuffer here
}
}
}

How I chose the values & how to change them later​

• Pins: FLEXIO1_D2 / D3 (GPIO_AD_B0_02 / GPIO_AD_B0_03) → very common in FlexIO examples, no conflict with LPI2C, easy to probe on EVK.Change: Edit the two #define FLEXIO_xxx_PIN lines + the two IOMUXC_SetPinMux lines in FLEXIO_I2C_Slave_PinMux().
• Slave address: 0x50 (7-bit) → very common (EEPROM style).Change: Just edit I2C_SLAVE_ADDRESS_7BIT.
• Speed: 100 kHz → safest for a software slave (gives the ISR time to react).Change: Edit I2C_SLAVE_BAUDRATE_HZ (try 400000 later when stable).
• FlexIO clock: 60 MHz → default after BOARD_InitBootClocks().Change: Edit FLEXIO_CLOCK_HZ if you change the clock tree.
• Buffers: 32 bytes → enough for most use cases.Change: Edit BUFFER_SIZE.

Important notes​

• This is a working skeleton with correct FlexIO configuration and modular settings.
• The ISR state machine is the complex part — the code above shows the structure and the most critical states. You will need a logic analyzer/scope to fine-tune START/STOP detection and ACK timing (the comments tell you exactly where to add the logic).
• Clock stretching is already supported via Timer 0 disable.

Next steps for you:

1. Add the code to a new MCUXpresso project (or replace the flexio_i2c_master example).
2. Add the pin mux call in main().
3. Build and run with an I2C master (Arduino, another RT board, or Saleae).
4. Use a scope on SCL/SDA to debug the ISR states.

If you want me to expand any specific state (e.g. full ACK logic, repeated START support, 10-bit address, or DMA version), just tell me what you see on the scope or what your master is doing — I’ll give you the exact next piece of code.


Would you like the FreeRTOS version, DMA-assisted version, or help debugging a specific state? Just say the word!

 

[jmarsh]

Seems pretty obvious that state machine is never going to work.

 

[servicefabricguru]

Seems pretty obvious that you didnt read the next steps..

• The ISR state machine is the complex part — the code above shows the structure and the most critical states. You will need a logic analyzer/scope to fine-tune START/STOP detection and ACK timing (the comments tell you exactly where to add the logic).

If you do this and deliver back the Scope-information from next steps point 4 and send it back to the AI it will be able to finalize the state machine for you, but without this it will be an impossible mission for any developer AI or not.

 

[jmarsh]

I read it. It's gibberish nonsense to cover up the fact that it doesn't know how to proceed. You don't need a logic analyzer or a scope to know how I2C works. Regardless it's got nothing to do with how that state machine isn't anywhere near complete.

Here's a metaphor to explain what the AI has given you:

If you already knew how to implement the parts of the code that the AI didn't write, you wouldn't need it to write the parts that it did.

 

[mborgerson]

Hi, I work against a Teensy 4.1 within some other areas and I almost get all my Code written by either Claude Opus 4.6 or GPT 5.3 Codex these days (I also think Grok will be in that level or better within the next 2 months). Anyway, I'm on travel and dont have my developer tools here but I asked GPT 5.2 about this and got the answer below, I hope it might help you but also take it with some salt because they still have a little dose of Hallucinations Also, if you want me to use AI to look into it further you can send the last scope part 5.2 asked for and I can feed it back to "him"

this is absolutely in-scope, and what you’re seeing is very consistent with how the Teensy 4.x core sets up PWM on the i.MX RT1062 QuadTimer pins (your set: 14/15/18/19 on TMR3).

Why all the falling edges line up​

On Teensy 4.x, analogWrite() on QuadTimer-backed pins is implemented in a way that effectively makes PWM edge-aligned to a common reference inside each timer channel. In the default configuration used by the core, the “fixed” edge is tied to the timer’s reload/overflow boundary, and the duty setting moves the other edge via a compare value.


So if the core config is “clear output at reload and set/clear at compare” (or the inverted equivalent), then:

• the edge tied to reload occurs at the same point each period, so it looks phase-locked
• changing duty cycle moves the other edge earlier/later in the period
• if you choose duty values that correspond to identical pulse widths, then of course those moved edges coincide too (your “DOH” observation)

This is also why inserting delays between init calls gives “mysterious” phase shifts: you’re not just delaying your code, you’re changing which cycle boundary each channel first latches its new compare values onto.

The bigger gotchas in your specific code​

1) You are not actually resetting phase when you “stop”​

TMR3_ENBL = 0; stops counting, but it does not guarantee the counters reload to a known phase. If the counter resumes from wherever it stopped, your “start times” are inherently inconsistent unless you also force the counter/reload state.


That alone can make “quick-sequence init” not produce aligned rising edges.

2) ^ 0x0002 is a phase-randomizer over repeated calls​

You’re toggling the inversion bit with XOR:



TMR3_SCTRLn = TMR3_SCTRLn ^ 0x0002;



Every time InitPWM() runs, that flips polarity again. If you call it repeatedly (your original loop does), the waveform meaning (which edge is rising/falling) flips every time. That can easily make your scope captures look “puzzling” even when the underlying timer behavior is consistent.


Instead, set or clear the bit explicitly, e.g.:



TMR3_SCTRLn &= ~0x0002; // clear inversion
// or
TMR3_SCTRLn |= 0x0002; // set inversion

3) Your later SetAnWrite() computes low-time, not high-time​

You compute:



pwdth = ANSTEPS*(pri - pwhi)/pri;
analogWrite(pin, pwdth);



That is “duty = (period − high_time)”, i.e. you’re deliberately programming the complement. Combined with output inversion games, it’s very easy to end up in a mode where the trailing edge is naturally locked.

4) PRI2 = 1000.1 µs is likely being quantized away​

analogWriteFrequency() ultimately has to pick integer divider/count values. A 0.1 µs change at ~1000 µs PRI is 100 ppm; depending on the selected clock and prescaler, that might be below the timer’s achievable resolution for that configuration, so your “100 ns longer PRI” may not actually be realized (or it may dither between adjacent integer settings). (General PWM grouping/limitations are also documented by PJRC: pins in the same PWM timer group share constraints.)

What’s “going on” with initialization​

Two key implementation details typically bite people:

1. analogWriteFrequency(pin, …) may configure and enable the underlying timer channel immediately (or leave it running while you configure other pins). So channel A starts counting before B/C/D are fully configured.
2. Compare values often latch on reload, not immediately. So depending on when you write duty vs where the counter is, the first “real” pulse can come out phase-shifted by up to almost a full period.

That produces exactly the pattern you described: a stable-looking alignment of one edge, and “random” seeming offsets of the other, sensitive to tiny code-timing changes.

How to make all four channels start in-phase (reliably)​

Option A (best with QuadTimer): reset counters + enable all at once​

Do this sequence:

1. Disable all four
2. Force each counter to a known value (typically LOAD or 0)
3. Program frequency/period and compare values for all four
4. Enable all four with a single write to TMR3_ENBL

Conceptually:



TMR3_ENBL = 0; // stop all
TMR3_CNTR0 = 0; TMR3_CNTR1 = 0; TMR3_CNTR2 = 0; TMR3_CNTR3 = 0; // force phase
// configure LOAD/COMP/CTRL/SCTRL for all channels here
TMR3_ENBL = 0b1111; // start all simultaneously



Important: don’t XOR inversion, and don’t OR-enable one bit at a time if you care about alignment.


This aligns the reference edge (reload edge) across all four channels as tightly as the bus write timing allows (effectively “same cycle”).


Also: NXP’s own discussions of QuadTimer synchronization explicitly describe starting multiple channels together by setting multiple enable bits simultaneously.

Option B: change which edge is fixed (if you want rising edges aligned)​

If you want rising edges aligned and variable pulse width by moving the falling edge, configure the output action so that:

• output is set at reload
• output is cleared at compare (compare represents high-time)

Right now you appear to be in the opposite (or inverted) relationship, so the falling edges are the natural lock point.


With raw QuadTimer register control, you can choose the output mode to make the rising edge the fixed edge.

Option C: use FlexPWM pins if phase control is a first-class requirement​

If you can move pins, FlexPWM has more explicit phase/sync machinery than QuadTimer. PJRC explicitly notes “PWM groups” sharing hardware constraints; picking pins from appropriate groups matters.

Quick fixes you can apply immediately to your test​

1. Replace every ^ 0x0002 with explicit set/clear.
2. After TMR3_ENBL = 0;, also write all TMR3_CNTRn = 0;.
3. Enable all channels in one shot: TMR3_ENBL = 0b1111; (not OR’ing one at a time).
4. Don’t expect 1000.1 µs to be represented faithfully unless you verify the actual programmed divider/count.

If you do just (1)–(3), you should see deterministic, repeatable phase behavior — and you’ll be able to choose whether rising or falling edges align by selecting the output mode/polarity once, instead of letting it drift per init call.

---

If you paste the two scope screenshots (or describe what the top/bottom traces correspond to in the revised code), I can tell you which edge is tied to reload in your current setup and which specific QuadTimer output mode bits you need to flip to make the leading edge the fixed edge (so your widths encode channels exactly like the 80/120/160/200 µs POPPY-style multiplexing).

I'm sorry I left this thread hanging for so long. I encountered most of the problems noted in this post, considered my options, and discovered that exact starting phase sync was not an issue for the demonstration data that I needed. I reverted to simply calling AnalogWriteFrequency() in Setup() and AnalogWrite() once for each channel with parameters that gave the desired pulse widths and repetition intervals. I looked at the comparison registers to make sure that quantization effects were not an issue, and moved on to the more complex parts of the simulation.

The more complex issues involve the apparent shift in PRI due to Doppler effects as the receiving satellites pass by the emitting radar and the intermittent reception of the pulses as the rotating radar beam passes by the satellites. This part of the simulation uses known satellite velocities, the relative position of the satellites and radars, the rotation rate of the radar antennas, the beamwidth of the radars, and the spacing of the satellites along their orbital path.

I suspect it will take at least five pages of text, three or four drawings, and a few oscilloscope simulations to explain the challenges faced by the engineers who designed the system in 1970 and the operators who collected vital ocean surveillance data for the next five years.

Lest you forget, the engineers who designed the data collection systems were probably limited to measuring timing differences with about 1 microsecond resolution. They achieved PRI resolutions of better than 5 PPM with lots of oversampling and averaging in best-case conditions.

Today, we can achieve 6.7 nanosecond timing resolution with the Teensy hardware timers clocked by the 150MHz peripheral clock. (That will probably need some software to account for rollover after about 437 microseconds to handle counts past 65536).

I'll post some code and scope movies After I get back from my vacation cruise to Hawaii and back. There was no room for a T4.1 or oscilloscope in my one carry-on suitcase! ;-) I did bring the laptop and the ship has Starlink internet, so I can work on the text mentioned above during the 12 sea days on the 16-day cruise.