Flowcode corrupt?

[echase]

Am having problems with Flowcode in last few days and am being to wonder if my installation is corrupt or Windows XP has done some update that is conflicting with it. Probably more likely my faulty programming though. At all times the simulation is correct.

I have changed the PIC and LCD to see if it’s a hardware fault and it makes no difference.

Symptoms include

1) When running a simple test loop that should display the time and clock up seconds, minutes and hours it starts OK but then displays random corrupt characters at times instead of numbers, e.g. hours might cycle through 23, 23, L8, 23, <8, 4, 23 and some non English characters/symbols I can’t replicate here. The variables are correct as they always go back to displaying the correct values after the corruption.

2) On another version of programme the hex file is not found, see error message below, even though, when I select the ‘Compile to HEX’ option there is no error message.

Is the
Serious Warning: Possible sw stack corruption, function '__div_16_16' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)

below a problem? All the other warnings are standard ones that do not seem to upset any of the various versions of the programme.

A problem could be that I am running a cut down version of the full programme in order to get the timing loop right before correcting it in the main programme. There are lots of remnants of the full code there that could be upsetting the timing loop, but as it works on the simulation it's difficult to see what these upsets might be.

Another problem that is probably not related is that this interrupt TMRO Overflow driven timing loop (it counts up to about 900 so that makes one minute at my low clock speed and prescaler; 15Hz interrupt frequency ) worked accurately on an 16F886. But on the 16F2520 the timing is very very slow.

Error message:-


Building CASM file
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 'FCD_LCDDisplay0_PrintString' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCD_LCDDisplay0_Clear' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCD_LCDDisplay0_Cursor' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCM_Set_variables' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCD_LCDDisplay0_PrintNumber' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCM_Reset_buttons_to_off' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCM_Button_time_loop' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'delay_s' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)

Memory Usage Report
===================
RAM available:1536 bytes, used:261 bytes (17.0%), free:1275 bytes (83.0%),
Heap size:1275 bytes, Heap max single alloc:127 bytes
ROM available:32768 bytes, used:16882 bytes (51.6%), free:15886 bytes (48.4%)


success

.............
Return code = 0

Launching the programmer...

C:\Program Files\Microchip\PICkit 2 v2\PK2CMD_MTX\pk2cmd_mtx.exe -PPIC18F2520 -F255B57~1.hex -M -A3.6 -H


Hex file not found.


.........
Return code = 37

Flowcode was unable to transfer the flowchart to the microcontroller. Check the programmer options and physical connections.

FINISHED

[Benj]

Hello

You LCD corruption has something to do with these warning messages.

Serious Warning: Possible sw stack corruption, function 'FCD_LCDDisplay0_PrintString' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCD_LCDDisplay0_Clear' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCD_LCDDisplay0_Cursor' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)

Say you main task is writing to the LCD. Half way through an LCD write routine an interrupt occurs. Inside the interrupt there are macros to drive the LCD. These macros find the LCD in an unexpected state and the data that would normally work corrupts the original command that was being written back in your main routine.

There are three potential ways around this problem. Option 1 is probably the easiest to work with.
1) Make sure all of your LCD routines are outside of the interrupt handler and just use variables to update the display in your main program.
2) Keep the LCD routines in your interrupt handler but in your main program disable interrupts before you call LCD functions and re-enable interrupts once the LCD functions have been finished.
3) Add the following lines of code to the start and end of each of the LCD macros in the LCD component C code file. This will disable interrupts while processing a LCD command.

Start - clear_bit(intcon, GIE);
End - set_bit(intcon, GIE);

On the 18F2520 you may have an incorrect configuration setting that is causing the program to run slow. Alternatively the interrupt rate from the timer could be much slower on the 18F device if TMR0 is 16-bit instead of 8-bit. Go into the timer interrupt enable properties and you should be able to compare the Interrupt frequency values.

Regarding your hex file not found problem does this occur every time or was this a one off thing?

[echase]

Clashing calls to the LCD sounds a plausible reason but:-

1) I don’t call the LCD component from within an interrupt except perhaps from the button_time macro which works on a ‘when PORT B changes’ interrupt on the switches. But this LCD corruption occurs when the buttons have not been accessed for ages.

2) The errors only ever occurs in numbers as PrintNumber. Letters or numbers as PrintString are always OK. Would the interrupt problem not affect both?


3) Adding the extra lines to the LCD component made no difference. But did I put them in the right place with right syntax as follows with beginning and end of file shown? I am reluctant to stop the interrupt for the LCD as it will slow down the clock and introduce uncertainty in its timing.

/*********************************************************************

clear_bit(intcon, GIE);

Return & parameter types:
.
.
.
/*Macro_Γ‰crit_ChaΓ®ne_End*/
/*Macro_ImprimirCadena_End*/
}
set_bit(intcon, GIE);

Incidentally I assume the ‘French’ in the original is correct.

4) I have had similar error messages in earlier versions of the software that did work fine. Here is an example of messages for good code.


Serious Warning: Possible sw stack corruption, function 'FCD_LCDDisplay0_PrintString' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCD_LCDDisplay0_Clear' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCD_LCDDisplay0_Cursor' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCM_Set_variables' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCD_LCDDisplay0_PrintNumber' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCM_Reset_buttons_to_off' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCM_Button_time_loop' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'delay_s' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)

However the message, Serious Warning: Possible sw stack corruption, function '__div_16_16' called by more than one asynchronous thread (main/Task, interrupt, interrupt low), is a new message so maybe that’s a clue. The ASM for the div_16_16 is as follows, but its beyond me to begin to understand what box in Flowcode this code is trying to implement.

__div_16_1_00005
; { __div_16_16 ; function begin
CLRF __div_16_1_00005_1_r, 1
CLRF __div_16_1_00005_1_r+D'1', 1
CLRF CompTempVarRet96, 1
CLRF CompTempVarRet96+D'1', 1
CLRF __div_16_1_00005_1_i, 1
label268435524
BTFSC __div_16_1_00005_1_i,4, 1
RETURN
BCF STATUS,C
RLCF CompTempVarRet96, F, 1
RLCF CompTempVarRet96+D'1', F, 1
RLCF __div_16_1_00005_arg_a, F, 1
RLCF __div_16_1_00005_arg_a+D'1', F, 1
RLCF __div_16_1_00005_1_r, F, 1
RLCF __div_16_1_00005_1_r+D'1', F, 1
MOVF __div_16_1_00005_arg_b, W, 1
SUBWF __div_16_1_00005_1_r, W, 1
MOVF __div_16_1_00005_arg_b+D'1', W, 1
CPFSEQ __div_16_1_00005_1_r+D'1', 1
SUBWF __div_16_1_00005_1_r+D'1', W, 1
BNC label268435529
MOVF __div_16_1_00005_arg_b, W, 1
SUBWF __div_16_1_00005_1_r, F, 1
MOVF __div_16_1_00005_arg_b+D'1', W, 1
SUBWFB __div_16_1_00005_1_r+D'1', F, 1
BSF CompTempVarRet96,0, 1
label268435529
INCF __div_16_1_00005_1_i, F, 1
BRA label268435524
; } __div_16_16 function end

I will email the C and ASM code in full.

I did wonder if there is a hardware problem causing the bits arriving at the LCD to be corrupted since leaving the PIC, but this theory does not accord with the past good behaviour (repeated if I reload the old code) and the strings being correct but not the numbers.

Note, I am not using you altered LCD component that accepts inputs from two Ports in this code. That is another project.

I am going to use the PWM to drive a Buzzer. Is this Interrupt driven and so could it cause similar LCD problems?

The missing hex and timing problems have gone away. Not quite sure what I did to make them go!

[Benj]

Hello

Ok maybe the problem has something to do with your div16_16 macro. The PWM is not interrupt driven and should not cause any problems in your application.

The correct syntax for disabling interrupts would be.

{
/*Macro_Γ‰crit_ChaΓ®ne_Start*/
/*Macro_ImprimirCadena_Start*/

clear_bit(intcon, GIE);
.....
function code
.....
set_bit(intcon, GIE);

/*Macro_Γ‰crit_ChaΓ®ne_End*/
/*Macro_ImprimirCadena_End*/
}

Maybe you could just try it for your print number routine if this is the only routine that is causing problems.

Another possibility is that you are overflowing the stack. Eg if you have more then 6 or 7 macro layers away from the main function then the chip may not be able to trace back down to the main function. There is a way of turning on the BoostC software stack which will give you 256 layers. Switching on the software stack is detailed in the BoostC manual included in the Flowcode V3/BoostC folder.

[Steve]

I've seen issues like this when the interrupt routine is doing far too much than is generally recommended. For efficiency, your interrupt routine should be as short as possible. Anything that will take more than a few milliseconds to perform (e.g. output to an LCD) should occur in the main program loop.

[echase]

Thanks, I will try some of these changes tonight.

I still have not found my div16_16 macro. There is no macro with that name that I have created or visible in the C code so it’s something done in Assembler which I can’t trace back to the C code.

[echase]

OK I think you were right about too much in the TMR0 interrupt. Or rather because I was running at so low a clock speed (125kHz, to save power) what little that was in the routine does not complete in time to get around all the delays set by the LCD component.

There seems to be a 1:1:1 correlation between slimming down this interrupt routine with the error message '__div_16_16' disappearing and the LCD then working.

But there is something odd about the V3.6 LCD component you sent me Ben. Are you sure it is correct and compatible with my Flowcode v3.4.7.48? With it in place my read switches interrupt on PORT B change never works, so I can’t read any switches. Can’t see why an LCD component would affect a PORT B interrupt.

Never mind, the LCD appears to work now with the older LCD component, despite its alleged minor bug, as long as I cut the code in the TMR0 interrupt or increase the clock speed.

[echase]

But there is something odd about the V3.6 LCD component you sent me Ben. Are you sure it is correct and compatible with my Flowcode v3.4.7.48? With it in place my read switches interrupt on PORT B change never works, so I can’t read any switches. Can’t see why an LCD component would affect a PORT B interrupt.

I immediately stopped using the V3.6 component because of this. Interesting though that the older V3.4 component is sometimes exhibiting similar problems now as some versions of the software do not react to some or all of the buttons.

Is this another case of the FCF not fully reverting when the original component is used? i.e. has it saved a bit of the V3.6 in the FCF.?

I wonder if a full upgrade to v3.6 might clear out some of these problems. Although I am nervous about introducing fresh problems because of the upgrade. Is it possible to uninstall v3.6 and reinstall v3.4 if I have problems?

[echase]

But there is something odd about the V3.6 LCD component you sent me Ben. Are you sure it is correct and compatible with my Flowcode v3.4.7.48? With it in place my read switches interrupt on PORT B change never works, so I can’t read any switches. Can’t see why an LCD component would affect a PORT B interrupt.

OK I now see what the problem was. I edited my v3.4 LCD component file some time back to add trisb lines to enable the switches to be read. Of course the new v3.6 file you sent did not have these extra lines.