Part Number:MSP430FR5994
Hi,
I'm trying to use the LEA on an MSP430FR5994 to compute a FIR filter with a reasonably large number of coefficients.
I can't seem to find any documentation on quite what the 'tapLength' member of fir_params is supposed to do, but following the filter_ex1_fir_q15.c example I have:
#define FIR_LENGTH (128)
DSPLIB_DATA(FILTER_COEFFS_AUD,4)
_q15 FILTER_COEFFS_AUD[FIR_LENGTH] = { .. }
DSPLIB_DATA(result,4)
_q15 result[FIR_LENGTH+48];
DSPLIB_DATA(fir_data_buffer,MSP_ALIGN_FOR_Q15(FIR_LENGTH))
_q15 fir_data_buffer[2*FIR_LENGTH];
static int qq = 0;
msp_fir_q15_params fir_params;
fir_params.length = FIR_LENGTH;
fir_params.tapLength = 128;
fir_params.coeffs = FILTER_COEFFS_AUD;
fir_params.enableCircularBuffer = true;
memset( result, qq, 20 * sizeof(_q15));
status = msp_fir_q15( &fir_params, &fir_data_buffer[2*FIR_LENGTH - 128], &result[24] )
if (memcmp( result, qq, 20 * sizeof(_q15)) {
/* Complain */
}
++qq;
Now, status is always OK.
And by and large this code works. But every so often, it will trigger the memcmp() and complain.
When I look closer, the CPU reads 0x80 from one of the guard bytes rather than the expected value (qq).
The debugger reads qq.
So, something weird is happening to memory accesses just after msp_fir_q15().
The question is - what have I done wrong? And if I have done something wrong, why does it only "sometimes" happen?
It looks kind of like the situation described in TRM S10.2.2 , but I don't believe this chip has a DTC.
I've tried disabling interrupts around the whole block, in case it is an interrupt corrupting memory behind my back and this has no effect.
I've tried replacing the LEA call with some token manual code that does the appropriate number of multiplications, and that seems to work fine.
I am running at 16MHz , but running from either the DCO or the HF XTAL does the same thing and I was under the impression that a 16MHz MCLK was legal in this situation?
My MSP430FR5994 advertises itself as a Rev C.
A __delay_cycles(1000) after the msp_fir_q15() call seems to make it happen more quickly (but that could be statistical noise).
Any help gratefully accepted ..
(for the curious, my stack is immedately below result - and obviously this causes apparent stack corruption and, seemingly, a branch through zero if it is affected)