Feasibility of Capturing Data read by BDM to file

[YeOldeBDM]

With the true time simulator, you can add various expressions to the data window and put the data window into periodic refresh so that all the expressions in the window are updated once per period. This is handy. Is there some API or some other method to append each snapshot into a file? 

Basically we are starting SQA on a project, and have opted to dump all the data we want to analyze out of a spare UART and into a PC for post processing. But this is still kind of intrusive for CPU cycles and memory usage -- I was just wondering if there was a way to capture the  contents of memory locations automatically, periodically to a file.

We are using CW 3.1 for HCS08 but are amenable to upgrading.

[CrasyCat]

Hello

There is no way to periodically send content of memory location automatically to a file.

I am afraid anything you would do achieve that will be intrusive anyway.

CrasyCat

[Alban]

Hi Cat,

I've been thinking about that... and might have a solution. A bit fastidious though.

With the debugger command line, you can execute batch files.
If we have a batch file executing a dump of the memory location and looping on this. (DB function)
If we have specified a file to save what appear in the command window (Log file exists)
Then we have a log file with the memory content.

If, on top of that, we have a small script (PERL) that strips anything that is not a reply to the Display Byte command, we can get a file with only the different values of the variable.

The reading of a memory location via BDM should not be a problem for the software execution.

What do you think of my "usine à gaz" ?!
Cheers,
Alban.

[CrasyCat]

Hello

I have been thinking about that too (And that is the reason it took me some time to answer that post).

Yes you can write a debugger command file, which periodically write content of a memory area to a file on the host.

But this too will be intrusive and once the script is started you have to hit "ESC" key on your keyboard to stop execution of the script. You will also not be able to debug any more.

So I am not sure it is much better than the print on UART solution...

Anyway if you want to give it a try, I would suggest you to use following commands:

  - LF to redirect output of command window to a file

  - LOG to define which information you want to log 

  - WHILE to define the loop

  - WAIT to define the period

  - DB, DW or DL to dump value of memory to command window/file

  - NOLF to stop logging

All these commands are defined in the manual {Install}\Help\PDF\Debugger_HC08.pdf. Take a look at chapter "Book V - Commands" for a detailed description of the commands specified above.

CrasyCat

[peg]

Hi,

It appears the Simulator in Codewarrior 5.1 does not support all of the commands available in the standalone P&E product. Most notably in this case the CAPTURE and CAPTUREFILE commands which would be helpful here.

CrasyCat:

I am not sure what you mean by the intrusiveness of this operation, certainly actually writing data to a file that already exists in the PC should not impact the monitored MPU.

[CrasyCat]

Hello

writing of data will not cause intrusiveness, but you need to read them first on the running board. Depending on the amount of data you wish to read, this might be intrusive.

Am I wrong?

CrasyCat

[peg]

Hi CrasyCat,

My understanding of the "non-intrusive" background commands is that they are actually intrusive, just not very much. The amount they intrude depends on many factors, one of which is the amount of data.

My experience is that the level of intrusiveness is far more than what Freescale claims. I have not investigated it fully however and am mainly just trying to solicit other users comments.

[Alban]

Hi Peg,
You sollicitated my comments.

The BDM block guides should indicate when the BDM module needs to "steal" a clock cycle from the application.

I think the probable mix-up is that when you use CodeWarrior debugger and more importantly the "Memory" window, the amount of information refreshed is not just one byte.

I advise you to tick the "View Protocol" box and you will see that, even when there is not much to do, the cable stays fairly busy. That activity can be limited by closing the memory window of the debugger (all of them if several are opened).

Also, the debugging cable has its influence.
If you were taking the TBDML with a stand alone software, you could verify what is happening because nothing would try to talk in your back

Alban.

[peg]

Hi Alban,

That is exactly the sort of comment I was hoping to solicit.

I was not using Codewarrior when this caused a problem and it was a debugging session on-site at the client when the problem occurred. So the issue was not investigated at the time and has only got a cursory glace since. I had suspected something like this and will try the setting in Codewarrior to check it out one day then take a look at P&E. Thanks.

BTW I recently mentioned I had an issue with the GT16A SCI not overriding the GPIO set as output when enabled. I looked into this recently and I can't reproduce the fault.