Search code examples
cbuffersignal-processingstm32cmsis

C After filling buffers with data, strange data appear


Buy debugging through SWD on STM32F746NG and putting break point in last line of the code below:

uint16_t data[128];
q15_t ref[64];
q15_t in[64];
.
.
.
for(uint16_t ii=0;ii!=63;ii++)
  {
    ref[ii]=data[ii*2+1];
    in[ii]=data[ii*2+1];
  }


  // 3.LMS processing
    arm_lms_q15(
            &myLMS,
            in,
            ref,
            dummyOut,
            error,
            nsamples
            );

  // 4.Visualizing errors
for(uint16_t bytecount=0;bytecount!=64;bytecount++)

Obviously all elemnt of ref and in must be the same but the last elemnt of these are not the same. the last element of data is 2617 bu is -15581 on ref and 2409 on in. The question is how to remove this data corruption in last element?


Solution

  • Always write loops as simple as possible. for(uint16_t ii=0;ii!=63;ii++) has a weird name ii for no reason. i stands for iterator, what does ii stand for? Also it checks != 63 for no reason.

    An idiomatic for loop is written as for(uint16_t i=0; i<n; i++) and deviating from that form is often "code smell".

    You should have

    #define REF_MAX 64  // replace this with some meaningful name.
    ...
    
    // remove magic numbers:
    uint16_t data[REF_MAX*2];
    q15_t ref [REF_MAX];
    q15_t in  [REF_MAX];
    
    // idiomatic for loop without magic numbers:
    for(uint16_t i=0; i<REF_MAX; i++)
    {
      ref[i] = data[i*2+1];
      in[i]  = data[i*2+1];
    }
    

    Now the highest index access of ref and in will be 63 (the 64th item) and the highest index acess of data will be 63*2 + 1 = 127 (the 128th item).


    Unrelated to your issue, it's not a good idea to allocate large arrays like this on the stack when coding for microcontroller embedded systems. You then get a stack peak use of >256 bytes when this function is called, which is very dangerous. Declare these buffers as static so they end up in .bss instead of the stack.