This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Copying variables

Hi,

I have a strange issue.
I am reading values from an accelerometer.
The read values go into an array which is uint8 and 7 bytes long.

The values are read ok and they exist in the array.
When I try to move the individual values to regular uint8 variables - nothing happens. The result is zero, even if the corresponding array index has a value.

I made a test and added a delay between each line.
Now, the values get copied normally from the array to the variables.

Can someone explain why this happens, why the 52832 does not perform these lines normally without delays in between?

This does NOT work:

      Accelerometer_X_L = SPI_rx_data[1];
      Accelerometer_X_H = SPI_rx_data[2];
      Accelerometer_Y_L = SPI_rx_data[3];
      Accelerometer_Y_H = SPI_rx_data[4];
      Accelerometer_Z_L = SPI_rx_data[5];
      Accelerometer_Z_H = SPI_rx_data[6];

All Accelerometer_X/Y/Z variables remain zero when the SPI_rx_data array has values on every byte.

The following DOES work:

      Accelerometer_X_L = SPI_rx_data[1];
      nrf_delay_us(50);
      Accelerometer_X_H = SPI_rx_data[2];
      nrf_delay_us(50);
      Accelerometer_Y_L = SPI_rx_data[3];
      nrf_delay_us(50);
      Accelerometer_Y_H = SPI_rx_data[4];
      nrf_delay_us(50);
      Accelerometer_Z_L = SPI_rx_data[5];
      nrf_delay_us(50);
      Accelerometer_Z_H = SPI_rx_data[6];
      nrf_delay_us(50);

Now the Accelerometer_,,, variables receive the values from each array index as expected.

How is this even possible?
It cannot be that the processor will not do as the code says.

Thank you!

  • I tested how low I can go with the delays and still get values copied ok.

    It seems that 5 us is the limit between working code and non-working code.

    If I set the delay to 2 us, only one or two variable values are copied.
    Delay of 3 us will make all but the first two variables copied ok.
    Delay of 4 us will make only the two last array indexes copied ok.

    When the delay is 5 us, all values are copied ok and the code actually works.

    I have never seen an issue like this, I lose valuable time with this kind of problems that should not even exist. 
    This is not even the first time this happens with the 52832, I am starting to lose trust in the 52832.

    I had earlier a similar issue where, at startup I set a variable to a certain value, nothing else touches this variable until the main loop.
    Then, at the main loop when I check the value, the variable is somehow changed to a different value.
    I was able to go around this only by setting the variable to the value I want, two times right before the main loop.

    I am using the Nordic DK board, Segger v3.40 in Windows 7 x64, GNU ARM Embedded Toolchain version 7-2017-q4-major.

  • I am having a strange behaviour also elsewhere.

    I make an if conditional:

    if (var1 != buffer[1] || var2 != buffer[2] || var3 != buffer[3] || var4 != buffer[4] || var5 != buffer[5] || var6 != buffer[6])
        {
            // do something.
        }

    var1...var6 are uint8, buffer[x] array is uint8 as well.
    Even though the var1...6 variables have the SAME values as the comparison buffer indexes, the code in the if conditional will be run.

    I have tested the above problem and this on three different machines, they work the same way.

    Only if I break this conditional statement into six separate blocks where I compare only one variable to one array index, AND add a 50us delay before that - the code actually works.

    I have entered the Twilight Zone somehow, I cannot even trust a processor run it's code without random issues.
    I tried this also on another Nordic 52832 DK board - same effect.

    What could I have so much wrong that code starts behaving like this?
    I get no errors, code compiles normally and runs otherwise ok.

  • It's the first I have seen of this. Can you modify one of the \nRF5_SDK_15.2.0_9412b96\examples such that I can recreate it here?

Related