Problem while enabling TIM2 in STM32G041J6M6

[Tommino]

Hello,

I am using the TIM2 with the STM32G041J6M6 and I am finding problems while enabling TIM2 using registers

With some code I have initiated the timer as reported below (TIM2 clock is enabled)

While debugging I can edit some timer registers (ARR,PSC,CCR,SMCR...) directly in the SFRs tab of STM32IDE but not the CR1 and CR2 registers.

If I put this line in my code

TIM2-> CR1|= (1<<0);

At the end the TIM2 is not enabled and a mess appears on the corresponding output pin,the GPIOA MODER and RCC IOPAEN are affected and cannot be modified on-the-fly in the SFRs tab anymore.

All this behaviour sounds weird to me....

Any idea why this can happen?

Regards

[S.Ma]

Make sure compiler compiles for the right memory mapping ie the right target mcu in project configuration.

Hw registers should be manually edited in debug mode when code is stopped by breakpoint never use live watch.

For sw to actually write cr, make sure peripheral is clock enabled, then enabled. Maybe write twice to check if it is same result.

[Tommino]

Hi,

Thanks for the reply. However I am still observing the same problem

• The target MCU in the STM32IDE is the right one
• the write to the TIM2 CR1 register is the last thing done.
• Writing twice in CR1 does not change the behaviour

[Tommino]

Hi @S.Ma​ 

I investigated a bit mote the issue and it seems that it comes out with every configuration on pin 4

 

I have keep testing a simple code reported on the bottom.

I have seen that a mess on the pin 4 comes out you can see from the screenshot (before there was a timer now I have GPIOs ), the MODER registers values are incorrect and they become unchangable during debug. This happens regardless the mode set on the other ports on the same pin 4. 

If from my code I remove the part regarding port pin 4 (PA1) it all works well for PA12 and PB1 and all the registers are correctly set and changable during debug.

The latter makes me think that it could be a FW issue. Do you have any idea? The NRST is not used...for debugging i am only using SWIO and SWCLK

 RCC->IOPENR|=(1<<0); // enable gpioa clock
 
 GPIOA->MODER &=~ (1<<25);//PA12 set as output
 
 GPIOA->MODER &=~ (1<<3);//PA1 set as output
 
  RCC->IOPENR|=(1<<1); // enable gpiob clock
 
 GPIOB->MODER&=~ (1<<3);//PB1 set as output
 
 
 
 while (1)
 
 {
 
 	 GPIOA->BSRR|=(1<<12);
 
	 GPIOB->BSRR|=(1<<1);
 
	 GPIOA->BSRR|=(1<<1);
 
	 HAL_Delay(10);
 
 
 
	 GPIOB->BSRR|=(1<<17);
 
	 GPIOA->BSRR|=(1<<28);
 
	 GPIOA->BSRR|=(1<<17);
 
	 HAL_Delay(10);
 
 }

[waclawek.jan · Accepted solution]

On pin 4, NRST is physically bonded together with other port pads. Unless you disable NRST in option bytes, pulling it low by any of those port pads causes the mcu to reset. Disabling NRST of course then has other consequences, e.g. you won't be able to "connect under reset" anymore.

This is why the SO-8 package is a tricky one and generally not very suitable for development (i.e. develop your application on a different package connected in the same way, and use the SO8 packaged device only for mass production).

JW

[Tommino]

Hi @Community member​ 

Thanks a lot for the reply.

Can you give us the details about how to disable NRST pin?

I tried to write 01 on these bits but it did not work. It keeps staying to 11 (i am not able to change them while debugging)

[waclawek.jan]

Read the whole FLASH option bytes subchapter.

Option bytes are not the registers, but are stored in the system FLASH, read out upon reset by system and used by the system to modify internal behaviour.

FLASH_OPTR is just a plain register which does not act on the system (it serves to allow to check what was programmed into the option bytes, and as a holding register during programming).

The easiest way to modify the option bytes is by STLink Utility, Cube Programmer, or similar.

I repeat, switching off the NRST function does have consequences, so think twice before you do it.

JW

[S.Ma]

Use cube programmer to access option byte. Once done, if your code has core stop low power mode, at least add a 0.5 sec delay at user code start to be able for stlink to try to grab the mcu before it migth execute any user low power mode or any code awol situation.