We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello,
I've been working with a board MCBSTR9 and I thought I had correctly configured the PLL so that I was working at the maximum frequency.
However, revising the configuration in the startup file provided by Keil, I've seen that the following values were set in the PLL configuration:
P = 3; N = 192; M = 25
, which, according to all the manuals I've seen, produces an fPLL frequency of 48MHz (the oscillator's frequency is 25MHz).
So, I changed the value of P to 2, to theorically get a frequency of 96MHz. However, the board don't even start running.
I changed the parameters to several values which should produce a 96MHz output in the PLL, but nothing worked. Restoring a frequency of 48MHz works fine.
I can't see where's my mistake. What am I doing wrong?
I don't work with your processor, so it is a bit hard to help.
But have you made sure that you don't have any peripherials that gets too high clock frequency when you step up the PLL frequency?
Have you checked any errata, so you don't have a development board with an early version of the chip?
Ruben,
You should define revision of your chip then check errata. ST change correct PLL settings minimum one time. You can find examples for PLL initialization on the ST site.
The board is practically brand-new, so I don't think it may be obsolete.
Either way, I have made an "experiment". I set up one of the timers using the "Pulse width modulation mode". Using this mode, one can use a comparation register so that an interruption is generated any time the value of the counter matches the value in the register. Additionally, the counter is reset after each match. The SRT9 Reference Manual gives the following formula to calculate a period of time:
CompValue = (t * freq/(DIV + 1)) - 5
freq is the clock frequency, which I am trying to figure out. DIV is a frequency divider to adjust the timer speed. Its size is 1 byte. CompValue is the value of the comparation register (2 bytes) t is the time interval
Assuming the frequency is 48MHz, I chose a value of 0xFF for DIV (which means we divide the frequency by 256), and 46880 for CompValue. This should generate an interruption every quarter of second. With a counter in the service routine, I print the number of seconds on the screen every four times the routine is called.
The problem is that "my clock" goes too fast, which means that the frequency is not 48MHz, but higher.
I still don't know where's the mistake...
Thanks. I'll check that.
You both were right.
There is a known issue with the flash memory which can't work at 96MHz while programming.
Thank you very much for your help.
I keep on having doubts on this.
I fixed my timer "experiment" and now it seems to run correctly (displays the seconds timely). The only difference is that, for testing, I changed the parameters assuming an internal clock of already 96MHz.
The Flash Memory Interface Clock shouldn't have any effects on the Peripheral Clock. However, if I set the FMI Divider, the timer slows down. That makes me think that, maybe, when I configure the PLL for an output of 96MHz, but I set the FMI divider, the board is actually running again at 48MHz, thus I don't get any improvement.
I'm using the startup file provided by Keil, can this be happening because of an error in the file?
I'm sorry for being so insistent, but I don't understand this strange behaviour.
Thank you very much for you input.
As usual, I don't have access to any of my code while looking at this forum.
At the moment, all I can say is that I've been using the Keil STR9 board and been running it at the full 96MHz. From memory it was a revision 'g' and our own in-house developed prototype has a revision 'h' - The stepping level may be wrong here, but I do remember that our proto has the latest and the Keil board has the previous one.
All timers, clocks etc work at the expected clock speeds. Currently, I'm going for 'flat out' on as much as possible.
When I was first exploring the CPU, I used the debugger, single stepped into the code and examined the clock registers - Modifying them to see what effect it had on all the clock outputs. Coming from an 8051 background and being new to the ARM I found the number of registers and combinations daunting.
If you're still asking on Monday, I should be able to access my code and may be able to help you.
Good luck.
there is figure named Clock Control in the manual STR91XF that clearly presents clock distribution. Also Data Sheet STR91XF has other figure named Clock Control. According that TIM0CLK - TIM3CLK clocked directly from master clock through 16 bit prescaler. And FMI clock setting should not affect timers.
That's the thing. It *shouldn't* affect, but it clearly does, because the "clock timer" I've made as a test actually slows down when I set up the FMI Divider. I've already gone through all the stuff about this topic in the Reference Manual, but what I'm seeing contradicts what the manual says.
To summarize:
- I couldn't set the PLL frequency to 96MHz, because the board froze when I loaded the program to the ROM.
- Then I saw that programming the ROM at 96MHz doesn't work properly, so I slowed down the ROM clock by setting up the FMI Divider.
- This shouldn't affect the timers' speed, but the fact is -it does. So that makes me think that setting up the FMI divider efectivelly reduces in half the overall speed. I say this because the timer works well (counts seconds correctly), when I set the parameters for a 96MHz clock frequency, BUT THE PLL IS SET FOR 48MHz (at least, according to the manual).
- The same thing happens if I set the PLL for 96MHz and, at the same time, set the FMI divider.
- If I set the PLL for 48MHz and the FMI divider, the timer runs at half the speed it should.
I mean, it does makes sense (if the ROM goes slower, it "feeds" the microprocessor with instructions at a lower rate). What I don't understand is why such a thing is not mentioned in the manual. Or, if I'm wrong and it doesn't make sense at all, I can't see what's happening.
I'm sure that it's probably my fault and that I'm making a stupid mistake. I hope I'm not bothering you guys so much. You're always very helpful.
Cheers, Rubén