Monday, April 1, 2013

Determination of the current clock frequency when debugging

   Clock frequency is the major parameter which exact knowledge is necessary at calculation of many values.  Beginning from banal excerpts, before generation of UART of transfer. 

   And even if at AVR where it is possible to count clock modes on fingers of one hand and where everything is initially predictable works on a default, it is transparent and it is obvious, many beginners had problems with understanding of in what mode the generator works.

   That the scheme doesn't get into STM32 where the description of RCC system occupies 35 pages of the close text, on the screen, and the heap of libraries, like CMSIS and SPL or wizards, like that that is in CoIDE, generate a starting code, to determine the current clock frequency turns into a difficult task. It also we will solve.

   How to understand, what at us it turned out on SYSCLOCK after all these HSI, HSE, dividers, multiplexers and PLL multipliers?

Master Clock Output
   For STM32 we have an excellent piece, as MCO a conclusion. On which it is possible to kick clock frequency and to have a look an oscillograph or a frequency meter. The truth if you work at the maximum frequency in 72Mhz, on MCO at the best you can give out frequency divided only on two. And it 36Mhz, is far not everyone or the frequency meter in a multimeter will eat the such

   But the method is good, allows to make direct measurement.

Here, in the lower part of the scheme there is a MCO multiplexer. To which it is possible to bring
PLLCLK/2 — as a last resort when precisely we know that is transferred to SYSCLOCK to PLL it is possible to look it
SYSCLOCK — actually clock frequency
HSI — the internal RC generator
HSE — the external quartz generator

   Thus, through MCO it is possible to have a look also at, whether as far as frequency at HSI floats or to have a look HSE was started.  And even external periphery.  Generally, there is a lot of application options. 

   So, it is necessary to configure MSO conclusion correctly only. On STM32F103C8T6 which is used in ARM STM modules for Pinboard it is A08 conclusion

If through SPL, it looks in general simply:

1 RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE);

2 GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8;
3 GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
4 GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
5 GPIO_Init(GPIOA, &GPIO_InitStructure);


Debugging means of Keil
    During the work in Keil if to start under a debugger. for example CoLinkEX (or CoLink is simple that is established on Pinboard II), it is possible to open a window with the RCC settings and there to look as there is a generator initialization. What modes are exposed and so on.

   And that the most pleasant, there it is possible to change in real time anything on the fly. For example, having given out a signal on MCO (previously having configured a conclusion. And it is possible to make it in the same place, in Keil, the GPIO settings window and having placed ticks)

Reference code
   At the worst it is possible to put the elementary reference code in memory. Which gives out obviously known endurance at obviously known frequency. And after a divergence of frequency to judge the real frequency of the controler.

   Here this code, for example, gives out on 1khz on 1 megahertz of the clock. Measuring a frequency meter a signal at the exit of B05 it is possible to learn the size of clock frequency of the controler at the moment:




void Delay( uint32_t Val)
for( ; Val != 0; Val--)

   In an example the B05 port is used since it is convenient to me to throw it on a light-emitting diode on Pinboard. And it is so possible to recustomize it on any other. Having certainly changed initialization.

No comments:

Post a Comment