Basic problem with Code

Discussions concerning TrueSTUDIO for STM32 9.0.0 and later versions.

Moderators: Markus Girdland, Mattias Norlander

Frolgo
Posts: 4
Joined: Tue Feb 13, 2018 5:56 pm

Basic problem with Code

Postby Frolgo » Sun Dec 09, 2018 2:51 pm

Hello,
I am trying to setup a USB Device with a STM32F042 and TrueStudio (Version: 9.1.0 Build id: 20181011-12) and CubeMX (4.25.0). There are some strange problems that I can not solve.
I have set some ports as outputs.

Code: Select all

GPIOA->BRR = (1<<2)|(1<<1)|(1<<0);
  GPIOA->MODER = (1<<4)|(1<<2)|(1<<0);
  GPIOA->OSPEEDR = (0b11<<4)|(0b11<<2)|(0b11<<0);

Then in the main while loop I toggle one pin.

Code: Select all

volatile uint32_t t = 0;
  while (1)
  {

  /* USER CODE END WHILE */

  /* USER CODE BEGIN 3 */
     GPIOA->BRR = (1<<1);
     for(t = 0; t < 800; t++);
     GPIOA->BSRR = (1<<1);
     for(t = 0; t < 800; t++);
  }

Now I expected the pin to toggle at 50% ratio. Strange thing is, it is not. The code generates a high pulse of 0.218ms and a low pulse of 0.302ms. What is going on here? This behavior is consistent over time and pulselengths do not change. If I invert the pulse the length are swaped too.

I guess if a simple blinky application does not work there is no sense in continuing the work until that is solved. So what may I be doing wrong or not considering?

Other problems:
- the Systicktimer is not firing. I checked the clock is running from HCLK systemclock. I put a pintoggle in the Interrupthandler that does not toggle.

Code: Select all

   static volatile uint8_t t = 0;
   if(t == 1)
   {
      GPIOA->BRR = (1<<0);
      t = 0;
   }else{
      GPIOA->BSRR = (1<<0);
      t = 1;
   }
(I know it is sloppy code but its just for testing).
- when debugging, the debugger gives me a message : File download complete
Time elapsed during download operation: 00:00:00.475
Target is not responding, retrying...
Target is not responding, retrying...
What could that be?
Does anyone have an explanation for the uneven pulses? I have the feeling something is not setup correct. I have attached the ioc file and my main.c.
Am very greatfull for any tips, I am quite stuck on this one.
Thank you very much
Best regards
You do not have the required permissions to view the files attached to this post.

Frolgo
Posts: 4
Joined: Tue Feb 13, 2018 5:56 pm

Re: Basic problem with Code

Postby Frolgo » Sat Dec 15, 2018 5:56 pm

Hello again,
I am still stuck with this strange problem. Does no one have any idea what causes the uneven length of the for-loop?
I generated the project new without USB. The simple code

Code: Select all

  volatile uint32_t t = 0;
  while (1)
  {
     for(t = 0; t < 50000; t++);
     GPIOA->BRR = (1<<1);
     for(t = 0; t < 50000; t++);
     GPIOA->BSRR = (1<<1);

  }
generates pulslengths of high 14.67 mS and a low of 16.77 mS.
How can that be???
Please, any help?

reference
Posts: 9
Joined: Thu Jul 26, 2018 7:52 am

Re: Basic problem with Code

Postby reference » Mon Dec 17, 2018 12:50 pm

View the disassembly listing to see whether there is any code difference on instruction level.

If there is no difference, then, well.. ARM Cortex-Ms are complex pieces of silicon, there are dozens of things that can affect the performance of instruction executions (like prefetch, preread, caches, speculative prefetch, branch prediction, interrupts, flash latency, bus matrix arbitration, etc., etc..).

If you want precision, use the timers, they are made for it, and are very robust.

User avatar
artbody
Posts: 18
Joined: Tue Jan 01, 2019 7:07 pm
Location: Germany
Contact:

Re: Basic problem with Code

Postby artbody » Thu Jan 10, 2019 9:56 am

your while instruction takes also time to process
then the systick irq ...
:idea:
best practice is to use a timer with PWM output
Linux artbody 4.14.83-gentoo #1 SMP Mon Dec 3 23:46:25 CET 2018 x86_64 AMD FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux
:mrgreen:

alister
Posts: 20
Joined: Fri Jan 25, 2019 3:18 am

Re: Basic problem with Code

Postby alister » Fri Jan 25, 2019 10:23 am

artbody wrote:your while instruction takes also time to process
then the systick irq ...
:idea:
best practice is to use a timer with PWM output


Agree with artbody. Polling the system tick in your pintoggle loop is easiest and PWM is most accurate.

Re the systick interrupt not firing: HAL_Init() starts the tick, HAL_GetTick() returns its value, its unit is milliseconds. You might double-check you're testing it right by calling HAL_GetTick() and seeing if its return value changes.


Return to “TrueSTUDIO for STM32 discussions”

Who is online

Users browsing this forum: Bing [Bot] and 2 guests