Hi, thanks for the explanation. On Wed, Aug 10, 2011 at 12:25 PM, JMGross <msp...@grossibaer.de> wrote:
> Hi! > > First, I suggest creating an account on the TI E2E community. The MSP > section there is quite active. > e2e.ti.com > > I already have an account, but didn't remember to ask there and just asked in the <msp...@yahoogroups.com>. > About the DCO and the FLL, keep in mind that the DCO (on the 5x series) has > only 256 different > possible output frequencies (older ones have less!). > Chances are, that your desired one is not directly available. Also, on each > MSP they are different. > So the DCO has an option to switch between two frequencies (the programmed > and the next > higher one) based on a 32 step pattern, the modulation. So you get 7936 > more > frequencies, but only as average over 32 clock cycles. This means a clock > jitter of 2..12% between > two individual clock pulses. > > I'd like to better understand this, where does the 7936 come from? Do you know this form the data sheet? > The FLL counts reference and DCO pulses and compares it against its > configuration. > Based on the result, it increments or decrements the modulation stepping > first and > then the DCO setting, one step at a time. > Since it still is unlikely that your exact frequency is available, the > final FLL situation will be > switching up and down between two MODx/DCOx settings, introducing another > jitter. > So the FLL result will match your desired frequency only as an average over > a relatively > long time (for 32768Hz reference, it is ~5ms.) > > The FLL, however, does not adjust the RSELx parameter. So when the FLL > wants to > adjust the DCO further down, but has already reached DCOx=0 (or up and > DCOx=31 is > reached) the fault flag is set. > It means that the DOC is configured to operate in the wrong frequency range > for the > desired output frequency. > > Ok, it's as I thought. > It is important to know that the fault flag simply indicates that DCOx is 0 > or 31. It does > not mean that the FLL won't be able to adjust the DCO up/down from this > after some > more time. > Having the flag clear does not mean that the FLL has settled. It may as > well be that > the DCO is just in transition and will finally hit the border without > settling, and the fault > flag comes up again after some time. > > In your case, a look into the datasheet reveals that the only DCORSEL > settings that > guarantee 3.0MHz to be possible are DCORSEL=3 and 2. > Worst case, you'll get a range from 1.51 to 6.07MHz for DCORSEL=3 and > 0.75..3.17MHz for DCORSEL=2. And considering the DCOx step > ratio of 2% at least and 12% at most, 3MHz will never fall to DCOx=0 or > DCOx=31. > > For 8Mhz, DCORSEL=4 and 5 will both fit and 3 and 6 are possible (but not > safe) > candidates too. > > If everything fails for some reason, you can go for 6MHz and use DCOCLKDIV > instead > of DCOCLK as clock source (with a divider of 2, or maybe even more). > This also reduces the jitter between two (or more) clock pulses. > > Why do you want to keep FLLD=2 and FLLREFDIV=1? > 3MHz/32768Hz is 91.55. So you can only set 91 or 92. > Using FLLREFDIV=1 will count against 16348Hz instead but also > FLLD=2 will divide the counted DCO ticks by four. Leaving you with > a multiplier of 46, and all you can get is 3.014656MHz (4885ppm error). > And the adjustment speed is only half as fast due to the FLLREFDIV. > With FLLD=0 and FLLREFDIV=1, you can use a multiplier of 183, > with the same adjustment speed and 2.998272MHz (-576ppm error) > or use FLLREFDIV=0 for the same 3.014656MHz but twice the > adjustment speed. > > Well I got it wrong when I wrote that, I wanted the default value of D to continue at 2, and the FLLREFDIV value to divide by one, so FLLREFDIV = 0 :) This is because I wanted to change the DCO frequency and keep DCOCLKDIV always half of DCOCLK. The reason for not wanting to change this is because it add much more complexity to my problem. I wanted to be able to swipe as much frequencies as possible just by setting the correct RSELx, and the N multiplier. > In case you wonder how I got the DCORSEL info: for a guaranteed > availability of a frequency at a specific RSEL value, > you'll have to pick the max value in the DCORSELx=y and DCOx=0 > line and multiply it with the max DCO stepping. The desired frequency > be equal or higher. And it must be lower than the min value in the > DCORSELx=y and DCO=31 row beneath. > > I didn't understand this. By max DCO stepping you mean the 32 step pattern? Taking the example of 3 Mhz, I'd go to RSEx =3 pick the max value of 1.51 and multiply by 32 which wold give me 48.32. This would not work, it's higher than my frequency. And it's also higher than the min value for the DCOx=31 line bellow. So, what do you mean with the max DCO stepping? > Everything else may or may not work or might work but set the fault flag. > > These min/max values are over the whole operating voltage and > temperature range. If you can narrow the operatign range down, it will > result in a wider guaranteed frequency span for this DOCRSEL setting. > But better take the worst case. :) > > btw: what do you mean with DVS? Dynamic Voltage Scaling? > Digital Video Services? Digital Voice System? Doppler Velocity Sensor? > Digital Voltage Source? Data Voice Switching? > (I already skipped the obviously nonfitting definitions) :) > > Sorry , it's Dynamic Voltage Scaling. The purpose is to implement some components in TinyOS that provide an interface to change to any desired frequency, and that automatically ajusts the core for it's minimum voltage required for that frequency. João > JMGross > > > ----- Ursprüngliche Nachricht ----- > Von: João Gonçalves > An: msp...@grossibaer.de > Gesendet am: 10 Aug 2011 02:56:09 > Betreff: Msp430 changing the DCO frequency > > Hi, Eric pointed me to you. > > I'm trying to implement DVS in msp430f5438A, and having a hard time > figuring > out how to find the configuration values for a given DCO frequency. > > I've tried to keep FLLD=2 and FLLREFDIV=1 constants and It would be great > if > I could only change the FLLN value to get a given DCO frequency. I'm > ajusting the DCORSEL range according to the datasheet, and the FLL > reference > is the 32kHz crystal. > > Calculating the N value for 8MHz using the expression given in the > datasheet > works great, but for 3 MHz, the fault flag appears, and the behaviour is > nothing of what should be expected. I looked at the DCORSEL ranges that > should handle that frequency but none of them suits to solve the fault > flag.. > Think is because the DCO bits are 31, (all 1) this fires up the flag. > > I really would like to find a configuration, for any frequency desired, but > right now don't have a clue on how to find the values where the DCO remains > stable. The info in the datasheet about DCORSEL ranges isnt helping that > much to this problem. > > I could always find specific values that I would know their configuration > apriori. Which would not be that bad if I could at least set the maximum > and > minimum frequencies for all the existing modes of the Power Management > Module. Anyway, power scales not just with the voltage but is also > proportional to the frequency, so, if I can get more intermediate > frequencies the better. > > Thanks in advance for any help. > > João > > >
------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
