Hi Steve,
sorry for my late reply.
You were completely right (of course) - I had to change my code and
adapt the FastClock wiring instead of this initialize_8mhz_clock() function.
Now it is working!
Thanks a lot!
~ Franz
P.S.
You were right, my actual app is not the testbluetooth app. I just
wanted to avoid bothering you with all the customized functions of my
app, so I tried to find the lines which caused the problem and reduced
my problem description to these ones (which can also be copied to the
test app)...
On 17.07.2012 15:23, steve ayer wrote:
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
