MSP430-FET and SPI trouble.

I'll update this by saying that if this is speed related, which it really shouldn't be, I'm running the MSP with the default oscillator values, so, DCOCLKDIV (1048576 hz) with the following setup using MSP Ware

 #define SPICLK 500000

unsigned char usciB0_SPI_Init(void)
{
 unsigned char returnValue = 0;
 //P3.3,2,1 option select
 GPIO_setAsPeripheralModuleFunctionInputPin(__MSP430_BASEADDRESS_PORT3_R__,GPIO_PORT_P3,GPIO_PIN3 + GPIO_PIN2 + GPIO_PIN1);
 SET_CS_PIN();
 DISABLE_CS_PIN();
	
 returnValue = SPI_masterInit( __MSP430_BASEADDRESS_USCI_B0__, 
 SPI_CLOCKSOURCE_SMCLK, //selects Clock source. Valid values are SPI_CLOCKSOURCE_ACLK SPI_CLOCKSOURCE_SMCLK
 UCS_getSMCLK(__MSP430_BASEADDRESS_UCS__), //clockSourceFrequency is the frequency of the slected clock source
 SPICLK, //desiredSpiClock is the desired clock rate for SPI communication
 SPI_LSB_FIRST, //controls the direction of the receive and transmit shift register. Valid values are SPI_MSB_FIRST SPI_LSB_FIRST [Default Value]
 SPI_PHASE_DATA_CHANGED_ONFIRST_CAPTURED_ON_NEXT, //clockPhase is clock phase select. Valid values are SPI_PHASE_DATA_CHANGED_ONFIRST_CAPTURED_ON_NEXT [Default Value] SPI_PHASE_DATA_CAPTURED_ONFIRST_CHANGED_ON_NEXT
 SPI_CLOCKPOLARITY_INACTIVITY_HIGH); //clockPolarity_InactivityHIGH is clock polarity select. Valid values are SPI_CLOCKPOLARITY_INACTIVITY_HIGH SPI_CLOCKPOLARITY_INACTIVITY_LOW

 if (returnValue != STATUS_FAIL) 
 {
 SPI_enable(__MSP430_BASEADDRESS_USCI_B0__);
 }
	
 return (returnValue);
}

Further info ....

I must be doing something perhaps fundamental here. The bizarre observations below seem to suggest this to me. I set up a call and comparison to the values I was anticipating from the former code and what I observe in the RXBUF. What I've observed is that my 'local' watch on a buffer and a global "Watch"  on the debug variable both indicate 0x00 as the value. However, when I set up a compare to defined values, they pass through as 'true' which means what the 'watch' shows must be incorrect. Or, code execution is incorrect.

Somewhere along the way here my observations don't make sense and leaves me questioning the debugger. Since I've haven't seen any threads on that, it must be something I'm doing however I can't explain what at the moment. 

Has anyone else had observations like this? 

Here is a sample of calling above and the result is that I can trap on the return (true);  however my local watch on buff[0] = 0x00 and buff[1]= 0x00  

(in this instance, A_Revision_O and A_Version_O are constants that represent an unsigned char Address value passed over the SPI)

#define A_Version_I 0x05 // I can see these values in the RXBUF after having stepped through an SPIRead. 

#define A_Revision_I 0x01

/**************************************************************************/

bool CheckVerRev (void)
/**************************************************************************/
{
    unsigned char buff[2]={0,0};
 	
    SPIRead(A_Version_O, &buff[0] , 1);
    SPIRead(A_Revision_O, &buff[1] , 1);
 // Now compare the version this is compile to run with
    //if (buff[0] == A_Version_I && buff[1] == A_Revision_I)    // commented out for testing individual buffer locations
    if (buff[0] == A_Version_I)
    {
    	if (buff[1] == A_Revision_I){
    		return TRUE;
    	}
    	else{
			return FALSE;
    	}
    }
    else
    {
		return FALSE;
    }
}

Hi Kevin,

it might be that you ran into a typical copy and paste error. I can only see

KevinF

while (!(UCB0IFG&UCRXIFG)); // USCI_B0 RX buffer ready?

even when you write the address - I would expect something like this

  UCB0TXBUF =  address ;   
  while(!(UCB0IFG & UCTXIFG));   
     
  while (!(UCB0IFG & UCRXIFG));    
  receiveChar = UCB0RXBUF;   
     
  UCB0TXBUF = 0;   
  while(!(UCB0IFG & UCTXIFG));   
     
  while (!(UCB0IFG & UCRXIFG));  
  receiveChar = UCB0RXBUF; 

Thank Jan, 

It wasn't a copy and paste error and my thoughts behind it were; I'm getting data in at the same time as I'm sending out and therefore waiting for the UCRXBUF to fill up (ie: not a blind send). The UCTXIFG flag would indicate it's ready to TX again, which it should be once I've finished receiving the byte. Now, I supposed that perhaps the more correct way would be to check the TX flag initially, TX,check the TX flag, check the RX flag plus any possible error flags, check for TX Flag before sending the next byte.... 

I don't think that's indicative of what I'm seeing since I actually do see my expected return value sitting in the RXBUF when I set a break point at the end of the call, what I don't seem to be seeing is the actual value sitting in the value you point to above as 'receiveChar' (as a watch) unless I single step. I thought perhaps my issue might be refreshing the watch list but that didn't seem to work either. 

Next, I looked to see if optimizations might be an issue. That doesn't seem to be a problem, I don't have any turned on at the moment. 

There something odd in the behaviour but oddly, when I try to trap for the behaviour in a return value (the latest update I think I mentioned above) - all seems fine. Since it'll be an easy change to make, I'll try your suggestion above and report back. Just seems odd to me to have the debugger break on a break point but indicate incorrect values. 

K

KevinF

he UCTXIFG flag would indicate it's ready to TX again, which it should be once I've finished receiving the byte.

Not exactly. If the SPI baudrate is near the MCLK speed, this assumption works. But for lower baudrates...
The bits are received on different clock edges as sent, depending on phase and polarity. So you may have a byte received wqhile the sending isn't finished (and TXIFG isn't set yet) or you may have finished sendign the last bit (and TXIFG is set) while the receiving of the last bit isn't done yet. There is an interleave of 1/2 SPI clock cycle.

If you single-step, time passes and the transfer completes. (the world doesn't stop turning just because you are single-stepping the CPU code execution). Likely this is why it works in single-stepping

Hi Kevin,

KevinF

The UCTXIFG flag would indicate it's ready to TX again, which it should be once I've finished receiving the byte.

This might not be true. Since SPI may run at a different clock than MCLK. The edges of SPI signals differ from MCLK then and this could cause a problem - as is works then you single step your code line by line and not when running through I would bet at beer it's a timing issue :-)

Hi Jens, 

While I hear what your saying. In my case the read phase is 1/2 cycle later and my clock is SMCLK. Why would the buffer (RXBUF) hold the correct value in both cases, or at least appear to be, and yet only when I single step does my variable in the watch window contain the same information?  I disable other interrupts with ENTER_TASK and re-store through LEAVE_TASK, which was another source of potential error. 

K

PS: I made the change to check for TXFG however it appeared to make no difference in my watch window.  

PPS: One thing I have not done in a while is power everything off which I'll attempt to do now and see if that resolves it. 

Hi Jan, 

Yeah, my gut says this too but so far I must be having a brain fart. Since both you and Jen's pointed my out my logic fault, I may be assuming too much here although my initial changes to your suggestion didn't appear to resolve the issue. I'l going to compare my captures with my data and restart the whole environment to see if I can see what the differences may be. 

Thanks to both you and Jen's for passing along your thoughts. I'll report back if/when I've got this figured but I do appreciate the suggested hints. 

K

So, for now, I'm going to chalk this one up to a strange environment issue. After a complete shutdown (target, FET and CCS - plus comptuer), it seems I am able to observe changes in my variables now in a watch window. The SPI data buffers are now equal to the variables I am using to read too. For some safety, I'm going to add in the above suggestions for alignment of interrupts, reads and writes ... I get what people have been suggesting (thanks Jan and Jen's) . I made some assumptions based on my app and the devices the SPI was talking too but I also get why both of you would suggest the 'correctness' . Thanks to all who took time to either read or write. K

KevinF

After a complete shutdown (target, FET and CCS - plus comptuer), it seems I am able to observe changes in my variables now in a watch window.

It's a timin gissue. When a breakpoint happens, lots of things are happening between debugger, FET and MSP. Depending on how fast things are done, hardware has continued to do their job (only the CPU of the MSP is frozen, not all fo it), registers may have changed (which  would have changed later on an undisturbed system).
By restartign the PC, you have re-initialized the operating system, the driver structure, the USB enumeration, and maybe have changed the response time sbetween debugger and FET by a few µs or even ms. USB is slooow. And not throughput counts, but latency and round-trip times for command and answer.