On Fri, 2006-09-01 at 12:51 +0100, Tamas Rudnai wrote:

> I have a problem on my project that when I debug my code it is absolutely
> perfect, however, in the real world it seems that there are just much more
> things that I did not take into account. My problem is that as far as I
know
> there is no way to track down what's going on even using a hardware debug
> station -- but I may wrong. So that the PIC needs to be run in the real
> clock speed while I would need to watch the input and output signals as a
> logic analyzer and see the code flow so that I can have a chance to detect
> why my code enters to the bad state.

Tamas,

You may wish to consider gputils and gpsim. With these tools, it's
possible to instrument your PIC source code with a variety of
debugging mechanisms to simulate real world behavior.

For example, you may know that at a certain point in your code that
some variable is in a certain range. However, you suspect that somehow
this variable is getting corrupted. In your source PIC code, you can
place an assertion:

SomeSubroutine:
  .assert "(my_var>=0x20) && (my_var<0x30)"
   movf  temp,W

When the movf instruction is executed, the assertion will examine that
the contents of 'my_var' are in the expected range.

Or you may just want catch the point where the upper two bits of 'my_var'
are set:

  .sim "break w my_var, (my_var&0xf0) == 0xc0"

There are many, many more assertions and breakpoint mechanisms
supported.


Or, you may wish to stimulate I/O pins or variables. gpsim supports an
"asynchronous_stimulus" mechanism that essentially allows you to
create any type of waveform imaginable. Waveforms can be attached to
I/O pins to simulate real world devices. Or, you can create a register
stimulus to simulate the changing of a register value. (Actually this
concept is extended to all simulator "attributes". Nearly anything
that can be written to can also have an attribute stimulus connected
to it. This is useful for driving external modules).

If it turns out that the built in simulator mechanisms are
insufficient, then you may wish to check out the external
modules. Probably the most popular is the USART. But there are others
like switches, LEDs, LCDs, resistors, simple logic devices, etc.

And if the built in modules are inadequate, you can always write your
own modules.

I use gpsim to test my personal PIC. Probably my most complicated project
is an 18F452 based design that has an RS232 interface, a proprietary
RF interface, a graphic LCD, several switches, an external 32kHz
crystal and a few other minor resistors. With this setup, I can
validate that an RF data stream is received correctly (or more
importantly, can test that the corner cases work and that erroneous
streams are recognized as such). I use the USART interface for
debugging and displaying information about the system. With gpsim's
USART module, I can design the UART output without having to burn a
chip. Similarly, I can design user interface screens in a simulation
environment by using gpsim's graphics LCD module.

Scott
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist