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?

CodePudding user response：

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.