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 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.
Ruben,
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