ST72F324J6 stack problem?

[henrik239955]

Posted on April 19, 2006 at 12:27

ST72F324J6 stack problem?

[henrik239955]

Posted on April 19, 2006 at 07:13

Hi, I have a strange problem that a cant solve. I use Cosmic compiler, STVD7 with EMU3.

For my application I use short stack memory model. It compiles and links fine, but in run-time it crash sometimes.

In main routine I only do this:

room_temp= ((float) int_room_temp/1023)*110 - 30;

In a timer interrupt I use printf to print values to LCD.

The calculation of room_temp is ok as long as not printf is used in

interrupt routine. But after an interrupt with use of printf the value of

room_temp is totaly wrong.

I think it is something wrong with the memory (stack) handling but I cant figure out what happens.

Any ideas? Thank you.

Map file says:

--------

Segments

--------

start 00008000 end 0000bd77 length 15735 segment .text

start 0000bd80 end 0000c272 length 1266 segment .const

start 00000080 end 00000081 length 1 segment .bsct, initialized

start 0000bd7f end 0000bd80 length 1 segment .bsct, from

start 00000081 end 000000e0 length 95 segment .ubsct

start 000000e0 end 000000e0 length 0 segment .share

start 00000200 end 00000200 length 0 segment .data

start 00000200 end 00000200 length 0 segment .bss

start 00000000 end 00005726 length 22310 segment .debug

start 0000ffe0 end 00010000 length 32 segment .const

start 0000bd77 end 0000bd7f length 8 segment .init

-----------

Stack usage

-----------

Debug\adc.o:

_ADC_Filter 7 (7)

_ReadADC 4 (4)

_ReadADC_32Avg 15 (8)

Debug\initregs.o:

_InitRegs 2 (2)

Debug\interrupt_vector.o:

_NonHandledInterrupt > 5 (5)

Debug\lcd16203.o:

_LCD_delay 4 (4)

_LCD_off > 16 (2)

_LCD_on > 16 (2)

_LCD_prog_char 20 (6)

_LCD_setup 22 (2)

_LED_off 2 (2)

_LED_on 2 (2)

_PutOutData 14 (2)

_blink_off 16 (2)

_blink_on 16 (2)

_clrscr 16 (2)

_putchar 17 (3)

_setcur 17 (3)

Debug\lcd_menu_handle.o:

_RTCInterrupt > 198 (18)

_init_menu 180 (2)

Debug\main.o:

_get_PLC_signal > 17 (2)

_get_alarms > 9 (6)

_get_temperatures > 8 (2)

_main > 14 (2)

_regulate > 16 (10)

Debug\spi_master.o:

_Init_SPI_Master 2 (2)

_SPI_Transfer 9 (5)

_delay 4 (4)

_eeprom_read 12 (3)

_eeprom_write 13 (4)

_set_external_outputs > 14 (5)

_set_external_port 12 (3)

Debug\taco_control.o:

_PB0_Interrupt > 5 (5)

_fan_alarm_handle 2 (2)

D:\Program\COSMIC\CXST7_16K\LIB\libfs.st7:

__addexp > 7 (7)

__poly > 11 (11)

__unpack 2 (2)

__norm 59 (29)

L11__cvtup 8 (6)

L31__putbuf 26 (9)

L7__gnum 19 (16)

__print 162 (51)

__dtento 30 (20)

__dtoe 89 (30)

__dtof 91 (32)

__dtog 111 (20)

_printf 178 (16)

__round 7 (7)

D:\Program\COSMIC\CXST7_16K\LIB\libis.st7:

__udiv 6 (6)

__uldiv 6 (6)

__itob 22 (16)

__ltob 24 (18)

_memchr 5 (5)

_strlen 2 (2)

_toupper 2 (2)

Stack size: 215

[luter]

Posted on April 19, 2006 at 07:43

Hi.

First and easiest what i would do in such case is to start debugger, before starting programm fill whole stack with 0xff or 0xa5 or whatever, start program, wait for a some time, stop it and check your stack. so, u can see how much of stack was used. of course, if programm crashes u can not get access to stack. by this way u can more or less evaluate the use of stack. repeat it for several times to get ''the worst'' use of stack.

[henrik239955]

Posted on April 19, 2006 at 08:04

Thanks for reply.

I have done that and the worst case seems to be stack goes from 0x1FF to 0x166. That should be ok?

I have also tried to use static memory models. When using memory long I get error ''segment .share size overflow (64)'' from linker.

[luter]

Posted on April 19, 2006 at 08:34

Well, u can try long stack as well, but i am not sure that it will help. It looks like your bug. Try to disable watchdog.

[luca239955_st]

Posted on April 19, 2006 at 11:43

Bood,

looking at your map file, the compiler calculates a maximun theoretical stack usage of 215 bytes (you measured much less with the method suggested by Luter). Since you have nothing but the stack in page 1 (all your variables are in page0), there should be no stack corruption (assuming, of course, that your ST7 has enough RAM).

The problem probably comes from the fact that you are using printf within an interrupt routine; this is a very bad practice for a number of reasons. Try to move printf into main (set a flag in your interrupt and then test this flag and execute printf if it is true) and the problem should go away.

More generally, this syle of programming is not very suitable for ST7 (and small micros in general):

- using float is big and slow (replace with look up tables when possible)

- using printf is big and slow (replace with own subroutine, or with the ''light'' version of printf if possible)

- using printf (or any other ''big function'') into interrupt routine is definitely to be avoided

Regards,

Luca (Cosmic)

[henrik239955]

Posted on April 19, 2006 at 12:01

Thanks alot!

It seems that the error only occurs when printing float values in the interrupt routine. I will follow your advice, I understand this is not the best for a small micro, but still I wonder why it dont work when all memory handle seems ok.

BR

Bood

[luca239955_st]

Posted on April 19, 2006 at 12:12

Quote:

..still I wonder why it dont work when all memory handle seems ok.

printf uses resources that are not saved by default when entering the interrupt routine; you could force the compiler to save all that stuff (notably, the LREG), but, as using printf under interrups is wrong anyway (no predictable execution time), you'd better remove it altogether.

Regards,

Luca

[henrik239955]

Posted on April 19, 2006 at 12:27

OK, thank you again.

I have removed it and it seems to be running fine now.