MPLAB / MPSIM - How do I log/trace a registers contents to file?

[K Ludger]

The subject says it all - I might be having a hard day but I can't find a
solution in the MPLAB user manual or google.

I'm trying to test a calculation routine across its full range of input
values so I want to run the program and write the contents of a couple of
registers out to a text file on each pass through a loop. Should be simple -
right?

Thanks.

 

[K Ludger]

It might be a "simple" thing.
But Microchip is not too good at presenting needed info, starting with
what pin numbers are used for programming their PICs: missing on various
"adta sheets", inconsistent labels / terminology of those pins; the info
is scattered over a number of documents with no guide or clue as wher to
look.
Programming via one of their kits is as bad; no guide as to what / where
the progammer is, no clue that the "demo board" is a demo and not a
programmer.
Hell, the so-called data sheets that i have seen have zero DC specs
almost zero AC specs (set-up times, hold times, rise times, fall times,
etc).
It seems that the ASS-u-ME-uption is that one inherently knows the
answers to PIC questions before one learns to read.
And it is extremely helpful that these "data sheets" are multi-megabytes
in size - therby cutting out everyone on dial-up (will NOT spend umpteen
hours to download !one! file).
If you have high speed internet, then take days to download the
terrorbytes of documentation and write a program to traverse them all,
looking for *your* keywords.

Thanks for the response Robert - I tend to agree with much of what you say.
I've got the MPLAB/MPSIM manuals which seem to contain a lot about stuff I
found by playing but not much on tacking register contents.

 

[Paul E. Schoen]

The subject says it all - I might be having a hard day but I can't find a
solution in the MPLAB user manual or google.

I'm trying to test a calculation routine across its full range of input
values so I want to run the program and write the contents of a couple of
registers out to a text file on each pass through a loop. Should be
simple - right?

In the help for MPLAB SIM I found the following under register trace:

The value of a specified register may be saved to a file (traced) during a
run for certain conditions (see Table: Definitions of Register Trace).
Specify register trace information here.

I have not actually done it, but it sounds like it should be possible. The
best place to ask is http://forum.microchip.com.

Paul

 

[K Ludger]

Have you tried posting and searching in microchips forums?

Thanks mook, yeah I've been there.

 

[Paul E. Schoen]

In the help for MPLAB SIM I found the following under register trace:

The value of a specified register may be saved to a file (traced) during
a run for certain conditions (see Table: Definitions of Register Trace).
Specify register trace information here.

I have not actually done it, but it sounds like it should be possible.
The best place to ask is http://forum.microchip.com.

I did a little experimenting and I was able to get a file with a trace of
the value of a user-defined file register upon each entry into a procedure.

I used Stimulus-Register Trace, and I set the Reg/SFR to "ledcount", and
the PC value to "BlinkUSBStatus". I created a text file for the results,
and chose "Dec" format. I set the width as 2 since the variable is an
integer. I am using my USB project, which is modified from the USB FS Demo,
and the "ledcount" simply runs from 0 to 9999 as a delay for blinking
status LEDs. When I click on "Apply" it tells me that the synchronous
stimulus was applied successfully, and it also clears the content of the
text file. When I run the simulation and stop after a second or so, or upon
a breakpoint, the file shows a succession of integer values from 0 to 9999.

I was unable to get a trace on the WREG register or LATB, but I was able to
see the PORTB register.

If you want to update the trace on a PC that is not named in the drop-down
list, you can use the disassemby listing to find the hex value of the PC
you want, and enter that.

It seems that it is best to set up separate files if you want to trace more
than one register, but a single file does work. It just adds the second
trace at the end of the first.

HTH,

Paul

 

[K Ludger]

I did a little experimenting and I was able to get a file with a trace of
the value of a user-defined file register upon each entry into a
procedure.

I used Stimulus-Register Trace, and I set the Reg/SFR to "ledcount", and
the PC value to "BlinkUSBStatus". I created a text file for the results,
and chose "Dec" format. I set the width as 2 since the variable is an
integer. I am using my USB project, which is modified from the USB FS
Demo, and the "ledcount" simply runs from 0 to 9999 as a delay for
blinking status LEDs. When I click on "Apply" it tells me that the
synchronous stimulus was applied successfully, and it also clears the
content of the text file. When I run the simulation and stop after a
second or so, or upon a breakpoint, the file shows a succession of integer
values from 0 to 9999.

I was unable to get a trace on the WREG register or LATB, but I was able
to see the PORTB register.

If you want to update the trace on a PC that is not named in the drop-down
list, you can use the disassemby listing to find the hex value of the PC
you want, and enter that.

It seems that it is best to set up separate files if you want to trace
more than one register, but a single file does work. It just adds the
second trace at the end of the first.

HTH,

Paul

Hi Paul thanks, that is encouraging. I'll try it and see how I go.

 

[K Ludger]

Terrorbytes? Are they that scary?

I dunno, but the other day I misread a posting titled Multisim as Muslim

PS - it's rumoured that Al Qaeda are placing explosives in tins of
Alphagetti Spaghetti, there are fears that it could spell disaster.

 

[Frithiof Jensen]

It might be a "simple" thing.

HeHe - why not cut the bottomfeeding and go straight to ARM7?

The CPU performance is vast, vast overkill if a PIC will do the job BUT the
ARM's are nevertheless relatively cheap, multi-sourced and the tools are
good and plentiful.