ahh,
a clock problem. it is toolchain related, but indirectly. it is *not*
caused by msp430dcospec.h.
let me explain (though people who actually read this list have seen this):
the current toolchain optimizes quite aggressively. my early testing
showed that a number of things were broken due to inexplicable timing
problems. hmm, odd.
after trying to attack them individually, i gave up and put a gizmo on
the scope and began looking at the clocks, which were not doing what was
expected; in short, the 8mhz initialization was broken. turns out the
optimizer removed the wait loop that was in the code you attached here;
i pulled the (then) working snippet from a t.i. app note ages ago and
never looked back at it.
peter bigot (mspgcc maintainer) set me straight and i fixed the
platforms' fastclock module accordingly awhile back, but, as i announced
last thursday when i committed some fixes that blitzed this
"initialized_8mhz_clock()" function -- which does not belong in a tinyos
application, and yes, laziness kept me from writing the fastclock module
for too long -- from a number of -contrib apps and wired to the clock
module: the use of fastclock is Good Practice.
question for franz: if you were testing with testbluetooth and hello
world, when did the msp430dcospec.h file enter the picture? if you're
going to test with released code and tell people that it's broken, then
you have to come clean and admit that you changed it? neither
msp430dcospec.h nor initialize_8mhz_clock are in this code.
anyway, this file simply tells the tinyos clock calibration code the
target frequency for the clock system (the msp430 has three). this
affects bus speed calibration, and is particularly important for the
uart. you can guess that the bluetooth module uses the uart, so if you
placed msp430dcospec.h in the app directory without changing the right
underlying clock settings, then your module wouldn't work.
WHAT TO DO:
as i announced last week, everyone should remove this initialize_8mhz
function from apps and replace it with fastclock wiring. if you run the
fastclock, you should place a copy of msp430dcospec.h in your app
directory, but the copy you reproduce below has an inaccuracy and should
read
#define TARGET_DCO_KHZ 8000 // the target DCO clock rate in binary kHz
one last critical consideration (esp. here) is bus speed. if you just
wire in the fastclock module, a la justfatlogging, the smclk will run at
4mhz.
but remember that smclk is used by default to clock buses, but the
default tinyos smclk speed is 1mhz, so a 4mhz smclk will break your uart
commz. so, you must either 1) wire in and call the fastclockinit and
fastclock interfaces (boilerplate is a good place to see how to do
this); or 2) hack the bluetooth module to change the uart calibration
parameters (don't do this).
i hope that this clears this up. please post back any other questions.
-steve
On 07/17/2012 07:32 AM, Franz Gravenhorst wrote:
Dear all,
as suggested, I open a new thread for my Bluetooth problems - as it
turned out that it has nothing to do with the toolchain upgrade.
My problems seems to be realted to this file: "Msp430DcoSpec.h"
If it exists in my source directory, then the Blueooth functionality of
my App does not work any more.
If it does not exist, it is working.
Contents of this file is:
#ifndef MS430DCOSPEC_H
#define MS430DCOSPEC_H
#define TARGET_DCO_KHZ 8192 // the target DCO clock rate in binary kHz
#define ACLK_KHZ 32 // the ACLK rate in binary kHz
#endif
You can test it by copying the file to the swtest/Bluetooth app.
(Bluetooth Hello-World app).
I have to questions:
1. What is the effect of this file?
2. For which applications is it reasonable to have this file and how do
I get the Bluetooth working even when the file exists?
Besides this, in my app there is this function:
void initialize_8mhz_clock(){
/*
* set up 8mhz clock to max out
* msp430 throughput
*/
register uint8_t i;
atomic CLR_FLAG(BCSCTL1, XT2OFF);
call Leds.led0On();
do{
CLR_FLAG(IFG1, OFIFG);
for(i = 0; i < 0xff; i++);
}
while(READ_FLAG(IFG1, OFIFG));
call Leds.led0Off();
call Leds.led1On();
TOSH_uwait(50000U);
atomic{
// BCSCTL2 = 0;
// SET_FLAG(BCSCTL2, SELM_2);
}
call Leds.led1Off();
atomic{
// SET_FLAG(BCSCTL2, SELS); // smclk from xt2
// SET_FLAG(BCSCTL2, DIVS_1); // divide it by 2; smclk will run at
8 mhz / 2; spi bus will run at 4mhz / 2
}
}
To get Bluetooth working, I had to comment out these four lines.
But I have no clue what the original sense of these four lines was...
Thanks,
Franz
_______________________________________________
Shimmer-users mailing list
[email protected]
https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
_______________________________________________
Shimmer-users mailing list
[email protected]
https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
