Running fine in Flowcode but not in HW ??

[ksor]

How serious should I take these warnings:

Serious Warning: Possible sw stack corruption, function '__div_16_16' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCM_Initialiser' 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)

I use the TMR0 overflow interrupt to reset a counter display, but it never resets - is there a connection to the warnings ?

[ksor]

I have found out to eliminate one of the serious warnings but still I have these:

Serious Warning: Possible sw stack corruption, function '__div_16_16' 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)

How can I found out where/what is causing these serious warnings ?

[ksor]

Serious Warning: Possible sw stack corruption, function '__div_16_16' 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)

I only have 1 statement where I use "division" if "function '__div_16_16'" has to do with that - that's here:

ShowThis = InCommingPuls/PulsPrOmdr*60/13

ShowThis and InCommingPuls are declared as INT and PulsPrOmdr is declared as BYTE.

How should this calculation be done to avoide the serious warning ?

What about the last warning ?

[Sean]

Hello,

If you are using interrupts, it is important that the code within the interrupt handler is kept as simple as possible.

If you are calling macros or delays from within an interrupt handler (not advisable), these might call functions that are executing in the main program and cause data corruption or stack overflows.

[ksor]

I have 3 interupt service rutines - here in descending order:

A lot of things going on !!!

1.jpg (39.75 KiB) Viewed 12266 times

Here I do the calculation with the division

2.jpg (17.44 KiB) Viewed 12266 times

Just an UP counting af a variable

3.jpg (7.39 KiB) Viewed 12266 times

The 3. interrupt is RB0INT and is disabled and enabled in the 1. interrupt

The 1. and the 2. interrupt is both TMR0 overflow interrupts but desided by the state of a switch

Is this too complicated a content for interrupts service rutines ?

[ksor]

I have 3 interupt service rutines - here in descending order:

1.jpg

2.jpg

3.jpg

Now I reduced the interrups to be as simple as the 3. one and ALL warnings disappeared !

But still not working in HD - but it works fine in Flowcode

[ksor]

I found out that the CHIP settings should be HS instead of XT here:

HS.JPG (53.57 KiB) Viewed 12262 times

for my HW to work (at least "work better" - still missing a little but I have to investegate that)

But in fact I have an EXTERNAL X-tal (to be honest a resonator !) - what does HS mean ?

[ksor]

I have a problem left in my HW version !

The Flowcode is working fine and I can step through the flowchart and it's doing what it's supposed to do.

The "facility" I'm going for is 1 pushbutton for both "FREEZE" and "RESET TO ZERO" - when first pushed the display is freezed and when the button is HOLD DOWN for a while further the display is reset to zero - it works fine in Flowcode but NOT in HW !

Here is the flowchart i two parts:

PART 0.JPG

(104.81 KiB) Downloaded 3148 times

PART 1.JPG (32.75 KiB) Viewed 12261 times

Any ideas of what goes wrong ?

[Steve]

Regarding your ISR and the "stack corruption" warning - it's because you are using the "switch" macro in the first one, and this has a reference to the "delay" function. You could try reading the pin directly instead using the "input" icon.

The "HS" is the required setting when using a crystal (or resonator) above 4Mhz - check the device datasheet for more info.

[ksor]

I HAVE reduced my ISR so they ONLY do some UP or DOWN counting of a variable - and that's removed ALL my warnings - as stated in an earlier posting.

My 3 interrups only has 1 line of code - like Var1=Var1+1 or Var2=Var2-1.

My problem now is that the branch marked with the arrow in my last post is NOT executed in my HW - it runs fine in Flowcode !

When a pushbutton is pushed, it should in the first place FREEZE the display with a counting result and if the button is HOLD DOWN a little longer, the display should reset to "0000" - and it does in Flowcode but not in HW.

[Steve]

When you have hardware issues, it tends to be issues with the configuration settings - e.g. wrong oscillator frequency or type, watchdog, etc.

Without having access to the exact hardware you have, it is very difficult for us to fix your problems remotely.

[ksor]

[Steve]

I understand that it will make you sad, but one of the skills a programmer needs to develop is the ability to debug problems in their own programs. This is not something you can expect others to do for you, but of course we'll always try to help where we can.

And if you do ever find debug your program and uncover a bug in Flowcode, then we'll obviously try to help find a workaround or issue a fix.

[ksor]

OF CAUSE you can't solve my HW-problems - I know !

I'll have to pin-point the problem more precise and maybe make a sample to illustrate - and I'll try that.

[Benj]

The problem may be due to the <=0 statement.

Is the variable a byte or an integer?

If it is a byte then you should be able to get away with =0.

If it is an int then the code should work correctly if the number is 0 or negative.

One way to test things like this is to create a very simple program and then preset the variable with eg 0 or -1 etc. Then light an LED if the decision icon returns true. Maybe light a different LED if the decision is false just to confirm that the program is running as expected on the hardware.

[ksor]

The variable is an INT and it descents (by TMR0 overflow interrupt) with 4 every time it's doing the test - for safety I have "<=" if my initial value should NOT be a multiply of 4.

In my HW it will never choose the YES branch - the C-code looks right I think - but I think I'll have to make a small test sample to see how it reacts on the "<=".

I'll let you know the result.

[ksor]

This little sample show branching i details and it works in Flowcode AND in HW !

Two pushbutton counts UP or DOWN an variable and the LEDs shows if the variable in >0, =0 or <0 (NOTE: I have used >=, = <= in the flowchart and then reversed YES and NO !)

So branching works in my HW - I beleave - right ?

Then I have to find out if my TMR0 is in fact running in my HW !

[ksor]

MY GOD ... if I display the variable TelNedTilNulstil (in english = CountDownForResetToZero) it stays on it's initial value !!!!!

Then I see 2 possible causes:

1)
The TMR0 is NOT running in HW
2)
Then TMR0 ISR is NOT executed because in the ISR the variable in counted DOWN with this formula:

TelNedTilNulstil = TelNedTilNulstil-1

I have tried to change the ISR to TelNedTilNulstil = TelNedTilNulstil +1 (adding instead) - still the displying shows the initial value.

Then I think TMR0 is NOT running in my HW - how can I check that ?

[Benj]

Hello,

If the timer does not appear to be running then check your interrupt enable properties and ensure that the clock source is selected as CLKO. This is the internal clock source.

If this does not help then you could test it by say lighting an led by turning on an output when the interrupt fires.

[ksor]

Hello,

If the timer does not appear to be running then check your interrupt enable properties and ensure that the clock source is selected as CLKO. This is the internal clock source.

In fact I did do that and it's all OK.

My program has 2 "modes" - 1) simple COUNTING revolution 2) measuring RPM.

In both modes I use TMR0 interrupt but with different service rutines - I beleave this IS allowed - when I enable TMR0 interrupt with the interrupt icon in COUNTING mode , I just reference ONE service rutine and when I enable TMR0 interrupt with the interrupt icon in RPM mode , I just reference ANOTHER service rutine.

The TMR0 interrupt in the RPM mode IS running, but the TMR0 interrupt in the COUNTING mode DOES NOT (05 - RPM og Counter.c )!

Concerning TMR0-interrupts the first icon running in the flowchart is a DISABLE - at that time no ENABLING-icon has yet specified a service rutine.

If I - just for fun - in my initialision macro sets up a TMR0-interrupt with the service rutine I want to use in the COUNTING mode then my HW works as supposed to in the COUNTING mode - but now NO TMR0 interrupt in the RPM mode appeares !

Maybe something IS wrong in this shifting service rutine !

Maybe you can see some malfunction in the code files here:

[Benj]

Hello Ksor

We have recently put a warning into the interrupt service routine that warns you if you try to enable the same interrupt but reference 2 different macros as this will not work in the C code. This modification is in the v4.3 release of Flowcode which will be released shortly. Basically the interrupt will always use the function that is listed first in the C code rather then the function it is being assigned.

Therefore to get around this problem you should instead use a global variable to control a decision inside the interrupt routine rather then trying to use several different interrupt routines.

[ksor]

OK - I haven't read through all the postings in "Bugs" and "Suggestion" section - maybe I should do that.

Have you got a release date for version 4.3 ?

(And i have checked and it's workes fine !)

[Steve]

v4.3 will be available imminently - we are undergoing some final checks now.

[ksor]

How "much" can I in fact change "on the run" in an interrupt - not the service rutines,
but can I change prescaling in diferent anables of the TMR0 interrupt ?

[Benj]

Hello Ksor,

Yes the prescaler can be changed by using multiple interrupt enable icons. I use a switch case here for a scope example that changes the prescaler to adjust the sampling speed.

The only thing that does not work when using multiple interrupt enable's is multiple macros that process the same interrupt source.