LPM needed for receiving all RF packets (huh?). Power or clock related?

John DAmours

Maybe this is too much info below. I'm having Rx problems related to using LPM's. Maybe someone can explain the relationship here, but then maybe I'm posting on the wrong category? (Side note: Wouldn't mind a CC430 category. Honestly, I never know if I should post on the MCP430, Controllers, or RF categories.) Anyway, just frustrated and sharing my problem again on the CC430 implementation. Any suggestions or help here?

Thanks,

_______________

First, I'm fresh out of dongle connectors (from the Chronos kit), so I soldered a dongle onto our board for ease of development. Seems it can only run now with power connected to the dongle and will not run with just power to my board. This leads me to believe the CC430 could be behaving differently to possibly cause other runtime problems... such as this (swag)???

The symptom is that when we loop the main using LPM0 (or LPM3) I don't miss any RF Rx packets, however the system hangs when we try to write out the ports (I2C or MIDI). Now, remove the LPM and just set the GIE and we miss about every other packet and more at times, even at close range.

So, it's probably not the dongle issue (but never know), so thinking that by the time we receive a packet then quickly use the port ISRs to transmit the data out the serial ports, we're having power problems and it hangs. Here's the main loop and port config. Maybe this has to do with the MCLK being off in LPM? So maybe we just need a delay for the clock before writing to the ports. But what's with the missing packets when LPM is not used? We know it happens when we write the ports because we reduced it down to just that operation, and we know it hangs because we set the LED to constantly flash when running.

Thanks for any clues here! By the way, it's now public what I'm doing and we're pretty close to a product kickoff. Check out "Cleanstage LLC" on Facebook if you're curious about SoulPedal(TM), Patent Pending.

Main...

while( true ) {

// __bis_SR_register(LPM0_bits + GIE ); // Doesn't miss data, but locks
__bis_SR_register( GIE ); // Misses Data, doesn't lock up.

if (radio->packetReceived) { // set in the Rx ISR
radio->packetReceived = 0;
if ( ((enum _packet_type)radio->rxBuffer[0] & PKTHDR_MASK) == ACCEL_DATA_TYPE) { // If the packet header is of type Accelerometer data...
radio->linkStatus = STATUS_LINK_ACTIVE;
radio->linkStatusInactiveCount = 0;
processAccelData (0); // this sends the data out the ports
}
}
radio->receiveOff();
radio->receiveOn();
__delay_cycles(5000);

if (++potSampleCount > 5) {
potSampleCount = 0;
pot->readPotValues(); // read the ADC on 3 channels
}
}

Port Setup....

// MIDI Serial port
// UCSCTL6 &= ~XT2OFF; // Enable XT2 (26MHz) Don't need because Radio should be ready
UCSCTL4 |= SELS__XT2CLK; // SMCLK=XT2 (26Mhz Clock)
__delay_cycles(50000); // probably not needed

UCA0CTL1 |= UCSWRST; // **Put state machine in reset**
UCA0CTL1 |= UCSSEL_2; // SMCLK to UCA0

UCSCTL5 |= DIVS_1; // /2
UCA0BR0 = 160; // 64/2
UCA0BR1 = 1; //
UCA0CTL1 &= ~UCSWRST; // Clear SW reset, resume operation

// *** I2C code ***

P1MAP3 = PM_UCB0SDA; // Map UCB0SDA output to P1.4

P1MAP2 = PM_UCB0SCL; // Map UCB0SCL output to P1.2

P1SEL |= BIT2 + BIT3; // Select P1.2 & P1.3 to I2C function

UCB0CTL1 |= UCSWRST; // Enable SW reset
UCB0CTL0 = UCMST + UCMODE_3 + UCSYNC; // I2C Master, synchronous mode
UCB0CTL1 = UCSSEL_2 + UCSWRST; // Use SMCLK, keep SW reset
UCB0BR0 = 12; // fSCL = SMCLK/12 = ~100kHz
UCB0BR1 = 0;
UCB0I2CSA = 0x2C; // Slave is 00b, Total addr is 58 plus Write bit
UCB0CTL1 &= ~UCSWRST; // Clear SW reset, resume operation
UCB0IE |= UCTXIE + UCNACKIE; // Enable TX interrupt, monitor for NACK (No Acknowledge)

// *** End I2C code ***

PMAPPWD = 0;

over 12 years ago

0 TA12012 over 12 years ago

TI__Mastermind 36395 points

John,

It is tough for me to guess what is happening here, have you tried to see if your code makes it all the way around as you expect in the time you expect it to happen. I say this because you say that you miss almost every other message. This indicates to me that your code is doing other stuff.

I always have an LED turn on/off when I enter low power sleep, this helps debug if I am spending enough time in sleep or not by how bright the LED is and/or use an O-scope to track down your timing.

/TA

0 Chad Christensen over 12 years ago

Expert 1670 points

First, have you had any luck with this issue?

Second, I agree with John about flashing some LEDs to see if the main() function is actually looping when it "locks up". Then maybe use the LED to narrow down on which function is causing the lockup?

I also use the CC430, and have had problems in the past with the receiver locking up, especially when called repeatedly very quickly (ie without a LPM timer slowing things down). My problems have almost always been causing by bad PMM settings, which caused error flags to be set, which locked up some of TI's RF functions (ie Strobe or ReadSingleReg). Are you using these functions?

If so, put a marker (like turning on and LED) when entering them, and turn off the LED when exiting and see if it hangs there. There are some while() loops that don't have any protection to prevent them from locking up. The one problem I can remember off-hand is an LVERR being set, preventing the RF module from properly outputting data and hanging either Strobe of ReadSingleReg.

0 John DAmours over 12 years ago in reply to Chad Christensen

Expert 1095 points

Thanks guys. The LED thing is a great idea but haven't tried it yet. Our LED is PWM so if the program stops, so does the LED. So I'll solder a little bugger in there, got some extra port pads in the layout fortunately.

There are some RF features that interest me as they may relate to this problem. First is maybe to use power ramping on the radio (not sure if I'm doing that now but will check... iff this is relevant?). The other is general RF robustness like Whitening, or even using a wider Rx bandwidth so I don't drop so many packets, and then never go to sleep (nightmares right). Keep in mind, it's the same program and tasks, only diff is using LPM (lockups) or not (missing packets). I'll also look for any radio errors. Am I on the right track? Some crazy symptoms, eh.

Bummer about your snop and strobe lockups. My main programmer is afraid of changing anything with the radio. If I ever get this out and funded on Kickstarter, I might need some help with the radio part. Everything else is ready. And the wireless updates to the pedal, well Helgard from S. Africa (this forum) was close but couldn't quite get it to reboot. Man this is so challenging. That's a lost feature that could cost us.

Part of me thinks this is a candidate for open-source for all that's possible with your feet.

SoulPedal

0 John DAmours over 12 years ago in reply to John DAmours

Expert 1095 points

An update to the problem, got it working by adding a 1ms delay after the radio wakes and exits the radio ISR from LPM0. Taking your ideas regarding PMM, we just figured the hardware needed to power-up before we write to the serial ports. I suppose PMM Ramping might help, any code samples out there to set up the ramp tables and stuff?

No clue why this works only when we go to LPM, but it does and we have plenty of time in the loop.

SoulPedal (TM) is now very fast and we're getting all the data now. Very cool stuff! It either writes to MIDI as a controller, then occasionally checks to see if there is an I2C slave out there, and automatically switches to I2C if so. That's were it writes to whatever for other types of control. Right now it's a Wah pedal, but it could be anything (and will be), Patent Pending, but not for long.

Thanks all,

Other wireless

Other wireless technologies forum

LPM needed for receiving all RF packets (huh?). Power or clock related?