Hi all there,
well I´m having some troubles mixing the SLAA357 FIR filter design tool and the MSP430F5338. I´ve used this code generation tool with some others chips like MSP430F2553 and the result was just awsome, but for some unkown reason, when I used the same filter code with the F5338 it seems to work for some seconds and then the processor halts, or something like this. When I try to pause it with the ccs debugger trough the launchpad (which i´m using to program it) it seems to be at the 0x0004 adress, where there´s nothing.
Here I put the code for my two code files, the one written in C, and the second the s.43 assembler file generated by the tool (with the necessary modifications to be used with the CCS):
************************************* C code*************************************************
#include "msp430f5338.h"extern FIR_filter(int);
int input_delay0;int input_delay1;int input_delay2;int input_delay3;int input_delay4;int input_delay5;int input_delay6;int input_delay7;
int muestra, output = 0;
//*************************************************************
void main(void) {
WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer
P3SEL |= BIT4; //SMCLK en la pata 4P4SEL = 0; //IOP5SEL = 0; //IOP6SEL |= BIT0; //IO todas menos la 0 para conversion ADP7SEL = 0; //IOP9SEL = 0; //IO
P4DS |= BIT0; //FULL DRIVEP5DS |= BIT3; //FULL DRIVEP9DS |= BIT1 + BIT5 + BIT6 + BIT7; //Bluetooth power y leds FULL DRIVE
P3DIR |= BIT4;P4DIR |= BIT0; //PNP_rojoP5DIR |= BIT3; //PNP_InfraP6DIR &= ~BIT0 + ~BIT1; //canales de conversion como entradasP6DIR |= BIT6 + BIT7; //segundo canal de conversion como entradaP7DIR |= BIT7; //NPN_InfraP9DIR |= BIT1 + BIT5 + BIT6 + BIT7; // Bluetooth power y leds como salidas
// Parpadeo verdeP9OUT |= BIT5;_delay_cycles(500000);P9OUT &= ~BIT5;_delay_cycles(500000);
// Parpadeo azulP9OUT |= BIT6;_delay_cycles(500000);P9OUT &= ~BIT6;_delay_cycles(500000);
// Parpadeo rojoP9OUT |= BIT7;_delay_cycles(500000);P9OUT &= ~BIT7;_delay_cycles(500000);
while(1){FIR_filter(input_delay0);_delay_cycles(1000);}
}
****************************************************************************************************************************
************************************************ assembler code**********************************************************
.cdecls C,LIST, "msp430f5338.h"
.def FIR_filter.text.ref input_delay1.ref input_delay2.ref input_delay3.ref input_delay4.ref input_delay5.ref input_delay6.ref input_delay7.ref input_delay0,output
FIR_filter:
;Stage 0
mov.w &input_delay0,R12mov.w R12,R13rra.w R13rra.w R13rra.w R13rra.w R13rra.w R13add.w R12,R13rra.w R13rra.w R13sub.w R12,R13rra.w R13rra.w R13rra.w R13sub.w R12,R13rra.w R13rra.w R13rra.w R13add.w R12,R13rra.w R13rra.w R13mov.w R13,R14add.w R14,&output
;Stage 1
mov.w &input_delay1,R12mov.w R12,R13inv.w R13add.w #1,R13rra.w R13rra.w R13rra.w R13rra.w R13sub.w R12,R13rra.w R13rra.w R13rra.w R13add.w R12,R13rra.w R13rra.w R13rra.w R13rra.w R13rra.w R13mov.w R13,R14add.w R14,&output
;Stage 2
mov.w &input_delay2,R12mov.w R12,R13rra.w R13rra.w R13add.w R12,R13rra.w R13rra.w R13rra.w R13sub.w R12,R13rra.w R13rra.w R13rra.w R13add.w R12,R13rra.w R13rra.w R13rra.w R13rra.w R13rra.w R13mov.w R13,R14add.w R14,&output
;Stage 3
mov.w &input_delay3,R12mov.w R12,R13inv.w R13add.w #1,R13rra.w R13rra.w R13sub.w R12,R13rra.w R13rra.w R13rra.w R13rra.w R13add.w R12,R13rra.w R13rra.w R13rra.w R13rra.w R13rra.w R13mov.w R13,R14add.w R14,&output
;Stage 4
mov.w &input_delay4,R12mov.w R12,R13inv.w R13add.w #1,R13rra.w R13rra.w R13rra.w R13rra.w R13sub.w R12,R13rra.w R13rra.w R13rra.w R13rra.w R13add.w R12,R13rra.w R13rra.w R13rra.w R13rra.w R13rra.w R13mov.w R13,R14add.w R14,&output
;Stage 5
mov.w &input_delay5,R12mov.w R12,R13inv.w R13add.w #1,R13rra.w R13rra.w R13sub.w R12,R13rra.w R13rra.w R13rra.w R13rra.w R13add.w R12,R13rra.w R13rra.w R13rra.w R13rra.w R13rra.w R13mov.w R13,R14add.w R14,&output
;Stage 6
mov.w &input_delay6,R12mov.w R12,R13rra.w R13rra.w R13add.w R12,R13rra.w R13rra.w R13rra.w R13sub.w R12,R13rra.w R13rra.w R13rra.w R13add.w R12,R13rra.w R13rra.w R13rra.w R13rra.w R13rra.w R13mov.w R13,R14add.w R14,&output
;Stage 7
mov.w &input_delay7,R12mov.w R12,R13inv.w R13add.w #1,R13rra.w R13rra.w R13rra.w R13rra.w R13sub.w R12,R13rra.w R13rra.w R13rra.w R13add.w R12,R13rra.w R13rra.w R13rra.w R13rra.w R13rra.w R13mov.w R13,R14add.w R14,&outputmov.w &input_delay6,&input_delay7mov.w &input_delay5,&input_delay6mov.w &input_delay4,&input_delay5mov.w &input_delay3,&input_delay4mov.w &input_delay2,&input_delay3mov.w &input_delay1,&input_delay2mov.w &input_delay0,&input_delay1ret.end
**************************************************************************************************************
Thanks very much to all that make this kind of network works so well!!
The "bug" you observed is probably caused by the "debugger".
Both the timing and the strength of the SBW signals generated by the LaunchPad are very marginal.
Thanks for the reply old_cow, but i observe the problem with and without the debugger. I mean, i,ve tried to toggle a led each time the main loop is entered, and also the processor stops or halts...in some seconds.
I´ve also debugged with the launchpad and the MSP430G2553, with this FIR routine, and never got any bug like this.
Any other idea?
Thanks
Alvaro Guzman when I used the same filter code with the F5338 it seems to work for some seconds and then the processor halts, or something like this.
_____________________________________Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.
Jens-Michael Gross, I surrender to your wisdom....I´ve been looking around in the CCS but i couldn´t find where is the large code mode enabled/disabled option. Anyway i changed "ret" for "reta" as your explanation seemed to look quite possible. And....here I have now the problem solved and the proccessor working perfectly!
Thanks a lot, you have saved me from the failure!
For me it´s always a pleasure to look around the forum and see your answers. Jens-Michael master of the MSP ;) Thanks again!
Alvaro GuzmanI´ve been looking around in the CCS but i couldn´t find where is the large code mode enabled/disabled option.
There's also a large data model option, which uses 20/32 bit data pointers and stores 32 bit instead of 16 bit registers to stack.
For C code, the linker takes care of not mixing different models when linking object ifles and libraries. The compiler puts this info into the object files. But I don't know how to add this info to assembly files so you're getting a linker error when trying to mix incompatible builds.
BTW: ISRs still use RETI. On interrupt, teh MSP430X core always saves a 20 bit return address (the upper 4 bits put into the status register storage) and restores it properly on RETI. This is transparent. However, ISRs need to be placed in <64k area, because the interrupt vectors are still 16 bit.
Alvaro GuzmanFor me it´s always a pleasure to look around the forum and see your answers.
Alvaro GuzmanJens-Michael master of the MSP