Some times program misbehaves not sure if using variables co

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 5.
To post in this forum you must have a registered copy of Flowcode 5 or higher.

Moderator: Benj

Post Reply
markus747
Posts: 33
Joined: Mon Jul 23, 2012 7:17 pm
Location: Petaluma california USA
Has thanked: 26 times
Been thanked: 2 times
Contact:

Some times program misbehaves not sure if using variables co

Post by markus747 »

Recently wrote need program to control reel using 16f887 (upgrade path from 16f877a) but though Ithought I had it perfected, sometimes on start up it runs motor without being able to control it from knobs and switches.
wanted to see if someone would look at my code and see if I am doing any fundamental mistakes.
The 2 things i see it do occasionally is either run undo high or undo low which runs motor in reverse (1 second) to kick out drive train and other times it runs uncontrollably and the only control which seems to function is the off switch.
(Although when it does behave this way it never is not engaged in low or high speed, (solenoid activated) and direction relay is not energized to make reel pull. so it doesn't seem to pose a danger but I need to cure it!
Attachments
ML- REEL 16.31_887 .fcf
(99.63 KiB) Downloaded 228 times

medelec35
Matrix Staff
Posts: 9521
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times

Re: Some times program misbehaves not sure if using variable

Post by medelec35 »

Hi Mark,
I have just compiled your flowchart, and saw this in the compiler messages:

Code: Select all

Building CASM file
Serious Warning: Call stack usage exceeds:8!

Call Stack Usage Report
=======================
 main and Task(s): hw used:4, exceeded by:0
 interrupt: hw used:5, exceeded by:0

Serious Warning: Possible sw stack corruption, function 'FCM_MY_INT' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'delay_us' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Memory Usage Report
===================
RAM available:368 bytes, used:87 bytes (23.7%), free:281 bytes (76.3%), 
Heap size:281 bytes, Heap max single alloc:95 bytes
ROM available:8192 words, used:1945 words (23.8%), free:6247 words (76.2%)



success
Return code = 0

FINISHED
So the stack exceeding 8 and stack corruption could be causing the issues your facing.

Whenever a flowchart is compiled it's always wise to check Call Stack Usage Report

so with the first issue, you can either rearrange your flowchart to reduce stack usage.
Or increase software stacks. see:
http://www.matrixmultimedia.com/mmforum ... 165#p38548
Or use a chip with more hardware stack.

As for stack corruption .
Most common cause is having same component within an interrupt that you have in a non interrupt part.
E.g Anything congaing delays: LCD, Delays themselves RS232 etc. Mod function.

I will see if I can track down the cause of stack corruption and let you know my findings.

Martin
Martin

medelec35
Matrix Staff
Posts: 9521
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times

Re: Some times program misbehaves not sure if using variable

Post by medelec35 »

I have found 4 issues with your flow chart.

1 PWM component in MY_INT macro is causing a corruption warning
2) Delay component in FAIL_SAFE macro causing a corruption warning you can use 5 times nop instead = 1us at 19.66MHz.
e.g in a C code box:
asm
{
nop
nop
nop
nop
nop
}

Since
3) ADC component in MY_INT is causing stack to exceed 8.

4) may not be an issue since it's accessed before interrupt is enabled: There is a MY_INT being called by a call macro and an interrupt macro.
This would not be allowed if the call macro was after the interrupt macro.

I don't believe its a good idea to have ADC component within an interrupt. I believe its the delays used within ADC component that causes the issues but I could be wrong?

Martin
Martin

Post Reply