• State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 21 subscribers
  • Views 3196 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

optimisation settings causing odd behaviour

David Fussell

Hi,

I've recently been experiencing some concern regarding the behaviour of a program, for which the optimiser, when set to favour size [OPTIMIZE (6, SIZE)], occasionally leads to the contents of a global variable getting trashed/overwritten. If the optimisation settings are altered to favour speed, this no longer happens.

It appears not to be an issue with specific XDATA address (where the variable resides), since changing the variables location doesn't prevent this from happening.

The variable in question is only ever modified via a single increment within a timer interrupt function.

Has anyone else experienced anything like this?

IDE: uV2
Compiler: V6.23a
Link/Loc: V4.23

Thanks for any illumination...

David

Parents
  • 0 in reply to Steve Merrick

    If you have functions that are called by the main program and by an interrupt, the linker will generate a warning (unless they were disabled). Typically, the warning will be a multiple call to segment.

    The linker generates a call tree and has to put the isr-main function somewhere in the tree.

    Since the isr-main function is called by the main program, it probably is stored in that tree. If other functions are also called by the function that calls isr-main, the memory of isr-main is overlayed.

    If an ISR subsequently calls the isr-main function, the memory used by isr-main is corrupted.

    This probably appears as variables/arguments in other aparently non-related functions getting corrupted.

    If this is the problem you are having, the following knowledgebase article describes exactly what to do: http://www.keil.com/support/docs/2042.htm.

    Jon

Reply
  • 0 in reply to Steve Merrick

    If you have functions that are called by the main program and by an interrupt, the linker will generate a warning (unless they were disabled). Typically, the warning will be a multiple call to segment.

    The linker generates a call tree and has to put the isr-main function somewhere in the tree.

    Since the isr-main function is called by the main program, it probably is stored in that tree. If other functions are also called by the function that calls isr-main, the memory of isr-main is overlayed.

    If an ISR subsequently calls the isr-main function, the memory used by isr-main is corrupted.

    This probably appears as variables/arguments in other aparently non-related functions getting corrupted.

    If this is the problem you are having, the following knowledgebase article describes exactly what to do: http://www.keil.com/support/docs/2042.htm.

    Jon

Children
  • 0 in reply to Jon Ward

    Excellent! Thanks, Jon, that was what I was after.

    Sadly, in the way of things in the real world, I can't get the original version to fail now, but I'll be patient, and I'll get there.

    As it stands now, ALL functions called from ISRs are marked 'reentrant', and I think this will cure my problem. But not all of them need to be reentrant; some of them only need be excluded from overlaying to cure the problem. [They are only called by one ISR, and never from the main thread.]

    Thanks everyone for your help!

    Steve Merrick
    Software Designer
    Tribal Data Systems