need help interpreting code for a 68HC705

[Damon]

Hi all.

I've inherited a wireless daq device which uses a 68HC705C8 chip.  I need to determine the limiting factor to the sampling rate of my overall system (hardware and software), so I'm trying to figure out if there's something in the code that controls the data in / data out conversion rate for the microcontroller.  I was told that the answer probably lies in the first few lines of code:

S10F1FF402C002C402AA02BF02C1012103

S1230100201F090A0B08001514131211100100B40012000900060004800399030002920278

S1230120409B9C4FC71FDFAE507F5C26FCA621B702A6E5B7063F003F013F04A6FFB705B694

Is there someone out there who can help me figure this out?  As a mechanical engineer, this is far out of my range of expertise so any help would be greatly appreciated.

Damon Cassisi

Prosthetics Research Study

Seattle, WA

[Wings]

I can help you interpret the code you have posted but I don't think you will like it. The code you have there doesn't tell you much at all.

The first line is simply the interrupt & reset vectors for the program.

The second line is data, not instructions. I have no idea what it means or what it is for since you don't have the code that uses the data. I say that it is data because disassembling that line results in code that makes no sense at all.

The third line is part of the power-on initialization code, and it goes like this:
0121 SEI
0122 RSP
0123 CLRA
0124 STA $1FDF (OPTIONS REGISTER - THIS DISABLES THE AUXILIARY RAM IN THE C8)
0127 LDX #$50 (RAM ADDRESS)
0129 LOOP: CLR 0,X (CLEARS RAM FROM $50 TO $FF)
012A INX
012B BNE LOOP
012D LDA #$21
012F STA $02 (PORTC)
0131 LDA #$E5
0133 STA $06 (PORTC DATA DIRECTION REG)
0135 CLR $00 (PORTA)
0137 CLR $01 (PORTB)
0139 CLR $04 (PORTA DATA DIRECTION REG)
013B LDA #$FF
013D STA $05 (PORTB DATA DIRECTION REG)
013F LDA ????? -END OF CODE

So you're gonna need a bit more code than this in order to be able to tell what's going on.

I know this didn't help much, but I tried.

[Damon]

I have the complete machine code, but unfortunately was never given the source code to go with it.  I really appreciate your attempt...I'll post the complete code at the bottom of this page if you're inclined to give it another go.  It's 33 lines of text - hopefully not too long for this forum.

The maximum speed of the hardware itself seems to be limited by the A/D chip, an LTC1285 with maximum sampling frequency listed at 7.5 kHz.  It's being fed a multiplexed signal (six channels out of an analog load cell) and passes the digitized signal to the microcontroller.  The signal is eventually sent out through a Bluetooth wireless serial cable to a computer running a LabVIEW vi.

I'm trying to figure out what ultimately governs the sampling rate for the whole system.  The software sends a samples-per-second number through the serial port to the hardware, but that's where I start to get very confused because I don't know if that, in turn, controls operations throughout the circuit or if the microprocessor is running on its own set of rate instructions.  I have a part-time electronics guru available, but he doesn't know this microcontroller and suggested I float the code to someone who might be able to interpret it.  He figured it might show up in the first three lines, but it obviously hasn't.

Here's the complete machine code:

S10F1FF402C002C402AA02BF02C1012103 S1230100201F090A0B08001514131211100100B40012000900060004800399030002920278 S1230120409B9C4FC71FDFAE507F5C26FCA621B702A6E5B7063F003F013F04A6FFB705B694 S1230140001C02B753A40797D60107B70D3F0EA626B70F14025FD60102E78127035C20F65E S1230160BF511E7EA612B70AB60B0653081B0216061C0A1C5008530218500A5306A650B794 S1230180521A50CD0214B610B6113D13B61AABB4B716B61BB717A640B712C6010FB792C6B0 S12301A00110B7939A0D5053015004160F1E0F5F9B17023F0C0F0BFDB60CE766E681B70C41 S12301C00F0BFD16029AB60C646646E76E5CE68126DF005004160F1E0F0B5003CD021D0E65 S12301E00FFDAE0FE666E7565A2AF9B652B78A3F540D10FD17500650AC20FB1A0217061D5C S12302000A8F0D50FD1B02CD0214CD021416061C0ACC01A54F5F5A26FD4A26F9813F91BEAD S123022091E666A40FB78BE66EB78CCD025E9FBE91E76ECD025E9F48484848BE91EA6EE767 S12302406ECD025E9FBE91E766B68C48484848BE91EA66E7663C91BE91E68126C2813F8EBD S1230260A6A0B78DA60D2011A6013D8D2B0B4C388E398D2B04A11126F5B78FB68BBE8C3F81 S12302808B3F8CB7909FB08E97B690B28D240DB7909FBB8E97B690B98D98200199398C39F1 S12302A08B348D368E3A8F26DA810D13143D17B617BB9397B616B992B716BF171650808086 S12302C09DCC0121B610A5202703CC0398BE8ADC02D2085019BE54E656A1FF26014AB711E3 S12302E05CBF54B3512506A6ABB78A125080BE54E65E486956486956E656A43F3D542602AC S1230300AA40B711A637B78A80BE54E65EA43FB7115CBF54B3512505A6B4B78A80A61CB757 S12303208A80BE54E65644444444CD04CDA660B78A80BE54E656CD04CBA66CB78A80BE541D S1230340E65E44444444CD04CD09500CA67FB78A80BE54E65ECD04CB5CBF54B3512507A625 S1230360A2B78A125080A699B78A80A609B711B652B78A80A60DB711A6B4B78A80A6FFB782 S123038011A6B4B78A801F0FB652B78A3F54145080A626B70F3F8A80A40E2703B61180B68B S12303A011A47FB7803D7F2A0BAE17D103EA27515A2AF880A137222EA130252AA407270BC1 S12303C0484848BA7FBE7EE7763C7E3C7FB67FA1082512BE7EBF516F815AB676E781E6765F S12303E05A2AF91E7F801E7F20BF42444853462B2D29283031323334353637384750524ACC S12304004BDE0407DC041E00070E15181B1E2124272727272727272727383D404346A600A3 S1230420B7521B5080A650B7521A5080A660B7521B50801150801050801002801102801EDD S123044002801F0280B680A40F4897D6010FB792D60110B793803F7E3F7F801D50801C5079 S1230460801950801850800001020304050607080910111213141516171819202122232483 S1230480252627282930313233343536373839404142434445464748495051525354555696 S12304A0575859606162636465666768697071727374757677787980818283848586878812 S11D04C08990919293949596979899A40FA10A2B04AB372002AB30B7118113 S9030121DA

Thank you - Wings and everyone else!

Damon

[Wings]

Damon,

You don't ask for much, do ya?

I put your code into Codewarrior and let it disassemble the entire thing. The code was either written by a million typing monkeys or is compiler-generated. It's tough to figure out, but I am able to find the major loop in the code, where it first writes & reads via the SPI port (I assume to the A/D converter) then does a LOT of junk with the serial port, then appears to wait for an interrupt from the serial port, then delays a fixed amount of time, then repeats. The fixed time delay is dependent upon the clock frequency driving the chip, and is: 786432*(4/XTAL) , where XTAL is the frequency of the crystal connected to the C8. I'm guessing the crystal is 4.1943 MHz which is common for something using standard baud rates, so your delay would be around 0.75 seconds if this is true. If this delay is the only delay there is then the only way to change it would be to change the code.

FYI, the delay code (executed twice) is:
CLRA
CLRX
L1: DECX
BNE L1
DECA
BNE L1

[Wings]

OOOppps.

That formula in my previous post is off by a factor of 2.

Make that 786432*(2/XTAL) rather than 786432*(4/XTAL).

Means your delay is .375 sec, not .75 sec.

[Damon]

The crystal frequency is actually 3.6864 MHz, and the baud rate specified through LabVIEW for the serial port is 115200 (=3.684e6/32 as stated).  From the corrected formula, it appears my delay is 0.427 seconds but I'm not sure how to fit that number into what I've observed.

My electronics guy stopped by with a scope last night, and we monitored a few signal frequencies.  When I request a 400 Hz sampling rate in LabVIEW, I get 400 Hz (measured at both the MUX signal output and the serial chip signal input pins).  When I request a 200 Hz sampling rate, I get 200 Hz.  When I request a 240 Hz sampling rate, I get 200(!) Hz.  When I select a 500 Hz sampling rate, I get 250 Hz.  The original vi programmer played a lot of games with the user-specified sampling number before sending it out the serial port, so I suspect that's got a lot to do with what I'm seeing, but the selectable timer interrupt you mentioned has me curious.  I'm going to dink around with the vi and see what happens.

I'm sorry to dump all that code out there like that - btw, I'd bet on the million typing monkeys - and I'm also sorry about the missing beer shipment, peg.  I tried to model the DAQ device with an equivalent fluid system in order to understand it better.  I started with coffee as my working fluid, but here in Seattle they frown upon that sort of usage.  In fact, as I was starting the experiment, three people driving by in their hybrids interrupted their mobile phone conversations long enough to stop and yell at me so I had to switch to the beer I was going to send you.

I didn't realize when I started this thread the magnitude of what I was asking, but definitely do appreciate the extra effort you have all put in for me.

Damon

[peg]

Hi Damon,

The 3.6864MHz crystal makes sense with the standard 115200 baudrate and also now means that on power up you have 10Hz sampling, then you can select from 100Hz to 800Hz in 100Hz steps from the serial command. The wrong selection you have would appear to be an error in the PC rather than in the C8.

P.S. Its morning in Sydney now so I have gone the other way, swapped the beer for the coffee.

BR Peg

[peg]

Hi Damon,

You have not told us what frequency crystal is on the C8.
The serial port and the SPI (interface to the LTC1285) are running at the xtal/32.

The AtoD is rated at 7.5ksps which is 120khz at the interface for 16 bit transfers.
So I presume your crystal is less than 3.8MHz.
That's as far as I have gone as the case of beer you sent hasn't arrived yet...

BR Peg

There is also a timer interrupt selectable by the serial port and uses a lookup table to select 1kHz, 875Hz, 750Hz, 600Hz, 500Hz, 375Hz, 250Hz and 125Hz.

Getting thirsty...

Message Edited by peg on 04-22-200601:02 AM

[farebrog]

Do you have the source code and schematics for the project? The 3 lines of code you have posted are the machine code that is used to program the micro. If you have schematics you can look up the a-d or d-a chip specs to determine the max throughput of the hardware. The software throughput will be dependent on your source code and processor speed.

[rhinoceroshead]

It is possible to disassemble the .s19 file you have provided into assembly code.  I know I've seen documents from this website that explain the .s19 format.  I believe that the 2 bytes immediately following the S123 is the address in memory being programmed to and then there is a frame of data, followed by a cyclic redundancy check.  There may even be software that disassembles an .s19 file for you somewhere, but I've never needed to do it.  From the assembly you could probably figure out what the program is doing if you were desperate.  But the best way to go is to just get the source code.  I can't imagine you would have access to the .s19 file without also having the corresponding .asm or .c file to go with it.

[peg]

Hi Damon,

If you have codewarrior you can load your s19 file into the decoder.exe programme in the progs directory to disassemble it. But then you have to go through all the fun of finding the data segments buried in the code etc etc.

You could search for the address of the register you  are looking for though then concentrate on those areas. It might pay to search the s19 file for the address first!

BR Peg