[STM32F303] ADC synchronization through TRGO2 not working on TIM1

[kpavlata9]

Posted on April 10, 2014 at 17:01

Hi, I'm having problem with synchronizing ADC (tested 1 and 3) with TRGO2 output of TIM1.

I'm using timer link between TIM1 (master) and TIM8 (slave in combined reset-trigger mode) through TRGO, so TIM1 determines the frequency and timers stay locked - it works fine. Now I'm using OC6ref as TRGO2 source for both timers to trigger ADC conversion. TIM1 for ADC1 and TIM8 for ADC3. The TRGO2 signal from TIM8 is working fine, even setting it to ADC1 works so both of the ADCs get triggered. But TRGO2 signal of TIM1 does not work for either of the ADCs. Does anyone experienced something like that? Any advice or comment welcomed.thanks,karel #adc #stm32f303 #synchronization

[Tesla DeLorean]

Posted on April 10, 2014 at 18:05

Does anyone experienced something like that?

It's easy to screw up the settings/configuration.

[kpavlata9]

Posted on April 10, 2014 at 18:26

yes, of course it is a valid comment and I thank you for that, yet not very constructive..

I have all the configuration in structures and the same code is configuring TIM1/8 and ADC1/3.excerpt from config:TIM1:.. .slave_mode = 0, .master_slave_mode = TIM_MasterSlaveMode_Enable, .itr = TIM_TS_ITR0, .trgo = TIM_TRGOSource_Enable, .trgo2 = TIM_TRGO2Source_OC6Ref,..TIM8:.. .slave_mode = TIM_SlaveMode_Combined_ResetTrigger, .master_slave_mode = TIM_MasterSlaveMode_Disable, .itr = TIM_TS_ITR0, .trgo = TIM_TRGOSource_Enable, .trgo2 = TIM_TRGO2Source_OC6Ref,..ADC1:..    .ADC_ContinuousConvMode = DISABLE,    .ADC_Resolution = ADC_Resolution_12b,    .ADC_ExternalTrigConvEvent = ADC_ExternalTrigConvEvent_10,     .ADC_ExternalTrigEventEdge = ADC_ExternalTrigEventEdge_RisingEdge,     .ADC_DataAlign = ADC_DataAlign_Left,    .ADC_OverrunMode = DISABLE,    .ADC_AutoInjMode = DISABLE,    .ADC_NbrOfRegChannel = 1,..ADC3:..    .ADC_ContinuousConvMode = DISABLE,    .ADC_Resolution = ADC_Resolution_12b,    .ADC_ExternalTrigConvEvent = ADC_ExternalTrigConvEvent_8,     .ADC_ExternalTrigEventEdge = ADC_ExternalTrigEventEdge_RisingEdge,     .ADC_DataAlign = ADC_DataAlign_Left,    .ADC_OverrunMode = DISABLE,    .ADC_AutoInjMode = DISABLE,    .ADC_NbrOfRegChannel = 1, ..reference manual:Table 35. ADC1 (master) & 2 (slave) - External triggers for regular channelsName |     Source                   |              Type                               | EXTSEL[3:0]EXT8 | TIM8_TRGO2 event | Internal signal from on chip timers | 1000EXT10 | TIM1_TRGO2 event |  Internal signal from on chip timers | 1010Table 37. ADC3 & ADC4 - External trigger for regular channelsName |     Source                   |              Type                               | EXTSEL[3:0]EXT10 | TIM1_TRGO2 event |  Internal signal from on chip timers | 1010EXT8 | TIM8_TRGO2 event | Internal signal from on chip timers | 1000so just by changing the bold setting from EXT10 to EXT8, the triggering works for both the ADCs, if both of them are set to EXT10 the trigger never arrives. Both OC6 are configured in the same way, the same problem was when as a source of TRGO2 I used Update.

[Tesla DeLorean]

Posted on April 10, 2014 at 19:00

yes, of course it is a valid comment and I thank you for that, yet not very constructive..

The pool isn't very deep here, I'm not interested in (re)constructing code from scratch to demonstrate this issue. Please look at how I present example code, and build a free standing, and compilable example that fully demonstrates your issue. Use the standard firmware library. Asking if others have ventured into some weird corner condition of the part and it's application, and expecting an answer, totally misses how forums, and especially this one, work.

[waclawek.jan]

Posted on April 10, 2014 at 22:43

I'd try to confirm that the TIM1 TRGO2 signal works as intended. As there does not appear a direct way to do that, for a trial, I'd generate it from a compare which could be redirected to physical output (i.e. OC1 through OC4).

I'd also read back the relevant registers (mainly TIM1_CR2, the timebase and the compare-related registers) to confirm they are set as intended. JW

[kpavlata9]

Posted on April 11, 2014 at 12:47

@clive

The pool isn't very deep here, I'm not interested in (re)constructing code from scratch to demonstrate this issue. Please look at how I present example code, and build a free standing, and compilable example that fully demonstrates your issue. Use the standard firmware library.

Asking if others have ventured into some weird corner condition of the part and it's application, and expecting an answer, totally misses how forums, and especially this one, work. Hi, thank you for answer. As a non native english speaker I just guess that by pool not being very deepyou meant you have not enough information to provide relevant answer. If otherwise, please correct me so I can learn something new besides what was the original question. Regarding my not very well formulated question, I had no intention to bother whoever to that level to compile some code - I just wanted to know if anyone came over such an issue - but lesson learned and I hope I have now better understanding of how forums, and especially this one, works. If you are still interested in running some test code, find it attached below. br k. ________________ Attachments : main.c : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1Mt&d=%2Fa%2F0X0000000bm1%2FFD7SpccdfL77DeYAefxJXDBTEgVvAcc7qJeLblSwoso&asPdf=false

[kpavlata9]

Posted on April 11, 2014 at 13:10

Hi,

thanks. I found the reason of the problem in something I consider a bug in standard peripheral library.

void
TIM_SelectOutputTrigger(TIM_TypeDef* TIMx, uint16_t TIM_TRGOSource)

{

/* Check the parameters */

assert_param(IS_TIM_LIST7_PERIPH(TIMx));

assert_param(IS_TIM_TRGO_SOURCE(TIM_TRGOSource));


/* Reset the MMS Bits */

TIMx->CR2 &= (uint16_t)~TIM_CR2_MMS;

/* Select the TRGO source */

TIMx->CR2 |= TIM_TRGOSource;

}

At line 8 in the above snippet form std periph. library the mask to clear the MMS bitfield is explicitly cast to uint16_t type: i.e. this operation does not clear only the intended MMS field, but also the upper 16 bits of CR2 register. CR2 being 32 bits wide and MMS2 fields belonging to the upper 16 bits, it just gets cleared by calling this function somewhere in the code. Because I'm using TIM1 as a master, I call this function after starting it to change TRGO form enable to update. My compiler (arm-none-eabi-gcc-4_8q4 fromhttps://launchpad.net/gcc-arm-embedded/) generates following code to do the job:

1.
movw r3, #65423 ; 0xff8f
2.
ands r3, r2

without the cast (the mask is explicitly defined as 32bit) the generated instruction is

1.
bic.w r2, r3, #112 ; 0x70

Now, the same kind of problem (bitnegating the 32bit mask and casting it to 16bits) is spread throughout the whole library. Is it really a bug or am I missing something? Did anyone before have any issues like this with standard firmware library? (my version isV1.0.1 form date 23-October-2012) downloaded directly form the st.com sites. If this really is a bug, is there any standard way how to report it? If you are interested in testing it on your own, the example code is in my previous post karel

[waclawek.jan]

Posted on April 11, 2014 at 13:54

Yes, this is a bug, but there might be a reason, sort of - I did not go through all families, but it appears that only 'F3 has defined bits higher than 16 in TIMx_CR2.

> If this really is a bug, is there any standard way how to report it? https://my.st.com/onlinesupport/app?page=onlineSupport You might say a word on this also on our local mailing list at list.hw.cz . JW