DSPIC33EP512GP502 and FFT issue extending FFT_LENGTH

[Ttelmah]

I notice you are not setting up the sample array as it is done in the example.
If you look, that is forced to bankx in the example.

[Marco27293]

I tried both #bankx and #locate, the error persists and device resets...

if I comment instruction:

fft(samples, FFT_LENGTH);

all works fine...

The problem is still in that function

[Ttelmah]

I'm worried about your ADC. Though you say it works in 512 sample mode.
Your ADC is a single ended unit giving an unsigned 16bit value. The FFT
code expects to receive a signed 16bit value, not exceeding +/-0x4000.
The values you are going to get will exceed the maximum allowed. It says
an overflow may result if the values exceed the allowed range.
Just tried turning the amplitude up above that range, and it intermittently
crashes.

[Marco27293]

I tried a dummy test:

[Marco27293]

I did further debug, seems the device resets during:

void memcpy_brev(Complex* dest, Complex* source, unsigned int16 fft_size)

execution in the assembly part

[Marco27293]

Any suggestion ?

I'm struggling on this issue...

[Ttelmah]

memcpy.brev, is exactly where the first problem is. It copies data from one of
the main arrays into the other. It is where half my fixes are. The others are in
the actual fft routine.

I've just twigged something you may be doing wrong. When you modify
fft.h, if you copy this to your project (the normal way to avoid changing the
master copies), you have to change the include line:

#include "fft.h"

Note the inverted commas instead of the brackets. This makes it pull the
file from the local directory before trying the master copy.
I'm wondering if you are actually not loading the fixed file.

I've sent you my modified ex_fft.c in the message board.

[Marco27293]

I renamed your file and put it in Lib folder:

[Ttelmah]

Well, it is behaving as if you are not getting the fix. Try the ex_fft.c
I sent, and see what happens. Will need a serial though.

[Marco27293]

I tried your ex_fft using your library fft.h, I got same resets, the trap error is:

[Ttelmah]

I have further modified fft.h, so that it fixes a couple of other places where
problems may appear.
Have sent my ex_fft.c as well.
This runs 100% for me, so you really need to test it, and once this is
working modify how you declare variables etc., to match how this is done.

OK. Just tried moving the declaration of samples to be global as you have it
this makes it crash again. Use the data layout as done in the example.

That is even odder. the stack is getting damaged, though the samples
array is at exactly the same location,.

[Marco27293]

I made all suggested changes...

I always got:

[Ttelmah]

OK.

Have just sent you another FFT.h.
Touch wood, this will work.

Turns out there are two or three separate issues. The first is the data loads
when the twiddle array is above 0x8000. This I've fixed in a tidier way now
The compiler itself when running C is smart enough to know the two different
ways this has to be handled, so I've put these loads into C code,
not assembler.
Then the separate stack trap, is actually being caused by a compiler
erratum. CCS knows about this again in C code, but the assembler in
fft.h, doesn't know it can trigger this when the address range is moved.
I've added two fixes for this.
It looks possibly as if it works now with the larger array, and the memory
organised as you have it.

[Marco27293]

Thank You Ttelmah !!

Now my code does not crash or reset anymore!

BUT a issue still persists: it seems that FFT output in x_data array is not consistent...

When I read it I got always similar random values...

How can I fix this ? (I tried with 2048 and 512 FFT size, same problem)

[Ttelmah]

I've not changed the maths at all here. If it doesn't work you will have to
look at how this is done. What I have changed, is to alter how the register
loads are done (so I use C to load the registers), and in one case the
register used (W2 instead of W1). This alters the binary value generated by
the code to avoid one of the errata on the chip. There may be an issue that
the CCS code doesn't like things here. Interestingly the compilers
disassembly listing of one line of the code is not right:

code line

mov [W0+W5], [W2+W5] //br[k].im = seq[i].im

disassembly line:

00C34: MOV ,[W2+W5]

Uurgh!....

However MPLAB's disassembly of the same line shows:

00C34 7AB160 mov.w [0x0000+0x000a],[0x0004+0x000a]

Which is correct.

The only other change is to add one NOP, because otherwise the
line:

END:mov [W1], [W1++] //k = k_next

can potentially trigger the erratum for a mov ending in 0 (this was
why you were getting the stack error trap here).

I've 'belt and braces' changed this. Adding the NOP, and changing the
register to W2. The actual description of this erratum suggests it should
not happen in the code as shown, but it is definitely triggering here.

Your problem is almost certainly the sample array location. You need to
force this onto a location that is a multiple of it's size or the bit reversal
maths doesn't work properly. This is described in the notes for the
MicroChip library that the CCS code is based on.