 |
 |
| View previous topic :: View next topic |
| Author |
Message |
NickPablo
Joined: 11 Jun 2015
Posts: 2
|
| dsPIC resetting when using float |
 Posted: Thu Jun 11, 2015 8:49 pm |
 |
|
Hi guys,
I'm having problem with dsPIC30F4013. It resets every time I use the float format type using printf ( or even sprintf). Looking at the code below, if I comment the block:
| Code: |
/***** This block resets the dsPIC toor****/
lcd_gotoxy(0,2);
printf(lcd_putc,"ADC0: %f",Vd1);
delay_ms(100);
lcd_gotoxy(8,2);
printf(lcd_putc,"ADC1: %f",Vd2);
|
then it works just fine, it displays the integer just nice in this block:
| Code: |
lcd_gotoxy(0,2);
printf(lcd_putc,"%Lu ",ADC0);
lcd_gotoxy(8,2);
printf(lcd_putc,"%Lu ",ADC1);
|
But the dsPIC resets when I comment out the block with float format.
My Version: 4.xxx (Been using this for more than a year)
See the full code below. Any helping hand is appreciated.
Thanks!
| Code: |
// Header code here //
#include <30F4013.h>
#DEVICE ADC=10
#FUSES NOWDT //No Watch Dog Timer
#FUSES XT_PLL8 //XT Crystal Oscillator mode with 8X PLL
#FUSES NOCKSFSM //Clock Switching is disabled, fail Safe clock monitor is disabled
#FUSES BORV27 //Brownout reset at 2.7V
#FUSES NOBROWNOUT //No brownout reset
#FUSES PROTECT //Code protected from reads
#FUSES MCLR
#use delay(clock=80000000)
#use standard_IO(B)
// Main code here
#include <Recon40.h>
//#include <math.h>
//#include <float.h>
/****** LCD Defines ********/
#define LCD_BL pin_f5
#define LCD_ENABLE_PIN PIN_d1 ////
#define LCD_RS_PIN PIN_b12 ////
#define LCD_RW_PIN PIN_f1 ////
#define LCD_DATA4 PIN_b11 ////
#define LCD_DATA5 PIN_d0 ////
#define LCD_DATA6 PIN_f0 ////
#define LCD_DATA7 PIN_f4
#include <LCD.C>
#use rs232(UART1,baud=115200,parity=N,bits=8)
/******* Global Vars ****************/
unsigned int16 heartbeat;
unsigned int16 ADC0,ADC1; //,Vd1,Vd2;
float Vd1,Vd2;
char adcCH;
char disp[12];
#int_TIMER1
void TIMER1_isr(void)
{
heartBeat++;
//if (heartBeat == 0xFFFF)
// output_toggle(LCD_BL);
// output_toggle(LCD_ENABLE_PIN);
//output_toggle(LCD_RS_PIN);
//output_toggle(LCD_RW_PIN);
//output_toggle(LCD_DATA4);
//output_toggle(LCD_DATA5);
// output_toggle(LCD_DATA6);
// output_toggle(LCD_DATA7);
adcCH++;
if (adcCH>=2) adcCH = 0;
set_adc_channel(adcCH);
if (adcCH==0) ADC0 = read_adc();
else ADC1 = read_adc();
Delay_us(2);
}
void main()
{
setup_spi(SPI_MASTER | SPI_L_TO_H | SPI_CLK_DIV_4);
setup_timer2(TMR_INTERNAL |TMR_DIV_BY_64 ,0);
setup_timer4(TMR_DISABLED |TMR_DIV_BY_1 ,0);
setup_timer3(TMR_DISABLED |TMR_DIV_BY_1 ,0);
setup_timer5(TMR_DISABLED |TMR_DIV_BY_1 ,0);
setup_timer1(TMR_INTERNAL|TMR_DIV_BY_8);
enable_interrupts(INT_TIMER1);
enable_interrupts(INTR_GLOBAL);
setup_adc_ports(sAN0 | sAN1, VSS_VDD);
setup_adc(ADC_CLOCK_DIV_8 | ADC_TAD_MUL_4);
// setup_adc_ports(sAN0 | sAN1, VSS_VDD);
// setup_adc(ADC_CLOCK_DIV_4 | ADC_TAD_MUL_2);
lcd_init();
// TODO: USER CODE!!
output_high(LCD_BL);
printf(lcd_putc,"\f dsPIC LCD\n");
printf(lcd_putc,"Float & Int");
delay_ms(3000);
printf(lcd_putc,"\f..Ready\n");
delay_ms(1000);
while(1) {
Vd1=(float)(ADC0*5)/1024;
Vd2= (float)(ADC1*5)/1024;
lcd_gotoxy(0,2);
printf(lcd_putc,"%Lu ",ADC0);
lcd_gotoxy(8,2);
printf(lcd_putc,"%Lu ",ADC1);
// this block resets the dsPiC
/* delay_ms(500);
sprintf(disp,"%f",Vd1);
lcd_gotoxy(0,2);
printf(lcd_putc,disp);
delay_ms(100);
sprintf(disp,"%f",Vd2);
lcd_gotoxy(8,2);
printf(lcd_putc,disp); */
/* delay_ms(500);
sprintf(disp,"%f",Vd1);
/***** This block resets the dsPIC toor****/
delay_ms(1000);
printf(lcd_putc,"\f");
lcd_gotoxy(0,2);
printf(lcd_putc,"V0:%f",Vd1);
delay_ms(100);
lcd_gotoxy(9,2);
printf(lcd_putc,"V1:%f",Vd2);
delay_ms(1000);
}
}
} |
|
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Thu Jun 11, 2015 10:50 pm |
|
|
Probably too little stack.
Don't quite know what has happened. Historically, on early CCS versions you always had to increase the stack, even for the most basic things. Then CCS expanded the default, and 90% of code didn't need it expanded. Then recently, there has been a whole 'spate' of needing to expand the stack even for simple things. I suspect that something recent in the compiler has increased the stack usage, so it has become a problem again.
#build (stack=256)
or even 384, or 512, depending on how big your code is.
Generally, if you add an error interrupt for stack overflow, you would be able to know what is happening. |
|
|
NickPablo
Joined: 11 Jun 2015
Posts: 2
|
|
| Posted: Fri Jun 12, 2015 6:41 am |
|
|
| Quote: |
PostPosted: Fri Jun 12, 2015 12:50 pm Post subject:
Probably too little stack. |
Priceless Ttelmah! You hit the nail right in the head. Just shifting from the 8-bit MCUs, these kind of requirements for the 16-bit ones (ie priming the stack size) didn't dawn on me. One big noticeable difference right upon compilation is the RAM gauge. From the original 9% -I guess that's the default 256 bytes given the fact that 30F4013 sports a 2K RAM - to 21%
| Code: | | #BUILD(STACK = 384) |
If one will not be too careful though, it will spell a memory drought in the rest of the software  . It resolved the issue for now however. The advice regarding the stack overflow interrupt is also brilliant.
Thanks indeed !  |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1346
|
|
| Posted: Fri Jun 12, 2015 11:12 am |
|
|
| It should not cause you too much of a drought. Aside from the print statements and floating point operations, most of the normal coding you do will take very little stack. CCS doesn't allocate parameters or local variables on the stack like other C compilers often do (I think microchips does). It instead attempts to assign each variable a particular spot in memory and works hard to ensure multiple variables that don't conflict can share that memory spot. It's a very RAM efficient way to do it. If you take a look a the SYM file, you can see this in action. Most of the stack usage in this scenario comes from function a calling function b calling function c etc, where you have to save a copy of some of the registers for each function call or if your function does some heavy lifting with strings or floating point. Most of its other stack accesses are quick push/pop combos which only pulse the stack size for a few instructions. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Fri Jun 12, 2015 11:25 am |
|
|
| Agreed. However it'd be interesting to take the time and compare stack usage on the current compilers, from those a few versions ago. It seems to have shot up recently. There have now been three threads in the last couple of weeks with printf's that would have worked on the older compilers, causing stack overflow. CCS may well have switched to using more stack, and less 'scratch' variables. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
