cancel
Showing results for 
Search instead for 
Did you mean: 

SYSCLK on STM32F101

psd2
Associate
Posted on May 20, 2010 at 08:57

SYSCLK on STM32F101

6 REPLIES 6
Nickname12657_O
Associate III
Posted on May 17, 2011 at 13:51

Hi,

Here is the clock going to Flash it is HCLK after the AHB prescaler.

With STM32F101 access line series  ( 36Mhz) the flash wait state should be 1 if HCLK is greater then 24MHz. 

STOne-32.

0690X00000604xzQAA.png

mikeshanahan9
Associate II
Posted on May 17, 2011 at 13:51

Phil,

Whilst I accept the diagram shown by STOne-32, I think that the question still hasn't been resolved, so beware:

Similar diagrams are shown for all devices within the family, both within datasheets and in RM0008.

Within the datasheets, supply current charateristics are often quoted with the condition that the wait state setting is adjusted according to the HCLK frequency.

Yet both RM0008, PM0075 (PM0042, as was) and Hitex's paper all refer to SYSCLK's frequency being used to determine the wait state setting! Come on ST, which one is it?

When I see ambiguity regarding a feature, especially within the manufacturer's documentation, I get nervous!

NB I have a similar thread running (alas, so far unanswered!) regarding USB on an `F105 and what settings of HCLK are allowed. I think that the two issues might be related - it would appear that this whole area of the STM32 family clock tree is not fully understood (even by ST!).

Comments anyone?

Regards,

Mike.
kashif
Associate II
Posted on May 17, 2011 at 13:51

 its HCLK.

for further details and computation help see AN2784

http://www.st.com/stonline/products/literature/anp/14779.pdf

http://www.st.com/stonline/products/literature/anp/14779.pdf

i agree with you mike.shan, St documentation sucks.... there are too much things in their documentation short of description. it takes a lot of time to find the right piece of information. the only document which i like is firmware library manual which is a little better.

mikeshanahan9
Associate II
Posted on May 17, 2011 at 13:51

Hi kashif,

Thanks for your suggestion about AN2784. However, I think that this is only connected with external ROM. If so, because the FSMC is being used, and it is clocked from HCLK, then yes, its wait states will be calculated in terms of HCLK.

However, I don't think that this affects what I said in my previous comments.

In fact, in the meantime, I devised a little experiment to test out the two opposing theories.

I took my target hardware and clocked it 'full tilt' - SYSCLK = 72 MHz and HCLK = SYSCLK.

I then 'walked down' the wait state setting from 2 to 1 to 0. It actually continued to run with only 1 wait state, but failed at 0. The point of failure was in system_stm32f10x.c: SetSysClockTo72(), when RCC_CFGR is altered to switch to the PLL. No surprises there (up to that point, the CPU has been running from HSI = ~8 MHz, so 0 wait states are OK).

I then repeated the experiment, but now with HCLK = SYSCLK /4 = 18 MHz, so if the HCLK theory is true, this should require no wait states. It failed at 0 wait states, in the same place!

Just in case there was 'something special' about my hardware (or software), I repeated all of the above on my STM3210C-EVAL board (using a build of ST's DFU demo, although I think that's irrelevant really - when it fails, it's before jumping to the application's main()).

It failed in exactly the same way! Therefore, I think that this is systematic (all devices are the same), and proves that the internal Flash ROM is clocked from SYSCLK. Perhaps there's a flaw in this theory? Please comment anyone!

NB as shown by my experiments (regardless of which theory is true), I managed to run both specimens at SYSCLK = HCLK = 72 MHz with only 1 wait state. This just goes to show that individual devices may exceed the datasheet ratings, but this shouldn't be used as a excuse to do this in a finished design - for all I know, if I had heated up (or cooled down) even these devices, they might have failed.

I hope this helps.

Regards,

Mike.

kashif
Associate II
Posted on May 17, 2011 at 13:51

well mike i have no idea what exactly you are up to.... but i guess you need to give a little close look to SystemInit() and SetSysClock() and before this you must be cleared about FIGURE 1 in stm32f10x datasheet.

well it sounds good that you have successfully run your device.

i have one question. where exactly you are setting wait states for your memory. can you share your FSMC settings here or your initializing code.

regards

mikeshanahan9
Associate II
Posted on May 17, 2011 at 13:51

Hi kashif,

I think that we have ‘crossed wires’ – I probably didn’t explain myself very well last time. Let’s try again.

I do

not

  have external memory and I am

not

  using the FSMC. Last time, I just commented that if  I was using it, because it is clocked from HCLK, then all its settings would be in terms of HCLK cycles.

The OP (phil) was asking about the STM32F101.

  • My project (target PCB) is using a `105.
  • I also have an STM3210C-EVAL, which has a `107 on it.
  • I also have an STM3210E-EVAL, which has a `103 on it.
  • I do not have any hardware with a `101 on it.

However, I believe that all STM32s are the same in this matter: they actually clock the internal program ROM from SYSCLK (at least when doing instruction fetches over the internal ICode bus; it may be different when reading data (constants) over the internal DCode bus (via the BusMatrix) – the documentation is confusing – see RM0008, section 2.1 – it’s all mentioned, but not fully described!).

As I said before, when two pieces of manufacturer’s documentation contradict each other, be afraid, be very afraid – perhaps even they don’t understand it!

If program ROM is clocked from SYSCLK, then the datasheet clock tree diagrams are wrong (and the ones shown in RM0008!), and the advice that STOne-32 gave to the OP is wrong.

He said (for the `101, that can only go as fast as 36 MHz) “…the flash wait state should be 1 if HCLK is greater then 24MHz.�?, implying that as long as HCLK is less than 24 MHz, then 0 wait states are okay. I think that this is wrong advice, but as I reported last time, on a given device, and at ambient temperature, you might ‘get away with it’.

Since last time, I have repeated my experiment on my STM3210E-EVAL and got the same results. So, I’ve now tried this on three independent STM32 specimens (and each of these were different variants) and it is always the same – at SYCLK = 72 MHz, dropping to 0 wait states always crashes, even if HCLK is set to SYSCLK /4 = 18 MHz, which, according to the datasheet diagrams, should not need any wait states.

In answer to your code request: I have done the experiment using ST’s Device_Firmware_Upgrade (DFU) demo project from their USB Library, but really any of their projects would do – as I stated last time, the crash occurs while the CPU is still in system_stm32f10x.c: SetSysClockTo72(), which is part of the standard code supplied under CMSIS.

As you point out, (under CMSIS) SystemInit() and SetSysClock() are used to configure the clocks.

 

system_stm32f10x.c: SystemInit() is called on reset (from within startup_stm32f10x_**.s). This, in turn, calls system_stm32f10x.c: SetSysClock(), which, because I’ve left SYSCLK_FREQ_72MHz defined, calls SetSysClockTo72().

Essentially, the only alterations that I made to their standard code were in SetSysClockTo72():

  • to comment out their line 943 “FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_2;�?, and change this to either ‘1’ or ‘0’,
  • to comment out their line 947 “RCC->CFGR |= (uint32_t)RCC_CFGR_HPRE_DIV1;�?, and change this to ‘DIV4’.

If the wait state (aka latency) is set to 0, regardless of whether HCLK = 72 or 18 MHz (‘DIV1’ or DIV4’), the CPU always crashes after line 994 “RCC->CFGR |= (uint32_t)RCC_CFGR_SW_PLL;�? is executed. This is the point when the code switches the CPU from HSI (~8 MHz) to HSE (72 MHz).

NB slightly different code is compiled if the CPU is a ‘STM32F10X_CL’, but my alterations and the crash point are the same in either case, as I’ve now proved with my latest test on a `103.

I may still be fooling myself, but anyone can repeat this experiment using just the ST library code. I’d be interested to know their results.

I hope that this helps.

Regards,

Mike.