Page 1 of 1

Is your Project Not working? Help and General Advice

Posted: Mon Dec 14, 2009 4:28 pm
by medelec35
Here are some basic solutions.

First make a very simple 1Hz flasher, using an LED and something like 270R resistor in series.

Code: Select all

 Loop while 1
 Delay 500ms
 Delay 500ms

If LED not flashing at correct rate (or at all) then check:

A) All voltages are correct. VDD or VCC = +5V. VSS or VEE=0V. Measure output connected to LED with meter. You could have LED connected wrong way around.

B) Pin Functions. Pin may not be a bi-directional port capable of sourcing and sinking current. E.g. Could be an I/P only or open source. The latter means it can only sink current, so you will need to connect anode of LED via a resistor to +5V. Cathode of LED to pin (not to 0V) then LED is off when pin O/P is high and LED is on when pin O/P is low.

C) Configuration settings:
1) Clock frequency.
For V3 Go to 'Chip', 'Clock Speed'
For V4 Go to 'View', 'Project Options', 'Clock Speed'
Make sure 'Clock Speed' matches the oscillator running speed of your microcontroller. If correct speed is not one of the drop-down options, then manually type correct speed in Hz. These setting only controls the timing loops for delays and any time dependent routines it does not set the speed of your hardware. The speed of hardware is determined by crystal or resonator frequencies, Value of R C network or internal oscillator value.
Using the internal oscillator:
A lot of microcontrollers must have C box at the beginning of Main with something like
osccon = 0x60; (This makes the microcontroller I'm using run with internal oscillator at 4MHz).
Or osccon = 0x70; (This makes the microcontroller I'm using run with internal oscillator at 8MHz).
Consult the microcontroller datasheet for more details. Don't forget the semicolon at the end of C statement

Even if you have not got a Matrix EB006 or other Matrix programmer it is a good idea to have PPP installed and with both Flowcodes V3 and V4 select 'Chip', 'Compiler options' then have 'Use external program to set configuration options' selected. Then click OK. This will ensure the correct configuration is sent to chip via compiled hex file.
Now select 'Chip', 'Configure' then click 'Switch To Expert Config Screen'. If you have not got matrix programmer or pickit, then just select 'Chip' then 'Compile to Hex'. This will create a file with the project name and hex extension, which can be loaded into your programmer for programming micocotroller chip.

2) Oscillator Selection. If using internal oscillator then it is best set on INTRC as Port I/O
If using external crystal 4 MHz or over then select HS
If External Crystal is under 4 MHz then select XT

3) Watchdog Timer. I would advise this to be Off.
If left on and 'Auto clear watchdog' (V4 and above only) is not selected or clear_wdt(); (all Flowcode versions) is not used then microcontroller will keep resetting itself before it has had a chance to run its code. So LED will not flash.

4) MCLR or Master Clear Enable. Depending with target device you have got. If enabled then microcontroller will only work when pin associated with MCLR is at +5V. When MCLR pin is at less than +5V i.e. not connected then microcontroller is at permanent reset state so will not run.
Unless you want to have a reset switch connected to MCLR (using a pull-up resistor and use a normally open switch to short pin to 0V to reset) then have MCLR set to internal.

5) Background debug (if applicable to your target device). Leave this Disabled. If left Enabled this will use pins RB6 and RB7 and you will get some puzzling results if any I/P or O/P device are connected to these pins.

6) Low Voltage programming (LVP). It is recommended to have LVP disabled. If left enabled, then a pin (usually B5) will not be available for any i/p or o/p use.
So if you are using B5 and you are not getting the desired o/p, or i/p is not working, then check LVP settings.

C) General use of Flowcode.

If using port masking, only Bits ticked can be controlled (or masked to work). All bits unticked will not have its state changed.

If you have 'Entire port' selected and output set to 1, then bit one will only be high if 'Used Masking' is not selected, or if 'Used Masking' is selected and Bit 0 is ticked. All other Bits will be low.

Important Note:
You may find that using inputs that the results are not as expected/
If masking or single bits are not used, then any i/p that does not have a load connected to either +V or 0V will be floating.
If any pins are floating then you must disable them by selecting Use masking.
Make sure any floating pins are un-ticked and only have pins ticked that will be used.

Code: Select all

error: missing semicolon
This can caused by an unconnected pin, or a calculation that is wrong e.g Number = 23. 45 instead of Number = 23.45 (note the space where there should not be one!). Or could be C code box with semicolon missing at the end.

Note: If you leave a semicolon off the end of statement in supplementary code box then you will get a 'general error' and not missing semicolon error!

Another Common cause is if you have loaded a flowcode example, then changed the target device, so new device has not got the same ports as the original target device. When that happens, pins become unconnected.

E.g With a keypad.
Right click on the keypad that is on the panel, then select 'connections'
Make sure all connections are valid, and not showing unconnected!

To check for errors E.g when compling you get

Code: Select all

Return code = 1
Flowcode was unable to compile the flowchart's C code due to the following errors:'
If you download Notepad++ or notepad2 (or any other notepad replacement that shows line numbering).
Then in 'Chip, 'Compiler Options' Where is says file viewer, just browse to the new notepad replacement. You only need to do this once.

Now compile to hex. Note the top line number within brackets e.g: C:\path\file_Name.c(610): error: missing semicolon
You are interested in line 610.

Next Click on 'Chip' , View C....
New notepad replacement will load. Scroll down to line 610.
Look for any mistakes along that line.
If you can't remember the lines showing up with errors, just look when the flowchart is saved for a file with File_Name.msg
You can alternately load File_Name.c file into your editor which displays line numbers.

Timer interrupts macros:

It is important that you do not place any delays or components that will have delays in like LCD displays ,RS232 etc within timer interrupts. Keep interrupt macros as short as possible.
Components like LEDs and calculation icons are OK to use.
If you do use delays which lasts for longer than the timer interrupt takes to trigger, then corruption will occur giving unexpected results.
If you want to update a LCD display after an interrupt has occurred, then set a flag to 1 within interrupt. E.g. update_lcd=1
then for your LCD have a decision branch E.g
If lcd=1 then display macros : lcd=0

Code: Select all

Warning unreferenced functions removed:
Benj wrote:
"Warning unreferenced functions removed:

This means that the functions that you are not calling (referencing) in your program will not be included in the assembled hex file. Basically because your not using them they wont consume memory on the device. This is normal and one of the major advantages of using the C language.

So these messages are normal and can be totally ignored.

E.g if you have only one ADC ReadAsByte.
Then since it is not:
Then there will be a

Code: Select all

Warning unreferenced functions removed:
        FCD_ADC1_ReadAsInt    in: D:\PWM12F675chip1.c
    FCD_ADC1_ReadAsVoltage    in: D:\PWM12F675chip1.c
    FCD_ADC1_ReadAsString    in: D:\PWM12F675chip1.c

Along with some other functions not being used.

Code: Select all

Floating Point Calculations

Sean has added a very good point:
Sean wrote:There are some differences between the representation of variable and calculations in the PC simulation and the C code downloaded to the microcontroller.

The main calculation illustrates two issues with the way programs handle calculations.

1. A C compiler sometimes needs to be forced to use floating-point calculations to produce intermediate results (it will try to use integer calculations if the input variables are integers). This can be achieved by representing integer constants with one decimal place.

2. Bit shift operators (<< and >>) can not be used as multiplication and division because of the way floating point variables are stored.

The calculation shown below should give the same results as the simulation.

Calculate = (adc1*2048.0) / 1024.0
There is another point to consider when using the default BoostC compiler for the PIC devices.

Floating-point calculations are handled by function calls, so the calculation will need to be re-written into the following form:

Calculate = fmul(int2float(adc1), 2048.0)
Calculate = fdiv(Calculate, 1024.0)

Simulation accepts the normal operators for floating-point calculations (+-*/ etc.) as well as the function calls. The other versions of Flowcode can work with either representation

0/0 is undefined value, which the PIC reads as 255.
Thanks to nmindana for that useful tip.

Code: Select all

Difference between simulation results and real microcontrollers

Duty = (151/14)*800
Results should be the same with or without brackets
Simulation will show 8628 but the true result would be 8000
Reason for this: Simulation will do (10.785)*800 = 8628
Where as a microcontroller will do (10)*800=800= 8000

A micorocontroller that is not using floating point, will always round down.
e.g. 10.98 will be rounded down to 10

If anyone has any more hints, tips or comments to help people new to Flowcode get their project working then feel free to add to this list.
Thank you.

You can find support page here:
This may give you a solution to your problem.

Regards Martin

Re: Is your Project Not working? Help and General Advice

Posted: Sun Jan 24, 2010 11:07 am
by medelec35
Ben. Steve & Sean or any one else.
There must be other common issues that I have not mentioned. Please add to this list. After all I'm sure we have all been there when we first started using flowcode. perhaps If there is a sticky created, so common problems can be resolved by reading sticky first.

Re: Is your Project Not working? Help and General Advice

Posted: Mon Jan 25, 2010 4:37 pm
by Steve
That's a great list - thanks for taking the time to put this together.

Re: Is your Project Not working? Help and General Advice

Posted: Tue Mar 30, 2010 8:02 am
by ncc1502
It might be an open door, but........

My experience is that when you simulate a program, almost all variables have (automaticly) 0 as a value at the start of the program.

When running this program on a microcontroller, this is for sure not the case and unprodicted things (or nothing) will happen.

Therefor make sure that every variable has been assigned to a value at the start of the program (or before you start using it)!

Re: Is your Project Not working? Help and General Advice

Posted: Tue Mar 30, 2010 9:29 am
by Benj
Rule of thumb to follow when working with variables on micros is:

Do I read the variable before I write to the variable?

If you do then you must initialise the variable.

Re: Is your Project Not working? Help and General Advice

Posted: Mon May 24, 2010 6:21 pm
by medelec35
thank you ncc1502 For taking the time to post a very good point, it is appreciated.I should of replied some time ago...sorry about that! Bens rule of thumb is worth remembering!
If any one else would like to add to the list, that too would be appreciated, especially by those people who are stuck.

Re: Is your Project Not working? Help and General Advice

Posted: Sat Oct 16, 2010 12:53 pm
by medelec35
Removed information on missing semicolon, and added it to first post.

Re: Is your Project Not working? Help and General Advice

Posted: Mon Oct 18, 2010 7:58 am
by Steve
medelec35 wrote:To check for errors:
If you download Notepad++ or notepad2 (or any other notepad replacement that shows line numbering).
Then in 'Chip, 'Compiler Options' Where is says file viewer, just browse to the new notepad replacement. You only need to do this once.

You can even use Notepad itself to do this - make sure word wrapping is off and then select "edit...goto" to enter the line number you want to set the cursor to.

Re: Is your Project Not working? Help and General Advice

Posted: Mon Oct 18, 2010 8:57 am
by medelec35
Thanks Steve. I guess the reason for using notepad++ is not only do you have all line numbers showing so you can just scroll up/down. There is a free plug-in to compare two files against each other with all differences highlighted. Also different functions are in different colours e.g. defines, commented out text etc.
However your point about using notepad and go to line number function is a good idea if you don’t want to download and use a different text editor.

Re: Is your Project Not working? Help and General Advice

Posted: Thu May 01, 2014 9:11 am
by cardac
Hello folks. well - now if you go to the exmples of FLOWCODE5, there is a bunch of examples on INTERRUPTS.. One of those examples is.....4.Reliable Seconds Counter...
I tested this and it seems to work fine (incorrectly though however!!!!)... because when you examine it... there is a TIMER there that has a setting to do with pulses from RA4/T0CKI.. in the setup of the interrupt/timer ...
I built this up in real hardware.. and of course there is nothing pulsing my RA4/T0CKI pin... so that TIMER will not work...

Can someone at Matrix.. please either fix the code... or fix the FLOWCODE software.. so that there will not be an anomally...????

Thanks guys.

Re: Is your Project Not working? Help and General Advice

Posted: Sat May 31, 2014 10:41 pm
by Brendan
I'm getting some very odd behaviour with an 18LF8722 PIC (128k ROM, 4k RAM).

First, I've disabled the usual suspects, such as Extended Mode, etc...

Impossible I know to debug routines without seeing them, but looking for no more than general 'pointers' to this problem at this stage:

On compile to Hex, Boost-C reports the code is currently about 47k large with 1.5k RAM used. There's lots of macro routines - none of which involving timers/interrupts/etc, and many of those macros use both local and global variables. There's lots of basic I/O and 6 x PIC ADC channels used, effectively two LCD displays (dual controllers driving a 40x4-line LCD display), four soft-configurable buttons, 224 o/p plus 224 i/p shift-registers for port expansion, other o/p and DAC shift-registers on separate DUT and Slave boards, etc.

Now I have a routine that checks which button is pushed should the test routine halt on a failure, the idea being that the user can elect to continue, repeat, or quit. As the test is run a test sequencing counter is used to index test control arrays, but the same counter value is also used to 'look up' verbose failure report strings (sent to the LCD) which are all contained in a separate macro with 112 stacked switches (effectively case statements). Therefore, the displayed failure report is simply based on the count value in the test sequence.

So... when the test runs, the test sequence counter counts down on each test loop which sets up all those shift registers for the next test, and should the test fail then the very same sequence counter is used to index the appropriate failure report. The counter is only decremented each time the main loop repeats to conduct the next test.

Now... the weird thing is that I'm getting the correct report on failure, and the button-press is awaited. However, after pressing/continuing, an erroneous report immediately follows (e.g. for sequence no. 25) without repeating the loop. At this point you'd expect that the test sequence counter were also corrupted, but pressing the continue button again correctly recommences from the last count and the next test in the sequence is correctly run. On the next failure the continue button is awaited so is pressed again, and again the very same erroneous failure report as before is immediately generated (outside the loop) before the continue button is again pressed and the next (correct) test in the sequence is run. By way of example, sending only the sequence counter value to the LCD looks something like...

'110'...Continue button...'25'...Continue button...'93'...Continue button...'25'...Continue button...'78'...Continue button...'25'... (etc).

As all works like a top in Flowcode, and in hardware too with some general build changes, there's obviously something corrupting something else in hardware, and so far I've managed to establish that the erroneous report/value above can change based on unrelated changes in the code.

As there's reportedly bags of code space and RAM available, I'd be grateful for any general gotcha's or things to explore as a starting block, least-of-all anything that might explain weird behaviour of this nature - particularly inexplicably and temporarily jumping out and returning to a loop such as described above, and the momentary shift in value of what should be a single global variable. The micro supply does appear to be well-decoupled, and I've seen the same thing on two separate boards now.

Many thanks in advance,


Re: Is your Project Not working? Help and General Advice

Posted: Mon Jun 02, 2014 4:25 pm
by Benj
Hello Brendan,

Hmm this seems like a tricky one to debug.

Could be that there is something like a write to an array that is going over the end of the array and therefore corrupting a different variable stored in RAM, the v6 simulation wouldn't show this problem as it detects this and extends the simulated array appropriately. This is just so you can do things like stream from a file without first needing to know how big the file is.

Might also be worth turning on the reset on stack overflow config setting if available just in case the limited hardware stack which keeps track of where to return from subroutines and macro calls etc is falling over.

Re: Is your Project Not working? Help and General Advice

Posted: Tue Jun 03, 2014 1:19 am
by Brendan
Thanks Ben :)

Yes, a tricky one, though I'll follow your advice and experiment with stack overflow reset as it is available on this PIC.

As time is never on my side (when is it !? :roll: ) I may just end up simplifying the routines to reduce stack depth. I certainly do have a shed-load of dependent macros and subordinate loops, though naively thought the considerable RAM would supplement the limited hardware stack, so doubtless something like that.

Regarding the large read and write arrays, they're initialised on startup and universally defined from the highest index value first (as required for the shift-register R/W chains) and universally exit at 'loopcount <1', so I'm quite sure stack overflow is the culprit. Your comments noted on possible array overflow conditions though (thanks again).

All the best,


Re: Is your Project Not working? Help and General Advice

Posted: Tue Jun 03, 2014 9:51 am
by Benj
Ok let me know how you get on with it.

If you get stuck and want me to have a look at the file then you can send via a PM if the file is sensitive.

Re: Is your Project Not working? Help and General Advice

Posted: Tue Jun 03, 2014 8:27 pm
by Brendan
Thanks again Ben.

I've started flattening and paring down the structure in the hope that I'll stumble across the culprit, and will post back should I discover something noteworthy for the benefit of others.

I understand the chip supports under and over-flow, but when enabled no resets or restarts - despite the odd behaviour. Certainly an odd one this :?

All the best,


Re: Is your Project Not working? Help and General Advice

Posted: Thu Oct 08, 2015 9:34 am
by DCW
hello folks...!! yes - I am a bit confused.... so please help me...

I construe a very simply flowcode.. it starts with an input icon.. linked to ... say B0 pin on the processor...
I also have a 'byte sized' register called B0... and the default value is a '1' ....
I also have pushbutton ... with properties connecting to B0... pin of the processor..

then after the input icon.. I have the 'decision' icon.. with the test... (if B0 = 0 ?) ... set into the setup of the 'decision' icon..

then I simply loop back to the beginning...

When I single step that flowcode... and I add the variable register... B0.... to be displayed in the simulation window... and when I do the input icon test... the value simply falls to 0...!!!!

why is this please.??? ..

now I have something even more intriguing... to mention...

after a while of 'sitting' in the simulation mode.... and resetting the B0 to a 1... on the simulation window... then the most amazing thing happens...!!! when I do the single step emulation... instead of the B0 register value getting set to 0... it stays on '1' value.. and you can single step or simulate the loop ..'at full speed'... it does not set back down to a 0... anymore...

the pushbutton I have... set at... Active Low.... (because I am expecting to have that B0 input tied up to +5v with a resistor... and have the push-button switch .. force that input to 0 volts...)..

so now - can someone please explain this to me..??? I have tested it on many attempts at different times... and even on different machines... and I get the same thing happening...

It is very frustrating.. to have to write flowcode... whilst this is happening... I have been taught to use - a negative going trigger on an input of a processor... so that is why I try to do it in flowcode...

Please help ... someone... I want to use flowcode... in that mode... and not to have to redesign my circuits to be +ve pulsed on the input of the chip...

I await any brilliance in this respect...
Kindest regards

Re: Is your Project Not working? Help and General Advice

Posted: Fri Oct 09, 2015 1:02 pm
by Steve
Hi Spen,

There should be no need to redesign your circuits and Flowcode should be capable of doing what you want.

The pushbutton component will always set itself back to "off" when it is not being pressed. This means that when you manually step through a program, there is no way to keep the pushbutton pressed down. Perhaps this explains what is going wrong?

If you're still having problems, please post your program and someone will have a look.

Kind regards,

Re: Is your Project Not working? Help and General Advice

Posted: Fri Oct 09, 2015 9:47 pm
by Brendan

Without sight of your code, I can only flag a few pointers which may or may not be of help...

Instead of manually stepping through the code, let it free run but slow stepping right down to perhaps 1s per step. Then, while running, click and hold the pushbutton throughout the complete simulation cycle and observe the holding variable. It visibly should go from 1 to 0 with the button held down (click-hold with the mouse) with the conditions you describe, and back to 1 when re-read without the button pushed. I do find that simulation has display persistence, but initialising values within the routine ensure you're always getting what you expect - as would be required in the compiled code by way of good practice.

Second thought would be to try another button/switch, in-case there's a possible problem with the particular button component - albeit unlikely.

Third would be to ensure the button port bit is dedicated to the button as a simple logical input.

Fourth would be to check that you haven't inadvertently masked out the port bit when readiing the button bit status.

This may all seem very obvious but I've used dozens of buttons and indicators dynamically in very complex simulations with professional code, and have never encountered such issues when plenty of time is allowed for graphics to be updated in simulations. I can only think it's likely an issue with the routine or something more unique/obscure that can only be analysed/advised with sight of an example project you're having problems with.

If you were able to post your code, someone will surely help to identify your problem.

All the best,