Reading MSP430 IO register too quickly?

Question

I'm working on a system where a MSP430 is communicating with another chip over its SPI bus. I'm sending a series of setup commands over the SPI bus and polling on the slave chip's Ready line. I'm using IAR as my IDE and I'm compiling the code without any optimization. The code looks something like this :

for(int i = 0; i < NUM_SETUP_COMMANDS; i++)
{
    SendSetupCommand(); //puts data in SPI Tx buffer, sets Chip select low

    while(P1IN & 0x40) //wait for Chip ready line to go low
    {
        for(int x; x < 1024; x++)
        { 
            //do nothing 
        }
    }

    HandleReadyLine(); //Transmit/Receive data on SPI bus
 }

With and without the empty inner for loop, this code work correctly. All the setup messages are transmitted across the SPI bus correctly. Without the inner for loop, this code block takes around 10 seconds. With the inner for loop, this code block takes about 100 ms.

It seems like reading P1IN as fast as possible, without the inner for loop, causes P1IN to not get updated as fast. Does this make any sense? Is there a clear reason that adding/removing the inner for loop would cause such a drastic timing change?

Answer 1

The loop is probably optimized. One way to make sure it is not optimized is to preform a dummy computation such as

for(int i = 0; i < NUM_SETUP_COMMANDS; i++)
{
    SendSetupCommand(); //puts data in SPI Tx buffer, sets Chip select low

    while(P1IN & 0x40) //wait for Chip ready line to go low
    {
        volatile unsigned int i;
        for(int x; x < 1024; x++)
        { 
            j++; 
        }
    }
    HandleReadyLine(); //Transmit/Receive data on SPI bus
}

The key here is the "volatile" keyword which forbids optimization of variable j by the compiler, thus your loop should not be removed.

Answer 2

It shouldn't make any difference.

A few debug suggestions:

I would suggest reducing the iterations of the inner loop to zero to see if that changes the system timing. Also try swapping the inner loop for a nop and see if that has the same effect. You might also take a look at the generated assembly and see if there is anything obvious between the two compilations. Lastly, (if you can) scope the SPI lines and see if there is any difference in behaviour between the two.