0

I am using STM32 cubeMX for configuration and Keil for programming. Have set onboard led pin pc13 pin as an output pin and default in push-pull mode. Set debugger to the serial wire as I am using ST-link V2 as a debugger. RCC set HSE to crystal/ceramic resonator. and clock configuration set to default and generated project. enter image description here

enter image description here

enter image description here

Now I started with a simple LED blink program. As below

    HAL_GPIO_TogglePin(led_GPIO_Port,led_Pin);
    HAL_Delay(1000);

build successfully with no error and uploaded and wonder my led was not blinking and shocked as I have done this before and now this is not working. when I debugged step by step and my code was just going from two functions repeatedly.

  while ((HAL_GetTick() - tickstart) < wait)
  {
  }

__weak uint32_t HAL_GetTick(void)
{
  return uwTick;
}

Nothing happens more in this code I know the code is right but there is some error in the HAL_delay configuration. After scratching my head for a day I tried uploading the following code

    HAL_GPIO_TogglePin(led_GPIO_Port,led_Pin);
    HAL_Delay(100);

And strange thing is that now my led is blinking only I have change the HAL_dealy value from 1000 to 100 and it works fine but, when using 1000 does not work at all. So for testing, I gradually increased the delay value and I find that more than HAL_delay(400) it does not work.

Not able to find cause for this Any help will be appreciable.

As suggested by Tom I debugged uwTickFreq using STstudio. and I got the following output waveform. enter image description here

After that, I also uploaded the following code. And defined a variable as "unsigned long int a;"

    HAL_GPIO_TogglePin(led_GPIO_Port,led_Pin);
    HAL_Delay(100);
    a= HAL_GetTick();

Now I debugged the value of a using STstudio. And strange the value of a becomes 0 once it reached around 300. enter image description here

Dharmik
  • 44
  • 4
  • What is the value of uwTickFreq, of tickstart and of uwTick each time through? – Tom V Feb 06 '21 at 07:48
  • The code you have posted is clearly not where the error is. You have been too aggressive in the fragments you have shown. Showing good code _fragments_ and asking why they don't work will get you guessed not answers. – Clifford Feb 06 '21 at 08:20
  • @TomV I found the following line of code designed in my Keil project. HAL_TickFreqTypeDef uwTickFreq = HAL_TICK_FREQ_DEFAULT; /* 1KHz */ – Dharmik Feb 06 '21 at 09:38
  • I know that line, but can you use the debugger to examine the contents of the variables? – Tom V Feb 06 '21 at 10:52
  • @TomV I have debugged few things see the attached waveform image I got from STstudio. I don't think the value of variable a should reset once it reaches around 300 right? – Dharmik Feb 06 '21 at 14:27
  • It seems that something is writing to that variable that should not. Are you able to set a data watchpoint on the uwTick variable? Alternatively are you able to look through the build output to see if any other point in the code references the symbol? If you are using the GNU linker try the flag -Wl,-Map=file.map, or else maybe run `nm` on each of your build objects. – Tom V Feb 06 '21 at 16:47
  • @TomV adding uwTick to watch window in Keil it is not showing any value. today in my code I defined one pin as an output pin and set its state to high on startup. I uploaded code without any hal timing function and setting that pin to low in code. The result was led at the pin was not glowing that's fine. Now I introduce one more line in my code a= HAL_GetTick(); and set the pin to low and uploaded the code and now I see my led is blinking like slightly glow and gets OFF quickly as code resets the pin. the conclusion seems like the controller is resetting itself on sing hal_delay functions. – Dharmik Feb 07 '21 at 05:55
  • You aren't trying to drive the LED directly from PC13 without a FET are you? Because that pin is not able to source or sink any current. – Tom V Feb 07 '21 at 13:28
  • @TomV PC13 has an onboard LED in the bluepill board. First was trying with that and after just to verifying I was using the PB11 pin directly connected with LED and the current limiting resistor was facing the same issue. But by changing 3 optional bytes shown below in the answer the problem was fixed. – Dharmik Feb 07 '21 at 13:58

1 Answers1

0

It seems like finally, I got the problem when I noticed the reset problem in the controller I searched around and find something here.

So I checked my optional bytes set in MCU with the STM32 cube programmer. It was set as below.

enter image description here

Therefore I enabled these three optional bytes.

enter image description here

And the problem of reset was gone and I am now able to use the HAL_delay function properly and now the value of HAL_GetTick() is also increasing more than 300.

Still have one dought I think watchdog was causing reset but why it only cause that when I use the timing function.

Dharmik
  • 44
  • 4