Silicon bugg in TIM_CCMR1_IC1PSC and TIM_CCMR1_IC1F?

[mikael239955_stm1_st]

Posted on October 11, 2015 at 19:31

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

[Tesla DeLorean]

Posted on October 11, 2015 at 19:59

DMA move byte data from memory to TIM CCR.

It's more than 8-bit wide, and it's normally a shadow register. I know the F4 gets squirrelly if you copy a 16-bit word to a 32-bit TIM register via DMA. The prescaler on the TIM is opaque (the internal count is invisible), and the TIM inputs are on the back end of a synchronizer circuit. ie pulling signals into it's clock domain, and sampling in the nyquist sense. Not seeing 3-4 MHz being an issue there. I think the input prescale is on the back end of that, but again it's internal count is invisible. If I was going to present a case to the validation engineers, I'd have some clearly demonstrable code and conditions.

[mikael239955_stm1_st]

Posted on October 11, 2015 at 21:32

Great! Just as i was about to press OK to send my finisheed reply ST forum decided to junk it all and present a unidentifed ERROR!  Twice!

It's more than 8-bit wide, and it's normally a shadow register. I know the F4 gets squirrelly if you copy a 16-bit word to a 32-bit TIM register via DMA. i meant mem to CCR from a programers wiev point not what hapends internally in various width translations. In which way do the F4 squirelness present it self since all CCR is 16 bits? and also because i have tremendous problems with the F334, even at 1,5Mhz. In one (one of many) tests i have same external/internal trigger driving 2 capature c's to stress arbiting and priority handling at the same time as CPU is runing a 50khz Systic ISR who wiggles a leg , when frequency is at higher end alising is noticeable on a 24 Mhz F100 device and DMA goes flat yet still no dop of transactions nor any drop of  ISR 's but ISR get slightely stretched just prior to DMA going flat, nice feature. All tests works nicely on the F103 but on F334 at 1,5Mhz drops in DMA transactions is noticeable and gets worse untill CPU even kills it selfs and all leg toggling ends only way out is  hard reset. In the mean time while CPU is on the graveyard DMA transactions happily continues.The prescaler on the TIM is opaque (the internal count is invisible), and the TIM inputs are on the back end of a synchronizer circuit.ie pulling signals into it's clock domain, and sampling in the nyquist sense. Not seeing 3-4 MHz being an issue there. I think the input prescale is on the back end of that, but again it's internal count is invisible. Only ST know what FAST enable do and where its connected on gate level, but it clearly cuses malfunction to hapend. If I was going to present a case to the validation engineers, I'd have some clearly demonstrable code and conditions. It's way to tideous/time consuming for me to present a specific fault case..so many ways to setup, ST have aquality lab they should do it if they are interested. as they did last year with the F373 who hade the wrong DFU code programmed  into billions of devices!