logs archiveBotHelp.net / Freenode / #43oh / 2015 / August / 5 / 1
hello, how can i measure the vcc in a launchpad msp430 5529, without requiring extra divider resistors?
or external reference
there is a an adc channel that provides that
@ cambazz
http://www.ti.com/lit/ug/slau208o/slau208o.pdf page 757 ...
1011b = (AVCC  AVSS) / 2
haha, tindie just acquired by SupplyFrame, the parent company of Hackaday
no surprise there, could tell Emile was rocking the "startup train" when he moved to silicon valley to join AOL's incubator
startup train aka "get paid big bucks to sell your pet company"
wonder how much he is getting
what is the proper way to feed a launchpad, msp430f5529 with battery. I got 3.3V and 5.0V converters for lipo
does it need power up with 5V or 3.3?
oh well i loaded blink in the msp430f5529 launchpad, then removed all the jumpers from the board but just the rx connection, it still blinks? why? there is it taking the power from?
So I'm looking in msp430.h.
And the value for CALBC1_xMHZ are all two bytes long, but BCSCTL1 is a single-byte register, wut?
for which chip
msp430.h is a generic that includes msp430<whatever>.h
Actually now that I think of it, that might be part of my problem
hang on
yeah so this is with the redhat gcc stuff aye
for some odd reason, some of the G2xxx series have their CALBC* crap pointing to the address in Infomem_A flash where the calibration constant is located
and some have the reference to the value
double-checked, this is the g2553.h provided with the Redhat package
wait in that case it's not so
#define CALDCO_16MHZ_ 0x10F8 /* DCOCTL Calibration Data for 16MHz */
const_sfrb(CALDCO_16MHZ, CALDCO_16MHZ_);
const_sfrb says that CALDCO_16MHZ is cast to a const volatile uint8_t * at the address specified by CALDCO_16MHZ_ (note the extra underscore)
so when you do BCSCTL1 = CALBC1_16MHZ; for example...
you're really doing-
Working on having a more complete understanding of how the periphs and clocks work by writing a psuedo-driverlib for different periphs
BCSCTL1 = *(const volatile uint8_t * 0x10F8);
meaning, BCSCTL1 should be assigned the value-of the byte pointer located at address = 0x10F8
Ah, I see.
the const_sfrb, sfrb, sfrw, etc. macros used in the msp430<blah>.h files should be looked up while you're at it.
So then the precalibrated DCO clock data is stored on chip?
yep, in infomem_a, technically in the TLV database
however the location of the data never seems to change so TI is comfortable putting an absolute address in the header
but, look further below
"Calibration Data in Info Mem"
TAG_DCO_30 is the TLV header "tag" indicating "this is the DCO30 Calibration Data"
if you were to take the start address of segment Info_A and start "walking" it as a TLV database, eventually you'd find the TLV segment with TAG_DCO_30 as its identifier and you'd know then that you're inside the DCO30 calibration segment
(as it turns out, that would point you around 0x10F8 or so)
once inside there, you can figure out what you want by looking at the address offset from the beginning of that TLV database segment, using the symbolic offsets CAL_DCO_16MHZ, CAL_BC1_16MHZ, etc defined below (notice how they start at 0x0000 and just go up to 0x0007 ... they're "offsets" from the "beginning of the DCO30 TLV database segment")
that would be the "most correct" and "most resilient" way to obtain the calibration values
but, using CALDCO_16MHZ, CALBC1_16MHZ is a shortcut that TI evidently believes works well enough
so long as they never alter the methodologies they use for writing and producing that calibration info on future revisions of the chip... or maybe you find a one-off sample of a chip that had to be recalibrated and it didn't store things at the exact address
but did follow the TLV tag convention
So if I'm understanding correctly
It's possible the data is stored on chip because it's _permanently_ on-chip so that every individual chip needs individual calibration?
manufacturing tolerances and slight defects, etc.
likewise, Info_A is protected by the debugger and in code from being erased, but NEVER override those protections and erase it yourself unless you've saved a copy for the particular chip in question or intend to run your own calibration lab to produce new values :-)
Thanks for the help. Back to writing my Timer_A driverlib
a more legit reason to get cozy with the TLV stuff is to pull the ADC calibration values, which almost nobody ever uses these days (except for temperature compensation and only if they realize the chip has calibration constants to make the math easier...)
but that compensates for variance in the slope function of the ADC relative to its reference voltage/etc.
again all based on variances introduced by manufacturing tolerances/etc
So, on clock sources.
It looks like there are four actual sources for clock: DCO, and others I don't quite get--VLO, LFXT1, and XT2
XT2 refers to an external oscillator attached to the pins XIN and XOUT I assume, or am I incorrect?
Okay nevermind, I found a forum post on e2e
you don't know about the 430's clocks?
Not nearly as much as I should
k back to msp430 101 for you :)
Here's what I think I get
basically there's a "high speed" clocking zone and a "low speed" clocking zone you typically see
DCO is a built-in, not terribly accurate high-speed clock that can drive SMCLK
SMCLK is usually an option for timers, uart peripherals/etc
the low speed "ACLK" is driven by either VLOCLK (internal to the chip, terribly inaccurate) or LFXT1... which is an external watch crystal
very accurate
also very low power
XT2 is an option on some MSP430's, and it's usually intended to be a high speed crystal or resonator oscillator
it's often an alternative option for MCLK (main CPU), SMCLK, some peripherals might be able to source XT2 directly regardless of SMCLK, etc.
on the F5529 launchpad, the XT2 is populated with a 4MHz resonator and on that chip it's used to drive the USB peripheral's PLL for the USB reference clock
but if you're not using USB, there's no reason you can't use it for SMCLK, etc.
assuming you need a clocking source that's super accurate (compared to the DCO).
(especially accurate across a wide range of temperature extremes)
MCLK is directly driven by DCO, correct? or is that something that I can select as well?
It can be selected.
Usually there is no XT2 or whatever so the DCO is the only high speed clocking source so it directly drives MCLK, SMCLK
But you can always switch those to other sources, and you can also institute clock dividers on each one... MCLK could be running at DCO/2 while SMCLK is running at full speed (DCO/1)
You can also run MCLK off the ACLK source
That would be slow as balls
But very, very low power :-)
Alright, so when I look up example code for certain peripherals, I see that they reference MCLK, SMCLK, and ACLK basically as if they default to DCO, divided DCO, and LFXT1
that's the usual default
SMCLK has no clock divider by default though but sometimes one is added depending on what the peripherals using it need
e.g. peripherals often have their own "clock dividers" they can institute on top of SMCLK, but for example Timer_A only has so much depth to that
« prev 1 2 next »