Precisely timed latching

[luke2]

Posted on January 17, 2016 at 09:21

So I am running and STM32F0 at 48Mhz with TIM1 clocked to an external clock source running at 24.576MHz. On GPIO-A is connected a bus synced to the external 24.576Mhz clock. At occasional intervals I want to latch a value on the bus based on a tick count on TIM1. Obviously since the timing requirements are very tight, the delays inherent in TIM1 and its CCs/DMA become very important. One approach I have thought about is using an OC on TIM1 that triggers a DMA transfer, however I have noted that timing may be difficult in this case as there is a noticeable delay before the transfer happens. Another approach might be using an external latch and generating a latch pulse on a TIM1 OC, although I believe there are going to be delays associated with OCs that will probably be relevant here also. Is there a way to latch a GPIO at a precise clock tick and then immediately stop latching to save IDR state?

I suppose my main issue currently is being able to ensure I can latch a value on the port with precise enough timing that it matches up with the desired tick on the 24.576MHz clock. Perhaps there is a way to adjust the OC timing with a short delay to make sure it aligns with the incoming clock signal and latches the correct value on the port (i.e. delay until the next pulse and set the OC a pulse earlier)?

I also need to occasionally put data on the bus for a single tick and then return the port to a high impedance state. I'm not sure this is possible with the MCU itself, although I can attach an external latch, put a value on it then generate a pulse to open the latch which will return to high impedance state once the line returns low. Obviously the pulse timing is very important here, and would need to output a one tick pulse to the latch from TIM1 OC.

Perhaps there is no practical way to get this kind of strict timing at the given core clock speed and I need to add some external components to calibrate the delay, then trigger pulses a tick earlier than required? Are the TIM1/OC delays predictable enough to ensure such a solution would work?

Thanks in advance for any comments

[Tesla DeLorean]

Posted on January 17, 2016 at 15:35

As described this doesn't sound at all viable.

Consider using an FPGA/CPLD where you have a common clock, at the 24.576 MHz, or a multiple thereof, ie 49.152 MHz

[luke2]

Posted on January 17, 2016 at 17:16

Doing a quick experiment, although the OC pulse output is delayed approx 100ns from the clock edge, it actually looks stable enough to get a stable latch (at least with a 24MHz signal), although I would need a way to calibrate the output delay to sub-bit timing. The maximum edge timing difference error seems to be about 25-30ns which is close to the max 41.4ns of a tick at this speed but probably workable. I guess the question is whether I can accurately calibrate a delay on the output to within 10ns, if so this just might work.

What would your main concern be if you were attempting such a thing?

[Tesla DeLorean]

Posted on January 17, 2016 at 19:17

You need a synchronous clock here, not two independent sources, with unique drift characteristics and intermodulation. Find a part you can clock at 49.125 MHz

The front end of the STM32 has synchronizers on the inputs, these will exhibit nyquist like sampling issues.

I'm not sure these are things you can calibrate out, you are working with integer dividers, and very course granularity, with little control. It's more likely to saw-tooth over 41ns rather than stick at 10ns

[luke2]

Posted on January 18, 2016 at 05:58

I presume an STM32F0 can not be overclocked to 49.152MHz? I guess I could use an 8.192MHz crystal and run the core at 40.96MHz, or some some better multiple to get close to 48MHz? The bus and core clocks can actually use a common crystal, which will presumably make timing errors minimal.

Thanks again

[luke2]

Posted on January 18, 2016 at 07:39

On reflection I could potentially try to lower the bus speed to 15.36MHz then use the same clock to drive the STM32 with a 3x prescalar for 46.08MHz. That would give me three cycles per bus tick which I think would be enough leeway to get reliable timing properties. I may even be able to get away with a 23.808MHz bus and 47.616MHz core if they are sharing clocks, and with a bit of thought - perhaps with a capacitor + schmitt trigger circuit I could calibrate a simple short signal delay to align edges?

What do you think?

[Tesla DeLorean]

Posted on January 18, 2016 at 15:24

Well the HSI on the part has a range of 46.656 .. 49.824 MHz over temperature. So providing 49.152 MHz from a ppm source wouldn't be entirely unreasonable. Not going to be usable for USB/CAN, but it's not clear if you are using that.

I still think this is better solved with logic, in an FPGA/CPLD. These processors aren't designed to process MHz signals in software.