hazardous behaviour with HCS12 MC9S12GC64

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

hazardous behaviour with HCS12 MC9S12GC64

Jump to solution
1,178 Views
davidCH
Contributor I
Hi

i'm getting crazy with debugging a very "simple" application: reading 5 sensors and controling max 4 outputs and a display with icons :
I use a bootloader to load my application

- with a "empty" periodic loop (every 30s), no problem since application do nearly nothing it's difficult to see if there's a trouble
- when i add: acquisition routines , tests routines to see if the inputs are in correct range , simple control routine which activate an output if inputs are in incorrect range
, the application become to do hazardous things: global variables that are not accessed for write (just read) by the current loop are modified.

Inside the loop, i use mostly byte variable, accessing with bit mask for reading and sometimes for writing, but only global varaible from the "applicative" file (not the "kernel")
I attached the applicative file, the main fonction with the loop is the "CESI" fonction, called by the kernel after boot.

I hope somebody can help me

Thanks

David
Labels (1)
Tags (1)
0 Kudos
1 Solution
373 Views
CompilerGuru
NXP Employee
NXP Employee
This
>global variables that are not accessed
>for write (just read) by the current loop
>are modified.

sounds like a stack overwrite problem. How large is your stack (STACKSIZE in the prm file)? Does it help if you increase it.
Did you try to set a watchpoint to the changing globals?

Daniel

View solution in original post

0 Kudos
2 Replies
374 Views
CompilerGuru
NXP Employee
NXP Employee
This
>global variables that are not accessed
>for write (just read) by the current loop
>are modified.

sounds like a stack overwrite problem. How large is your stack (STACKSIZE in the prm file)? Does it help if you increase it.
Did you try to set a watchpoint to the changing globals?

Daniel
0 Kudos
373 Views
Lundin
Senior Contributor IV
Or simply download the whole program to the debugger. Before you start the CPU, set all cells in the stack memory to zero. Let the program run for a while and then check how much of the stack it has munched away at.

And if you expect others here to read through your code, please write it in english.