dsPIC problem

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

Reply to
Syd Rumpo
Loading thread data ...

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 to
Syd Rumpo

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
 Click to see the full signature
Reply to
Tim

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 to
Mark Borgerson

the

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 to
Tim Wescott

s

oop

Hi 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 to
Abhishek

You saved me a lot of time, thanks.

--
Syd
Reply to
Syd Rumpo

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
 Click to see the full signature
Reply to
Tim

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 to
Syd Rumpo

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

Reply to
Mark Borgerson

Mark Borgerson == ARM song broker.

Anagrammatically yours,

--
Syd
Reply to
Syd Rumpo

Nice to find someone else whose inclination to play with languages isn't limited to those understood by computers!

Mark Borgerson

Reply to
Mark Borgerson

Hi Syd,

Yes, I have worked on FFT on dsPIC before. :)

Regards, Abhishek

Reply to
Abhishek

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.