STM32F405: Can we use Port A0 (T2.1-ETR or T8 ETR) to trigger a capture on Port A5 (T2.1-ETR or T8.1)?

[GeoffF]

When we enable the RTC feature on our controllers, we do a calibration in Production against a GPS-locked 10MHz signal. Usually, we'll use the T2 ETR to clock the 10MHz signal in and an RTC-generated 1Hz signal on one of the other T2 channels such as T2.4 to capture the count.

On a new design, our hardware engineer allocated the 1Hz input signal on PA0 (T2.1-ETR) and the 10MHz in on PA5 (also T2.1-ETR). I didn't realise this would be a problem until we came to testing the PCBA.

I had a thought about using T8 instead, but I can't easily see how to make the ETR input trigger the capture instead of the channel input.

For the prototypes, we may need to hand-modify the boards to swap some leads around.

[GeoffF]

After discussion, we can't use T8 as it's only 16 bit and our calibration algorithm needs 32 bits.

[waclawek.jan]

Extend it to 32-bit in software. Yes, there's the ambiguity with capture at around the rollovers, but that's a relatively basic thing to solve especially in case of well-known and relatively precise inputs.

However, I personally would not consider wasting two pins for the external interconnection just for this purpose (although it might be an option if the pins are straight brought out to some sort of a header for any reason and there could be looped back in the calibration jig) and would use the internal interconnection from LSE to TIM5. Now as it is connected now, this might get a bit tricky, but it should be possible to set PA5/TIM2_CH1 as straight input capture, set TIM2_CR2.MMS=0b011 to output TRGO upon the ill-named "compare-pulse", and then use TIM5's slave-mode controller to run with external clock from appropriately set TRGI.

JW

[GeoffF]

Thanks for the response Jan,

Our RTC calibration procedure and code is used and well-proven in a lot of products here, so I'm reluctant to change it too much.

As DI4 is unused at the moment, for our prototypes we just bridged PA0 and PA1 and changed the 1Hz capture code to use T2.2. The next iteration will swap those two pins.

Since I have a lot of other projects to work on, we'll leave it at that. However, if I were to continue trying to get the software to handle this mis-routing, I'd probably prefer to use PA5/T2.1-ETR2 to clock the timer and use T5.1 to output the capture signal instead (since that's what it's meant to be doing). Basically, we're trying to count the 10MHz transitions that occur in the nominally 1-second period output by the RTC, then we adjust the RTC trim.