AnsweredAssumed Answered

Silicon bugg in TIM_CCMR1_IC1PSC and TIM_CCMR1_IC1F?

Question asked by tjerneld.mikael on Oct 11, 2015
Latest reply on Oct 11, 2015 by tjerneld.mikael
In a function depending on ICF1F and IC1PSC beeing zero, no filter, no clock divide for a input
capture to DMA request with input frequency of max 3-4 Mhz. DMA move byte data from
memory to TIM CCR. Original application is for a72Mhz 103. Additional tests was made on
F100RBT Discovery VL and F334R8T6 Nucleo.F100 and F103 are years old, F334 is a
month old. Test has only been done on TIM4 and TIM2.On F334 TIM2 was used.
Capture to DMA trigg is somewhat complicated/complex/tideous thing to setup.
No idea if a simple capture with no DMA request triggers the same fault sequence.

For 100RBT:
IC1PSC divides only by 4 and 0 , no 2 or 8.ICF1F behaves somewhat erratically.  

For 103C8:
IC1PSC beeing not 0 out of reset, i had to write zero to make it zero.
IC1F is somewhat erratically,skip pulses at random.

For F334R8T6:
IC1PSC dont work at all, constant no div.

Using same setup code (as far it is possible) and application code on all 3 devices.

So far on 100RBT device i disscovered that TIM4->CCMR1 |= TIM_CCMR1_OC1FE;
(CC1 Fast enable) seams to interfer with both IC1F and IC1PSC it do not matter if delay
is incerted between CC1 Fast enable  and everything else or if its set first or prior to
TIM enable.

For 100RBT:
If CC1 Fast is disabled PSC can be set normally.

No idea if anything i have discovered have a valid ground to stand on or else.
I will conduct some more testing for the F334 later, eventually for the 103C.

If others have discovered same strange behavioural of TIM'ers on same or
other devices it would be nice to know