STM32WL5x: Undocumented Bug in IRTIM Module

[AJ_1]

Hello,

I have been developing a program on the NUCLEO-WL55JC1 development board, and I found a bug in the IRTIM module. The reference manual says that, when enabled, the IRTIM module will NAND the outputs of TIM16 and TIM17 and output the signal on a pin. The bug I found is that if TIM17_BDTR.MOE is set before TIM16_BDTR.MOE is set, the IRTIM module outputs a high signal until TIM17 counts to TIM17_CCR1 for the first time. If TIM17_CCR1 is greater than TIM17_ARR, the output stays high forever.

I have attached a simple program that demonstrates the issue. It uses STM32 Low Level Drivers and is designed to run on a NUCLEO-WL55JC1. On this development board, the IR_OUT pin is connected to LED2, so you can see the IRTIM output signal. Both TIM16 and TIM17 are configured to always be high, and since IRTIM NANDs the signals together, LED2 should never turn on. However, when the program is initially run, LED2 is on until the first time TIM17 counts to CCR1.

I did not see this issue listed in the errata, so I'm assuming it's an unknown issue and wanted to report it to ST.

[waclawek.jan]

I have reproduced the problem on a 'G0B1.

And I investigated further. Turns out, the IRTIM does not work as documented, as a simple NAND. Instead, IRTIM appears to work like this:

• there is an edge detector at the input from TIM17_CH1
• if there's a rising edge at TIM17_CH1 AND the input level of TIM16_CH1 is high at the same time,
  output goes down, otherwise it stays high
• if output is already low and there's a falling edge at TIM17_CH1, regardless of TIM16_CH1 state the output goes high

In other words, a pulse is "copied" (and inverted) from TIM17_CH1 to output, if at TIM17_CH1 rising edge TIM16_CH1 is high.

The probable reason for this scheme is, that at the output, negative pulses (as they intend to drive a LED from the lower N transistor) have always the same length as TIM17_CH1 pulses. It is anticipated that TIM17_CH1 is the carrier, i.e. higher-frequency input (if it would be plain NAND, it wouldn't matter).

Bottom green waveform is TIM16_CH1 and top blue is IR_OUT (btw. a bad way to call the IRTIM output, as one can't find it by textual search for "IRTIM"). Note how the output pulses are all uniform, even if the last of them "hangs over" beyond the TIM16_CH1 "envelope's" trailing edge.

---

As I've already had things wired up, I was curious about which clock is used in the TIM17_CH1 edge detector. This is rising-edge waveform with all clocks at reset default: bottom green waveform is TIM17_CH1 and top blue is IR_OUT (note, that due to TIM16_CH1 envelope the output pulse is not always present with the input pulse, and this is an averaged display of many runs of the oscilloscope, that's why the blue waveform has "both polarities" after the edge):

Difference is cca 1/16MHz (due to default HSI16 clock). At this point, there's only one single 16MHz clock in the whole mcu, so we've established that the edge detector's latency is 1 clock. Now let's set APB divider to 2 by setting RCC_CFGR.PPRE=0b100  (note, that due to the "timers clock rule", timers are still clocked by the original 16MHz):

Whoa.

A quick experiment with TIM17_ARR reveals, that this "double edge" is present only if TIM17_ARR is even (i.e. the real division ratio is odd); it returns to "single edge" if ARR is odd.

This is consequence of the fact, that IRTIM TIM17_CH1 is sampled at APB = AHB/2 clock, whereas TIM17 is clocked twice as fast, which at odd division rates results in the TIM17_CH1 edge's "phase" changing in respect to APB edge.

Using APB divider of 4 results in the expected "twice slower" waveform:

JW