STM32 TIM TI2FP2 GPIO very high input current on pin problem

[HWhit.1]

I am trying to make a precise delayed pulse for my project that does not use interrupts. I plant to use TIM1 or TIM8 on a STM32H7A3 using the TI2FP2 input to trigger and reset the counter in one-pulse mode.  I tried the method describe in website.  Controllerstech.com  https://controllerstech.com/stm32-timers-9-one-pulse-mode/   This worked as expected when a switch to the +3.3 V line was used as a trigger. When I connected to a open-collector LVTTL  output the trigger pulse disapeared.  It turned out the  electrical impedance was extremely low. after HAL_TIM_OnePulse_Start(&htim8,TIM_CHANNEL_1); was executed.

I measured the current from the +3.3 V line to the TI2FP2 input (PE7) to be 102 mA. I would expect this to be max a few microamps.

STM32 Timers #9. One Pulse Mode || Retriggerable OPM

The problem was reproduced for TIM1 and TIM15 on the same board and also TIM1 on a STM32L476 board - so it seems to be a problem with the HAL.

My questions:

(i) What does the reset state on a GPIO pin mean? Does this mean the input is connected to ground?

(ii) Is it possible to correct this by writing to GPIOE_MODER register to set to the alternate fumction to set the mode on PE7 to 0x2  (= alternate function)?

I am grateful advice on how to deal with this.

 

 

[Tesla DeLorean]

Sounds like there's something egregiously wrong with your circuit to the point the pins are probably damaged at this point.

Provide a circuit diagram of exactly what you've wired. Check the ground situation. 

[TDK]

Reset state is the state the pin is at after reset. Generally pins are in high impedance mode. They are not connected to ground.

102 mA going into a pin is indicative of a hardware failure. Perhaps the pin has been subject to an overvoltage condition.

> I am grateful advice on how to deal with this.

Not much you can do about a hardware failure. Use a different pin, replace the chip or buy a new board.

Measure the current draw when the chip is in reset (NRST pin low). If it's still very high, the chip is damaged.

> The problem was reproduced for TIM1 and TIM15 on the same board and also TIM1 on a STM32L476 board - so it seems to be a problem with the HAL.

There is nothing that the software can do to cause 102 mA to go into a pin. Current sink/source is limited to about 30 mA on a pin.

Could also be that you're misinterpreting reading somewhere. If it's happening with multiple boards, this is more likely. You can check that the pin is configured correctly by examining the registers directly.

[waclawek.jan]

> You can check that the pin is configured correctly by examining the registers directly.

Note, that when a pin is set to AF in its respective GPIOx_MODER field and to a Timer's AF in GPIOx_AFR[], it's the Timer which controls whether that pin is turned to Output or not, by setting it to Output Compare in TIMx_CCMRx.CCxS=0b00 (and enabling it in TIMx_CCER.CCxE, and also TIMx_BDTR.MOE in Timers with complementary outputs).

Read: it's not enough to look at the GPIO registers to determine, what state a pin is in.

JW

.

[HWhit.1]

Jan,

Thanks for pointing out that the pin state is governed by the combination of the TIM8 settings and the GPIO that determines the pin state. On your advice, I dug a bit deeper into what settings could cause the very low impedance the STM32H7A3 PE7 which is set to TIM8 TI2FP2 input. This is an input pin that triggers and resets TIM8.

As far as I understand from the below the TIM8 settings seem to be OK. The only register that could influence PE7 is SMCR where input TI2FP2 is set as a trigger to the control block. Looking at Figure 315 in the reference manual, I don’t think the break circuitry acts TIM8_CH2 input that feeds TI2FP2. As the code works, even with TIM1 as well as on other type of STM32 and the only problem is the 102 mA drawn by pin PE7 when connected to +3.3 V. I believe the problem is with GPIOE. In GPIOE_ MODER as MODE7 seems to be incorrectly set, probably by the HAL code. Figure 73 in the manual indicates that the alternate mode input is fed from the pin via a Schmitt  trigger which will present a high impedance to the pin. So if the analogue line in Fig. 73  is grounded, as seems to be the case, this could account for the problem of the high current drawn.

The register settings and interpretations are listed below for TIM8 and GPIOE. I attached the code for the STM32L476 board as this is cleaner and shorter than the one for the STM32H7A3 board.

Thanks for the other replies. I don't believe the problem is a damaged board as (i) the PE7 pin was connected to +3.3 V via a push button switch and the the voltage was checked first with a multimeter. (ii)  Before the HAL_TIM_OnePulse_Start(&htim1,TIM_CHANNEL_1); command is executed, the input is in a high impedance state.(iii) The pin still functions OK in other modes (iv) The problem occurs also for TIM1 on a completely unused STM32L476 board exactly as it did for TIM1 on the H7A3 board I am using for the application.

Fig. 73 in the reference manual suggests that putting PE7 into alternate mode by a register write may correct the problem. As noted above the alternate function line is behind a Schmitt trigger, so doing this should not cause any detrimental effects. I will try this in the next days.   

Many thanks!

 

GPIOE

MODER is set to 0x5802100 (some pins used for other purposes)

Mode7 is 0x3 which corresponds to the reset state on PE7.

PUPDR 0x100: PUPD7 = 0x0  - No pull up/down.

 

TIM8

CR1 = 0x8: OPM true

SR = 0x1: UIF true

SMCR 0x10060: TS = 0x6 TI2FP2 is trigger  SMS_3 = 0x1 slave mode

CCMR1 Output/input 0x10010: OC1M = true OC1_F set active level on match

CCIR 0x11: CC2E = 0x1 capture compare enable , IC1F = 1 Capture compare OC1 enabled

PSC 0x103:  Prescale register

ARR 0xc34f: Auto reload register

CCR1 0x270: value loaded in capture compare reg 1

BDTR 0x200a00: BKP = 1 break1 active high, MOE = 1 main outputs enabled,  BK2P = 1 break2 active high

AF1 0x1: BKINE = 1 break input enabled

AF2: 0x1: BK2EN = Break 2 input enabled

All other registers are 0x0

 

[waclawek.jan]

MODER is set to 0x5802100 (some pins used for other purposes)

Mode7 is 0x3 which corresponds to the reset state on PE7.

MODE7 are bits 14 and 15, which are 0b00, that's Input (not default which would be weird, and not even AF which would be expected since you would want to use it as TIMx_CHx).

As others said, symptoms indicate board damage. What board is this? Is there anything else connected to that pin?

JW

[HWhit.1]

Jan,

 

Thanks once again for your efforts to help me!

I took thought about your point about not having anything connected. I decided this would make debugging simpler to use the Nucleo-L476RG board (which has only been exposed to a multimeter) and work on that in isolation. (The Nucleo H7A3ZI-Q which I am using to develop the full application has other peripherals set up.)  So, I changed back to the Nucleo-L476RG board and used TIM1. All the other settings are default in the .ioc file.

The pins used by TIM1 are PA8 for TIM1_CH1 output (OC1) and  PA9 for TIM1_CH2 input (TI2FP2). I managed to pin down a bit mire where the problems is.

 

In debugging, after execution of HAL_Init(); the impedance of PA9 to ground was high. I modified the code slightly so I could have debugger breakpoints immediately before and after HAL_TIM_OnePulse_Start(&htim1, TIM_CHANNEL_1); is executed.

Before this command is executed the impedance to ground was high and the registers were:

GPIOA

MODER

  Mode8  = Mode0 = 0x2

OSPEED

  OSPEED8 = OSPEED= 0

PUPDR

  PUPDR8 = PUPDR9 = 0

IDR

  IDR9 = IDR8 = 1

AFRH

  AFR8 = AFR9 = 1

 

TIM1

CR1: 0x8

  OPM = CEN = 1

CR2 :0x100

  OIS1 = 1

SMCR: 0x66

  TS=0x6 SMS = 0x6

SR: 0x30505f

  TIF = CC4IF = CC3IF = CC2IF = CC1IF =UIF = 1

CCMR output: 0x100100

  OC1M = 1

CCMR input: 0x100100

  ICIF = 1

CCER: 0x2

  CC1P = 1

PSC: 0x4f

ARR: c34f

CCR1: 0x270f

BDTR: 0x2002000

  MOE = 0 BMP = 1

DMAR: 0x9

  DMAB = 0x9

OR2: 0x1

  BKINE = 1

OR3: 0x1

  B2KINE = 1

 

After execution of HAL_TIM_OnePulse_Start(&htim1, TIM_CHANNEL_1); the resistance drops for pin PA9 to ground  to about 140 Ohms. The GPIOA registers for pins PA8 and PA9 are unchanged. The following TIM1 registers are however, changed.

CR1: 0x8

  CEN -> 0

CCER: 0x13

  CC2E -> 1, CC1E -> 1

BDTR: 0x200a000

  MOE ->1

DMAR: 0x8

  DMAB –> 0x8

 

The reproducible change in impedance when this the above line is executed suggests that the low impedance is not likely to be due to a damaged chip. I checked the power supply voltages and these are OK. Also, since MODER is unchanged – the problem is likely to be elsewhere.

 

Looking at what the registers do in the manual and looking how the registers change I believe  setting CEN -> 0 is OK, MOE -> turns on the OCR output(s) so this is also OK. Why DMAB which has to do with DMA changed, I don’t understand, but it should not have any effect because DMA is not used. What now looks suspicious to me is CCER, where according to the manual CC2E would set the output on channel 2 which is TI2FP2 to a capture compare output.  This, I think, would put PA9 to 0 and this could account for the low impedance.  I can try a register write to CCER to set CC2E to zero. However, I will leave that till later to avoid making mistakes.

 

Many thanks again!

[PKurz.1]

Hi

In my opinion this is an obvious bug in CubeMX.
I have exactly the same problem with STM32F303 (nukleo32)
Only setting CH2 as in the attached picture fixes the problem.

 

 

 

[waclawek.jan]

> I have exactly the same problem with STM32F303

What exactly is the "exactly the same problem", what are its symptoms and what were the settings at which those symptoms were exhibited?

JW

[waclawek.jan]

> (If Cube would be perfect, it should show a warning: "Set used channel as input, to use input signal TIxFPy." )

I don't get it. Is the complaint here, that a pin assigned to TIM channel set to Output Compare, is actually Output?

JW

[AScha.3]

Your close. :)

Not setting a channel as anything seems to set the OC on, after the timer start/compare. (HAL_TIM_OnePulse_Start())

As @HWhit.1 writes : Before this command is executed the impedance to ground was high ...

I never had a problem with this, but i also never forgot to set the used inputs as inputs.

Works as expected then.

[waclawek.jan]

Oh, now I see.

HAL_TIM_OnePulse_Start() is NOT what you'd think based on its name.

It's a recurring theme here.

JW

[HWhit.1]

Hi,

Even when CC2 is set to input in ititialise by:

if (HAL_TIM_OnePulse_Init(&htim8, TIM_OPMODE_SINGLE) != HAL_OK)
{
Error_Handler();
}
sSlaveConfig.SlaveMode = TIM_SLAVEMODE_COMBINED_RESETTRIGGER;
sSlaveConfig.InputTrigger = TIM_TS_TI2FP2;
sSlaveConfig.TriggerPolarity = TIM_TRIGGERPOLARITY_RISING;
sSlaveConfig.TriggerFilter = 0;
if (HAL_TIM_SlaveConfigSynchro(&htim8, &sSlaveConfig) != HAL_OK)
{
Error_Handler();
}
sMasterConfig.MasterOutputTrigger = TIM_TRGO_RESET;
sMasterConfig.MasterOutputTrigger2 = TIM_TRGO2_RESET;
sMasterConfig.MasterSlaveMode = TIM_MASTERSLAVEMODE_DISABLE;
if (HAL_TIMEx_MasterConfigSynchronization(&htim8, &sMasterConfig) != HAL_OK)
{
Error_Handler();
}

The pin pin became low impedance to ground exactly when HAL_TIM_OnePulse_Start(&htim15,TIM_CHANNEL_1); was executed. The solution was to do a direct register write directly afterwards to set bit CC2E to zero which disables OC2 and the pin reverts to a high impedance state where it acts as an input. The code is for TIM15,

HAL_TIM_OnePulse_Start(&htim15,TIM_CHANNEL_1);
TIM15->CCER = TIM15->CCER & 0xffffffef ;

This extra line resolved the problem for me.

The problem seems to have the character of a bug in HAL because to my mind executing a HAL_TIM_OnePulse_Start should not modifiy the initialised register values as to which channels are set to input compare and which are set to output compare. However, there might be an underlying reason for doing this - but it is not obvious to me as to why this should be so.

H.

 

[AScha.3]

Hi,

i used only other modes, not "one pulse" , so maybe just one pulse has a problem.

I could try it on (just have it here) F303 , TIM3 . ch1 as TI1FP1 , ch3 as output (to see on scope).

To check: is it a bug in HAL - or ... 

[waclawek.jan]

Please read what I wrote above, and the links I've given there.

Also, please read the associated documentation.

Just reiterating: HAL_TIM_OnePulse_Start() and its "framework" is *not* what you think based on its name, i.e. it's *not intended* to produce one single pulse on one output of the timer upon calling this function. It is intended to demonstrate one particular example from the RM (which is one of the many examples which don't not belong to RM and should be moved to an AN, but that's another issue), namely this one:

So, it always uses *two* channels, one set as input, and other as output. If you don't set them using the methods intended (which I am not interested in finding out, but you should really examine the example in Cube which is intended to demonstrate HAL_TIM_OnePulse_Start()), those two channels will set neither as you intended, nor as that example intended.

As you may have noticed, I don't use Cube/HAL, so I am not really interested in getting it more usable.

JW