Home/Support/Support Forum/how do I slow down the RCM6600W?
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

how do I slow down the RCM6600W?

0 votes
Upgrading from the rcm5600W to the rcm6600W I'm having problems with the memory mapped IO. worked fine with the 5600 but now with the 6600 running at 3x the frequency I want to figure out how to slow it down.

How can I set the osc/8 divider in the register?
how do I change the GCSR? when I try to insert into my code the debugger crashes.
asked Jan 25, 2016 in Rabbit Software by mattfosteraz New to the Community (6 points)

Please log in or register to answer this question.

2 Answers

+1 vote
 
Best answer
I think you will need to look at the functions in PLL.LIb if you want to tweak the R6000 clock speed.

The PLL_init and PLL_SwitchCPU only provide very limited ranges so you will probably need to look at the lower level functions.

Regards,
Peter
answered Jan 25, 2016 by petermcs Veteran of the Digi Community (1,130 points)
selected Jan 25, 2016 by mattfosteraz
0 votes
It might be a better idea to update the configuration for your memory mapped I/O to add wait states as necessary for the faster clock speed of the RCM6600W. This will allow for better overall performance, and limit the reduced speed to just I/O access.
answered Feb 29, 2016 by TomCollins Veteran of the Digi Community (2,051 points)
I'm at 15 wait states.  When I was originally on the rabbit3000  I only needed to be at 7 wait states.  When I upgraded to the rabbit5000 I had to bump it up to 15 wait states.  Now with the rabbit6000 the edge rate is too high and so I have lots of ringing up to 15 wait states.  can I go to 30 wait states?
If ringing is the problem you might want to look at adding some low value series resistors to the effected lines. This will help to slow down the rise and fall times. Adjusting the wait states won't improve ringing as the signal transitions will happen as quickly irrespective of the wait states.
I've seen a situation on a different platform where a plug in Arcnet network card would experience strange behaviour which turned out to be problems with ground bounce when the data lines went from 0 to 0xFF and the switching rate on the new rev of chip was much faster than the previous one...
...