Hello I have an odd problem with some dsPIC code. I'm using MPLAB and a dsPIC Starter Kit 1. I have some C code calling an assembler routine - in fact the Microchip FFT stuff. It doesn't work and causes the processor to hang or reset or go off on a jaunt - not sure which. I have three LEDs which the C code turns on if/when the assembler routine returns. If I put the appropriate pops and a return instruction into the assembler part way along I can make it return and the LEDs come on. Part way in is the instruction... clr a,[w8]+=2,w6,[w10]+=2,w4 ...a return placed before this instruction returns, but placed after it doesn't and the LEDs go off - one is already on before the asm is called. I've looked at the op-code - 0xC32046 looks ok to me. The right registers are being pushed and popped in line with the correct calling procedure. if I comment out the offending line, the code gets a little further but then the ... mpy w4*w6,a,[w8]-=2,w7,[w10]-=2,w5 ... instruction kills it. Likewise, if I comment this out it goes a bit further. It's a dpPIC33FJ256GP506 and I'm using the debugger. I know I'm doing something stupid - maybe I need to set something somewhere. I've not used this before, so it's all a bit unfamiliar. Any help gratefully received. Thanks -- Syd
dsPIC problem
Started by ●October 9, 2011
Reply by ●October 9, 20112011-10-09
Me again. I've trimmed the code to a minimum...
push.d w8 ; {w8,w9} to TOS
push.d w10 ; {w10,w11} to TOS
push.d w12 ; {w12,w13} to TOS
push CORCON
fractsetup w7
push PSVPAG
clr a,[w8]+=2,w6,[w10]+=2,w4
pop PSVPAG
pop CORCON
pop.d w12 ; {w12,w13} from TOS
pop.d w10 ; {w10,w11} from TOS
pop.d w8 ; {w8,w9} from TOS
return
This doesn't return unless I comment out the clr instruction.
Thanks
--
Syd
Reply by ●October 9, 20112011-10-09
On Sun, 09 Oct 2011 14:10:07 +0100, Syd Rumpo wrote:> Me again. I've trimmed the code to a minimum... > > push.d w8 ; {w8,w9} to TOS > push.d w10 ; {w10,w11} to TOS > push.d w12 ; {w12,w13} to TOS > push CORCON > fractsetup w7 > push PSVPAG > > clr a,[w8]+=2,w6,[w10]+=2,w4 > > pop PSVPAG > pop CORCON > pop.d w12 ; {w12,w13} from TOS > pop.d w10 ; {w10,w11} from TOS > pop.d w8 ; {w8,w9} from TOS > return > > This doesn't return unless I comment out the clr instruction.I'm not sure of the details of the dsPIC assembly language, but it appears that there's memory that's pointed to by w10, w8 or both that's getting modified -- are you sure that those pointers are valid? If you're stomping on the stack or on some control register someplace then bad things can happen. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by ●October 9, 20112011-10-09
In article <v92dndhi5cEGUAzTnZ2dnUVZ_i2dnZ2d@web-ster.com>, tim@seemywebsite.please says...> > On Sun, 09 Oct 2011 14:10:07 +0100, Syd Rumpo wrote: > > > Me again. I've trimmed the code to a minimum... > > > > push.d w8 ; {w8,w9} to TOS > > push.d w10 ; {w10,w11} to TOS > > push.d w12 ; {w12,w13} to TOS > > push CORCON > > fractsetup w7 > > push PSVPAG > > > > clr a,[w8]+=2,w6,[w10]+=2,w4 > > > > pop PSVPAG > > pop CORCON > > pop.d w12 ; {w12,w13} from TOS > > pop.d w10 ; {w10,w11} from TOS > > pop.d w8 ; {w8,w9} from TOS > > return > > > > This doesn't return unless I comment out the clr instruction. > > I'm not sure of the details of the dsPIC assembly language, but it > appears that there's memory that's pointed to by w10, w8 or both that's > getting modified -- are you sure that those pointers are valid? > > If you're stomping on the stack or on some control register someplace > then bad things can happen.What I get from a cursory read of the DSPIC instruction manual is that the instruction does this: clears ACCA moves the word pointed to by W8 to W6, postincrementing W8 moves the word pointed to by W10 to W4, post incrementing W10 From this, it doesn't appear that the indirect memory references change memory---only the contents of ACCA, W4 and W6, W8 and W10 are changed. (w8 and w10 by postincrementing, and w4 and w6 by indirect loads from memory). Does the DSPIC have a memory controller that will cause a fault if w8 and w10 point to invalid memory? I know that on the ARM chips, such faults often cause a jump to an infinite loop in the default library code , and it is the programmer's responsibility to insert code that does something sensible. If you have a debugger, a clue to such a loop is that halting the code shows you in the infinite loop. Of course, I've NEVER had that happen! ;-) Mark Borgerson
Reply by ●October 10, 20112011-10-10
On Sun, 09 Oct 2011 12:51:55 -0700, Mark Borgerson wrote:> In article <v92dndhi5cEGUAzTnZ2dnUVZ_i2dnZ2d@web-ster.com>, > tim@seemywebsite.please says... >> >> On Sun, 09 Oct 2011 14:10:07 +0100, Syd Rumpo wrote: >> >> > Me again. I've trimmed the code to a minimum... >> > >> > push.d w8 ; {w8,w9} to TOS >> > push.d w10 ; {w10,w11} to TOS >> > push.d w12 ; {w12,w13} to TOS >> > push CORCON >> > fractsetup w7 >> > push PSVPAG >> > >> > clr a,[w8]+=2,w6,[w10]+=2,w4 >> > >> > pop PSVPAG >> > pop CORCON >> > pop.d w12 ; {w12,w13} from TOS >> > pop.d w10 ; {w10,w11} from TOS >> > pop.d w8 ; {w8,w9} from TOS >> > return >> > >> > This doesn't return unless I comment out the clr instruction. >> >> I'm not sure of the details of the dsPIC assembly language, but it >> appears that there's memory that's pointed to by w10, w8 or both that's >> getting modified -- are you sure that those pointers are valid? >> >> If you're stomping on the stack or on some control register someplace >> then bad things can happen. > > What I get from a cursory read of the DSPIC instruction manual is that > the instruction does this: > > clears ACCA > moves the word pointed to by W8 to W6, postincrementing W8 movesthe> word pointed to by W10 to W4, post incrementing W10 > > > From this, it doesn't appear that the indirect memory references change > memory---only the contents of ACCA, W4 and W6, W8 and W10 are changed. > (w8 and w10 by postincrementing, and w4 and w6 by indirect loads from > memory). > > Does the DSPIC have a memory controller that will cause a fault if w8 > and w10 point to invalid memory? I know that on the ARM chips, such > faults often cause a jump to an infinite loop in the default library > code , and it is the programmer's responsibility to insert code that > does something sensible. If you have a debugger, a clue to such a loop > is that halting the code shows you in the infinite loop. Of course, > I've NEVER had that happen! ;-)Unless the fact that it's stomping on w4 and w6 is killing things. The OP needs to check to see if those two registers are assumed to be preserved across calls or not. But if it's in their library code I'd be looking to see if the memory locations are valid first, for sure. -- www.wescottdesign.com
Reply by ●October 10, 20112011-10-10
On Oct 10, 9:35=A0am, Tim Wescott <t...@seemywebsite.com> wrote:> On Sun, 09 Oct 2011 12:51:55 -0700, Mark Borgerson wrote: > > In article <v92dndhi5cEGUAzTnZ2dnUVZ_i2dn...@web-ster.com>, > > t...@seemywebsite.please says... > > >> On Sun, 09 Oct 2011 14:10:07 +0100, Syd Rumpo wrote: > > >> > Me again. =A0I've trimmed the code to a minimum... > > >> > =A0 push.d =A0w8 =A0 =A0 =A0 =A0 =A0 =A0 =A0; {w8,w9} to TOS > >> > =A0 push.d =A0w10 =A0 =A0 =A0 =A0 =A0 =A0 ; {w10,w11} to TOS > >> > =A0 push.d =A0w12 =A0 =A0 =A0 =A0 =A0 =A0 ; {w12,w13} to TOS > >> > =A0 push =A0 =A0CORCON > >> > =A0 fractsetup =A0 =A0 =A0w7 > >> > =A0 push =A0 =A0PSVPAG > > >> > =A0 =A0 =A0 =A0 =A0 clr =A0 =A0 a,[w8]+=3D2,w6,[w10]+=3D2,w4 > > >> > =A0 pop =A0 =A0PSVPAG > >> > =A0 pop =A0 =A0CORCON > >> > =A0 pop.d =A0 w12 =A0 =A0 =A0 =A0 =A0 =A0 ; {w12,w13} from TOS > >> > =A0 pop.d =A0 w10 =A0 =A0 =A0 =A0 =A0 =A0 ; {w10,w11} from TOS > >> > =A0 pop.d =A0 w8 =A0 =A0 =A0 =A0 =A0 =A0 =A0; {w8,w9} from TOS > >> > =A0 return > > >> > This doesn't return unless I comment out the clr instruction. > > >> I'm not sure of the details of the dsPIC assembly language, but it > >> appears that there's memory that's pointed to by w10, w8 or both that'=s> >> getting modified -- are you sure that those pointers are valid? > > >> If you're stomping on the stack or on some control register someplace > >> then bad things can happen. > > > What I get from a cursory read of the DSPIC instruction manual is that > > the instruction =A0does this: > > > =A0 =A0clears ACCA > > =A0 =A0moves the word pointed to by W8 to W6, postincrementing W8 moves > the > > =A0 =A0word pointed to by W10 to =A0W4, post incrementing W10 > > > From this, it doesn't appear that the indirect memory references change > > memory---only the contents of ACCA, W4 and W6, W8 and W10 are changed. > > (w8 and w10 by postincrementing, and w4 and w6 by indirect loads from > > memory). > > > Does the DSPIC have a memory controller that will cause a fault if w8 > > and w10 point to invalid memory? =A0I know that on the ARM chips, such > > faults often cause a jump to an infinite loop in the default library > > code , and it is the programmer's responsibility to insert code that > > does something sensible. =A0 If you have a debugger, a clue to such a l=oop> > is that halting the code shows you in the infinite loop. =A0Of course, > > I've NEVER had that happen! =A0;-) > > Unless the fact that it's stomping on w4 and w6 is killing things. =A0The > OP needs to check to see if those two registers are assumed to be > preserved across calls or not. > > But if it's in their library code I'd be looking to see if the memory > locations are valid first, for sure. > > --www.wescottdesign.comHi Syd, To know what exactly is causing the problem you can add "traps.c" file(located in compiler folder) to your project while compiling it. When you'll compile and run , it will halt in the infinite loop corresponding to exception which has occurred. Most probably, it is the problem of memory placement. (So your code will probably halt in Address Error Trap if you have included "traps.c" in your project) Be sure that you have placed the data in correct memory segments. There are two data memory segments in dsPIC (X and Y memory). The FFT source and destination vectors have to be placed in Y memory and Twiddle factors have to be placed in X memory or the program memory. Also , make sure that your are passing all the required arguments in proper order to the library function. Refer to DSP library documentation provided with the compiler. If this doesn't solve the problem, you can monitor CPU registers to zero down the exact cause of error. Also, If you are using any assembler optimizations then probably you can check by turning off the optimizations to know if assembler is creating any problem.
Reply by ●October 10, 20112011-10-10
On 10/10/2011 11:56, Abhishek wrote:> On Oct 10, 9:35 am, Tim Wescott<t...@seemywebsite.com> wrote: >> On Sun, 09 Oct 2011 12:51:55 -0700, Mark Borgerson wrote: >>> In article<v92dndhi5cEGUAzTnZ2dnUVZ_i2dn...@web-ster.com>, >>> t...@seemywebsite.please says...<snipped> Thanks all for your help. Abhishek nailed it, I needed to use y memory for the source and destination. At first, that caused an error, but Google then found me a reference which explained it had to be far memory. You saved me a lot of time, thanks. -- Syd
Reply by ●October 10, 20112011-10-10
On Mon, 10 Oct 2011 13:12:19 +0100, Syd Rumpo wrote:> On 10/10/2011 11:56, Abhishek wrote: >> On Oct 10, 9:35 am, Tim Wescott<t...@seemywebsite.com> wrote: >>> On Sun, 09 Oct 2011 12:51:55 -0700, Mark Borgerson wrote: >>>> In article<v92dndhi5cEGUAzTnZ2dnUVZ_i2dn...@web-ster.com>, >>>> t...@seemywebsite.please says... > > <snipped> > > Thanks all for your help. Abhishek nailed it, I needed to use y memory > for the source and destination. At first, that caused an error, but > Google then found me a reference which explained it had to be far > memory. > > You saved me a lot of time, thanks.In retrospect, another approach that you could have taken would be to start with whatever Microchip demo app there is for this program, and gradually change things to match your app, until something breaks or the light goes on. I didn't think of it until too late here, but it's a technique that often works when you're badly stuck, to find the one @#$% thing that the apps engineers forgot to tell you. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by ●October 10, 20112011-10-10
On 10/10/2011 19:23, Tim wrote:> On Mon, 10 Oct 2011 13:12:19 +0100, Syd Rumpo wrote: > >> On 10/10/2011 11:56, Abhishek wrote: >>> On Oct 10, 9:35 am, Tim Wescott<t...@seemywebsite.com> wrote: >>>> On Sun, 09 Oct 2011 12:51:55 -0700, Mark Borgerson wrote: >>>>> In article<v92dndhi5cEGUAzTnZ2dnUVZ_i2dn...@web-ster.com>, >>>>> t...@seemywebsite.please says... >> >> <snipped> >> >> Thanks all for your help. Abhishek nailed it, I needed to use y memory >> for the source and destination. At first, that caused an error, but >> Google then found me a reference which explained it had to be far >> memory. >> >> You saved me a lot of time, thanks. > > In retrospect, another approach that you could have taken would be to > start with whatever Microchip demo app there is for this program, and > gradually change things to match your app, until something breaks or the > light goes on. > > I didn't think of it until too late here, but it's a technique that often > works when you're badly stuck, to find the one @#$% thing that the apps > engineers forgot to tell you.Trouble is, there isn't a demo for this application as far as I can tell, but yes, it's always a good approach to start with something that works. This is my first dsPIC project and there's quite a lot of documentation to wade through. My guess is that Abhishek has used the FFT stuff before. But now I can make LEDs light, there'll be no stopping me. Tomorrow, the world. Or maybe a beeper, let's not get too ambitious. Thanks -- Syd
Reply by ●October 10, 20112011-10-10
In article <j6vj9q$n5v$1@dont-email.me>, usenet@neonica.co.uk says...> > On 10/10/2011 19:23, Tim wrote: > > On Mon, 10 Oct 2011 13:12:19 +0100, Syd Rumpo wrote: > > > >> On 10/10/2011 11:56, Abhishek wrote: > >>> On Oct 10, 9:35 am, Tim Wescott<t...@seemywebsite.com> wrote: > >>>> On Sun, 09 Oct 2011 12:51:55 -0700, Mark Borgerson wrote: > >>>>> In article<v92dndhi5cEGUAzTnZ2dnUVZ_i2dn...@web-ster.com>, > >>>>> t...@seemywebsite.please says... > >> > >> <snipped> > >> > >> Thanks all for your help. Abhishek nailed it, I needed to use y memory > >> for the source and destination. At first, that caused an error, but > >> Google then found me a reference which explained it had to be far > >> memory. > >> > >> You saved me a lot of time, thanks. > > > > In retrospect, another approach that you could have taken would be to > > start with whatever Microchip demo app there is for this program, and > > gradually change things to match your app, until something breaks or the > > light goes on. > > > > I didn't think of it until too late here, but it's a technique that often > > works when you're badly stuck, to find the one @#$% thing that the apps > > engineers forgot to tell you. > > Trouble is, there isn't a demo for this application as far as I can > tell, but yes, it's always a good approach to start with something that > works. This is my first dsPIC project and there's quite a lot of > documentation to wade through. My guess is that Abhishek has used the > FFT stuff before. > > But now I can make LEDs light, there'll be no stopping me. Tomorrow, the > world. Or maybe a beeper, let's not get too ambitious.In the spirit of fellowship, I offer the following micro ode: Three buses for DMA Masters under the die, Seven for peripheral devices running on their own, Nine breakpoints for code doomed to die, One for the CPU running from cache alone In the land of micros where the datasheets lie One CPU to rule them all, One CPU to find them, One CPU to bring them all and in the package bind them. In the land of micros where the datasheets lie. Mark Borgerson
