View previous topic :: View next topic |
Author |
Message |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Wed Jul 26, 2023 7:40 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Marco27293
Joined: 09 May 2020 Posts: 126
|
|
Posted: Wed Jul 26, 2023 7:47 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Wed Jul 26, 2023 7:55 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Marco27293
Joined: 09 May 2020 Posts: 126
|
|
Posted: Wed Jul 26, 2023 8:11 am |
|
|
I tried a dummy test:
Code: |
#INT_EXT1
void ADC_manager()
{
samples[array_pointer].im = 0;
samples[array_pointer++].re = 100;
bytes_counter+=2;
if(array_pointer >= 2048) {array_pointer=0;disable_interrupts(INT_EXT1);}
}
|
This way I exclude ADC responsibility, BUT error persists in fft function... |
|
![](templates/subSilver/images/spacer.gif) |
Marco27293
Joined: 09 May 2020 Posts: 126
|
|
Posted: Wed Jul 26, 2023 9:40 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Marco27293
Joined: 09 May 2020 Posts: 126
|
|
Posted: Thu Jul 27, 2023 1:09 am |
|
|
Any suggestion ?
I'm struggling on this issue... |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Thu Jul 27, 2023 1:33 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Marco27293
Joined: 09 May 2020 Posts: 126
|
|
Posted: Thu Jul 27, 2023 1:36 am |
|
|
I renamed your file and put it in Lib folder:
Code: |
#include <Lib/fft_3Bee.h>
|
I think it is correct... |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Thu Jul 27, 2023 2:00 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Marco27293
Joined: 09 May 2020 Posts: 126
|
|
Posted: Thu Jul 27, 2023 2:03 am |
|
|
I tried your ex_fft using your library fft.h, I got same resets, the trap error is:
Code: |
mov [W0], [W1] //br[k].re = seq[i].re
02BF0: MOV [W0],[W1]
////
ADDRESS FAULT PC:2BF0 W0:5152 W1:E002 W2:5174 W3:C044 W4:7FF W5:2 W6:714A W7:FFFD W8:3FFC W9:4000 W10:3CFB W11:3CFB W12:B7A4 W13:1000 W14:2000 W15:7E0C DSRPAG:1 DSWPAG:1 TBLPAG:0 INTCON2:8000 INTCON3:0 INTCON4:0 CORCON:12A
STACK (6) 4428 0 0 2C22 0 2EEC
|
If I put 512 FFT_LENGTH all works fine again! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Thu Jul 27, 2023 2:08 am |
|
|
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,. |
|
![](templates/subSilver/images/spacer.gif) |
Marco27293
Joined: 09 May 2020 Posts: 126
|
|
Posted: Thu Jul 27, 2023 2:15 am |
|
|
I made all suggested changes...
I always got:
Code: |
mov [W0], [W1] //br[k].re = seq[i].re
02BF0: MOV [W0],[W1]
////
ADDRESS FAULT PC:2BF0 W0:5152 W1:E002 W2:5174 W3:C044 W4:7FF W5:2 W6:714A W7:FFFD W8:3FFC W9:4000 W10:3CFB W11:3CFB W12:B7A4 W13:1000 W14:2000 W15:7E0C DSRPAG:1 DSWPAG:1 TBLPAG:0 INTCON2:8000 INTCON3:0 INTCON4:0 CORCON:12A
STACK (6) 4428 0 0 2C22 0 2EEC
|
|
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Fri Jul 28, 2023 12:49 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Marco27293
Joined: 09 May 2020 Posts: 126
|
|
Posted: Mon Jul 31, 2023 3:53 am |
|
|
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) |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Mon Jul 31, 2023 5:23 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
|