the speed of work of stm32f103 is changing in debug/standalone

[fourjustoneday]

Posted on September 28, 2011 at 08:00

some part of my code keeps the speed of motor using encoder. I have an timer interrupt, calc impulses from the motor and find the speed. It works fine in ''download and debug'' (IAR + jetlink). But when I press ''debug without download'', it works faster. I put a counter in the interrupt routine - 23430 calls in ''debug with download'' and 30442 cals in ''debug without download''. When I test code without emulator at all, it works approximately twice slower.

The speed is 72MHz, it's selected in some header.

[Tesla DeLorean]

Posted on September 28, 2011 at 16:17

You appear to have an issue with assuming initial conditions, or failing to initialize things properly.

Use a serial port to get telemetry from the system under test, and add enough code to understand what your code is doing, and the system conditions.

An easy starting point would be to confirm the clocks are running at the expected speeds, both from what the system thinks they are, and what you can measure externally to confirm that. Valid output of serial data suggests it has enough knowledge of the correct clocks to set the baud rate properly.

Something like this would be instructive :

    RCC_ClocksTypeDef RCC_ClockFreq;

    RCC_GetClocksFreq(&RCC_ClockFreq);

    printf(''SYS:%d H:%d, P1:%d, P2:%d, ADC:%d\r\n'',

                                            RCC_ClockFreq.SYSCLK_Frequency,

                                            RCC_ClockFreq.HCLK_Frequency,        // AHB

                                            RCC_ClockFreq.PCLK1_Frequency,    // APB1

                                            RCC_ClockFreq.PCLK2_Frequency,    // APB2

                                            RCC_ClockFreq.ADCCLK_Frequency);

[emalund]

Posted on September 28, 2011 at 16:27

Valid output of serial data suggests it has enough knowledge of the correct clocks to set the baud rate properly.

got caught on that one once

the baudrate was specified as ''desired''*2 with some comment

the uC was actually running at half desired speed

Erik

[Tesla DeLorean]

Posted on September 28, 2011 at 17:05

got caught on that one once the baudrate was specified as ''desired''*2 with some comment the uC was actually running at half desired speed

 

<G> I think we all have stories, or colleagues, with similar issues.  Back in the 70's I remember the old mechanical counter petrol pumps couldn't handle the price rises, and the station owners stuck ''x2'' stickers on the pricing lines. There fixed that for you...

Yeah, that's why the serial output is the first thing I get working, and stick a scope on it to confirm bit timing. The ST firmware library masks a lot of the clocking details, so the serial port should come up with the internal consistency enforced by the library decoding the actual settings, and then you're just dependent on the right external crystal. Programming at the register level people tend to have more rigid expectations of what the system is doing, and is more susceptible to the code janitor flipping the wrong switch on the upstream clocks or PLLs.

What's with the freaking huge fonts on the forum today?

[gerhard_karl]

Posted on November 24, 2014 at 12:00

Dear clive1,

I absolutely need your helb.

Please give me your e-mail address, or contact me: [e-mail]

Thank you..

best regards,

Gerhard

[Tesla DeLorean]

Posted on November 25, 2014 at 00:03

Check the profile