Program stops by itself

[Jan Lichtenbelt]

I met a big problem. The flowcode V5 program starts correct but after a while it stops by itself. Can someone looks into the msg.txt-file for me if there is sometime the take care???

Thanks

Jan Lichtenbelt

[kersing]

Jan,

The only questionable message I see is that delay_us requires argument of minimal 1. Do you have a delay of 0 somewhere in your program?

Regards,

Jac

[Jan Lichtenbelt]

Jac,

Thanks for your help. I checked the C-program, but this is without delay_us. It is only a 'çaution' message.

But what is the meaning of: '16F19xx memory map used', while I use the 12F1840?

Jan

[kersing]

Could you check "build" -> "project opties" -> "chipconfiguratie". What chip is listed at the top right?

[JonnyW]

Hi Jan. Could you clarify what do you mean it stops by itself - how long does it take to do this?

Memory allocation issues are unlikely but buffer overrun issues are possible, corrupting memory. Also do you use recursion anywhere in your program, or loops inside macros other than Main?

What happens during simulation? Does the program simulate with no problems or warnings? It could also be something like a component waiting (looping) for a state to change, such as SPI, which is never happening, maybe because it is in an interrupt or something similar which disables comms in some way.

If you post your program we can take a look, but these are some of the more common causes of a lock-up.

Jonny

[Jan Lichtenbelt]

Dear Jonny,

Thank for your help. You mentioned:
1) memory allocation are unlikely
2) buffer overflow? How can I get beware of it?
3) the program can not be simulate due to a lot of C-program steps
4) no recursive loops are used.
5) looping could be possible, but works in the initialise maco correctly. The same is used in the main macro, were the program stops

The extra problem is that I use the 8pins 12F1840, which make impossible to use the LCD. I use the RS232 ouput to an other EB006 board with RS232 receiver and LCD. I will do some extra test to see where it really stops. Up to now, it seems to me that is stops on more then one place in the program.

Can you react of point 2). I will check setup in the mainwhile further.

Kind regards

Jan Lichtenbelt

[JonnyW]

Hi Jan.

When using C code blocks it will not be easy to find any buffer overflows - Flowcode v5 detects any array overflows in Flowcode icons during simulation, but not in C. The simplest way would probably be to just look through the code manually and check all the logic that refers to arrays and array access. To find these icons you can use the Find/Replace dialog - search for the '[' bracket and Flowcode will list all the icons (including C) that contains this - remember to search in all macros.

Without seeing the code it is difficult to know if stack overflows (from recursion or not) or array overflows are likely.

Good luck,

Jonny

[Benj]

Hello,

I would start by finding out if the issue is related to time the processor has been on or due to a software issue, I would suspect the latter though things like the watchdog timer could cause the former to be an issue.

Edit your code so that there are specific steps, eg maybe outputting a count to LEDs. Then try and use this count to start to debug where the program is hanging. Is it always in the same place? If so then you can start to track down where the problem is creeping in.

If the program is crashing at different places then do you call any macros from your interrupt routines or do you have lots of interrupts running at the same time. This should be ok but could lead to problems if two interrupts were reference the same function eg a small delay in a LCD function.