eZ430-CC2480 and ZASA code

Ed McGettigan

Other Parts Discussed in Thread: MSP430F2274

I can't quite figure out how I did it, but I've messed up something on my eZ430-CC2480 boards and they can no longer communicate with the SensorMonitor interface. The Sensor Monitor GUI indicates that the module is there and the COM port shows up, but the message field indicates that it is not responding.

I was using the IAR 4.11 Kickstart edition and the ZASA source code with no changes. I compiled the ZASA code in IAR and it downloaded and verified to the boards without any warnings. The boards seem to operate normally, pressing the button on the PC board produces a red LED indicating a coordinator, pressing the button on battery board produces a green LED indicating a router, but nothing seems to happen. In addition to the GUI indicating an issue, the coordinator LED doesn't blink indicating a data transfer.

I think that I might have erased something in the MSP430 that isn't rebuilt by the ZASA code. Initially I had selected the "write to locked Flash" and "write to locked BSL Flash" code in the IAR debugger options as I thought that I needed to do this. If I did kill some necessary code or register values is there anyway to get these back.

I also thought that it might have been something to do with using 4.11 instead 4.10, so I uninstalled 4.11 Kickstart and installed the 30-day full eval of 4.10a with the same results. I did notice that the "wirte to locked BSL flash" option is not available in the 4.10 version.

Any suggestions on where I should start to debug this?

over 17 years ago

Ed McGettigan over 17 years ago

Prodigy 40 points

I'm answering my own question, but it looks like I erased all of the calibration data that was stored in the MSP430 so the DCO is no longer operating are the correct frequency and thus the UART datarate.

It looks like the devices are basically useless at this point, unless there is a way to recover and/or reload the calibration data. Any ideas?

Morten Braathen over 17 years ago in reply to Ed McGettigan

TI__Mastermind 19575 points

Hi Ed,

There is a backdoor. We have saved the calibration data, so if you have the serial number of the boards in your kit we can email you this data to be rewritten into MSP430 flash information page starting at the specific address or

if the DCO cal data has been erased the UART frequency will be too inaccurate for a stable communication as you have experienced. MSP430 has one of the following solutions:

Connect a frequency counter to the F2274 pin 1.4/SMCLK/TCK and play in IAR debugger with the DCO register values until you are closest to 1MHz. Then take the software Elprotronic FET-Pro 430 (click here) and a MSP-FET430UIF. With this tool you load the Information Memory into a file on your PC. Then you write the try-and-error cal values into the file (e.g. with notepad) and load the file back into the MSP430 Information Flash.
The BSL uses a different method. MSP430 at first receives a calibration byte, which is the value 0x80. This 0x80 is on the serial signal line a low-pulse with the width of 8 bits (including start and stop bits). BSL uses Timer_A to find out how many DCO clock pulses are within these 8 serial bits. This way it can calibrate the UART and adopt it to the baud rate of the received sync byte 0x80.

You can see the temperature and VCC dependence of the DCO in the MSP430F22xx data sheet (slas504b) on page 35. The uncalibrated frequencies are on page 32.

LPWRocks

Ed McGettigan over 17 years ago in reply to Morten Braathen

Prodigy 40 points

Excellent! Where can I email my SN# to? On the possible chance that you might be able to access the data. All three of the boards have the same serial number eZ430-RF2480T Rev:1.31 SN#60000026

I will also try out the frequency counter measurement as I would to get a little more "hands on" with the boards.

Morten Braathen over 17 years ago in reply to Ed McGettigan

TI__Mastermind 19575 points

Feel free to send me a privat message and I can obtain your contact info to email you the necessary information

LPRF_Rocks

Morten Braathen over 17 years ago in reply to Ed McGettigan

TI__Mastermind 19575 points

Hi Ed

Thank you, I will get you the calibration data.

LPRF_Rocks

Ed McGettigan over 17 years ago in reply to Morten Braathen

Prodigy 40 points

Using the earlier suggestion to measure the frequency of the SMCLK directly I was able to find good settings for the DCO attributes and to get back up and running.

The MSP430F2274 on the RF2480T board only has a landing pad on the P1.4 pin and trying to get a scope on the pin was a bit too difficult for me. Looking over the MSP430 datasheet I was able to determine that the SMCLK could also be accessed using P2.1 which is tied to the R71 resistor that is part of the light sensor circuit. R71 is tiny little 0402, but getting a scope probe on it wasn't a problem.

I changed the hal_board.c ioInit code for P2SEL to 0x03 to select the SMCLK for P2.1 output and I didn't need to change P2DIR or P2OUT as the were already set correctly. I then added a couple of lines in the halMcuInit code where it detects that the calibration data is missing and sets the HAL_EVT_NO_8MHz flag to explictly set BCSCTL1 and DCOCTL values and not set the flag. This would allow me to change these values and as needed to determine the correct settings. There is probably a better way to do this, but the IAR software is new to me and this worked well enough for me.

I set up some memory watch points in the IAR debugger was able to determine that the default settings for the DCO attributes DCOCTL and BCSCTL1 were set to 0x60 and 0xB7 on power up and I was getting 780 KHz with my first board. This was well off the 8MHz value that the ZASA software thought that it should be to drive the 9600 baud UART.

The DCOCTL register has 3 bits of interest that are the DCOx values and reside in [7:5] the lower order bits [4:0] are for the modulation to improve EMI results which aren't important to the primary frequency.

The BCSCTL register has 4 bits of interest that are the RSELx values and reside in [3:0] the higher order bits[7:5] control other aspects of the design and don't need to be changed for this experiment.

After playing around with a variety of settings (in hindsight it would have been much easier to take a look at the DCO Frequency table in the datasheet) I was able to find one setting that would work well for 1MHz across all three boards DCOCTL = 0xC0 and BCSCTL1 = 0xB6. This gave values of 0.999, 0.993 and 1.025 MHz for the 3 boards.

Finding the settings for 8MHz took a while longer (again it would have been easier if I had read the datasheet) as changing the DCOx and RSELx values had wider jumps. I finally settled on two settings 0x60 and 0xBD for two of the boards and 0xE0 and 0xBC for the last board. This gave values of 8.13, 8.01 and 7.89 MHz for the 3 boards.

Using the 8MHz settings I was able to get the serial link working again with the Sensor Monitor code. I still need to get the values programmed into the TLV data space, but for now the soft code values are working.