开云体育

Chuck,

I've been using all sorts of LAs since the beginning of 90s in the reverse engineering for the systems with scarse or no technical documentation. Simply at the start I had my own home built machine initially based on Intel FlexLogic ICs (they had the fastest clock rate in 1993) then switching to Altera FLEX/APEX families. Then at the beginning of 2000s HP/Agilent LAs with a deep memory became available at the bargain prices. I talk mainly about the arcade machine HW (as this role goes I analyze the chipset architecture in details and re-produce its functional analogues for the FPGA/semicustom IP implementation) which are not the simple uP based HW (Tek is a such example). So, I know something about the reverse engineering bringing the concrete examples ;))

Everyone in the embedded "professional" hacking knows IDA. This is not a panacea as a cross-platform disassembler, but almost and certainly the best of all. But since there is a lot's of the dynamic code in the FW (especially when ppl translating from C++), which can't be analyzed statically (by the disassembler), this runtime can be only analyzed on the working maching by using the LA even without any built-in inverse assembler. So the synergy of both are required to understand the code architecture. Getting the architecture, control and data flow and symbolizing the source is the most important steps. Also we shouldn't forget that the source can be actually compiled by not a very optimal compiler generating the spagetty code.
From all the above, the current example (Tek 6802 base platform) is quite simple, HW is all documented and it can be analyzed statically. But due to the code volume superimposing the calls will be necessary and there the LA will be undispensable.

Back to the oscilloscope, I've got 2445a CAL01 re-calibrated. This time I got it right (digital scopes unfortunately are quite useless). Still CAL02 gives the LIMIT error. But what I also noticed is that when I put the time cursors to the 1st and 11st vertical line the displayed frequency/period gives the precise value in seconds. However, it seems that when I just put them one division apart or a few, then I do have the error in the displayed delta T. Negative if both cursors are to the left from the center and positive when both to the right. It seems like there is a problem with the DAC linearity or something in its path.
IMHO this kind of error then hits back in CAL02.

What do you think?

Thank you again and all the Best,

Maxim

On Sat, 13 Oct 2018 09:55:50 -0400, you wrote:

I have been designing and debuging embedded systems for more than
40 years. I started with the 8008, and have designed and programmed
hardware for the 8080, Z80, 8085, 8086, 80188, 80186, ..., 68000, 68010,
PIC, ARM, ..... Believe it or not, but they are all substantially similar,
some a little more similar than others.

However, whenever anyone tells me that a Logic Analyzer, with an internal
disassembler probe, will ease the job of understanding anything, I know
immediately that they don't know what they are talking about.

The state of LA disassembler probes never reached a point where useful
work could be done, and are in fact a tantalizing way of wasting money.
It seems like it should be possible, was sold as the software engineers
panacea, but it never is.

There are some situations where the LA can be of use, but mostly for
tracking specific events under specific conditions, IMHO.

The largest problem is that the disassembler probes for given microprocessors
always lags the deployment of those microprocessors, and the fast evolution of
new processors means that the art is always running away from your investment
in probes.

Now for the 6800 and such, you could find the most up-to-date probe,
so that becomes less of a factor for that generation of processors,
I'd think.

A far better way of understanding an assembly program is to use a
good disassembler, that allows you to use your own labels for data and
jump addresses, and it is generally free. Plus, the software interface to
the hardware processors is surprisingly slow to change, and simple and
cheap to adapt.

Hmmm, got one for the 6800 series? I have core images...

Software emulators, debuggers, and disassembler/decompilers, have largely
supplanted the disassembling Logic Analyzer, and they did so back in the days
of the Data General Eagle, and DEC's VAX..

I don't think anyone was recommending using 6502 tools on a 6802. I think
it was simply either someone showing a parallel, or mistaking my mention of
the 2465's 6802, for the more famous "02" processor the 6502.

IIRC, the 6802 did more integration of the RAM into the processor. I
think that the DM5010 uses one as well.

Harvey

-Chuck Harris

maxim.vlasov@... wrote:

6802 shares the 6800 instruction set, however for the inverse assembler for HP/Agilent 165xx, 166xx and 167xx still a different adapter is required due to the slightly different bus timing (or one can be made by using a simple 5V tolerant CPLD). Mostek/WDC 650x & Motorola 680x are completely different animals architecture wise.
The TASM PC (for DOS) cross assembler can be used to compile and link the code natively for 6802/6800. IDA disassembler will re-create the disassmbled code to the level of the original source (or sometimes even better documented). HP/Agilent INVASM will disassemble in real-time all the event driven routines, for example interrupts, insitu on the running oscilloscope.
By disassembling and recompiling the original source (disassembly done automatically by IDA) the generated ELF (embedded linker file with symbol data) can be loaded into the HP/Agilent 16505A or Agilent 167xx software analyzer suite to display the statistical distribution and recurrence of the service routine calls. This sometimes very handy to analyze the real-time FW. I've done a few projects in the past for 68040/PPC in that way.

IMHO, there is no need to complicate the life with 6502 tools since they'll provide no help with 6800.

On Sat, 13 Oct 2018 01:47:20 -0400, you wrote:

Or, "Square Wave".

To be a bit pedantic, to me, square wave doesn't talk about the
levels, so where's 0 and where's Vmax...?

bet there's lots of opinions on that one.

Harvey

-Chuck Harris

Harvey White wrote:

On Fri, 12 Oct 2018 16:22:55 -0700, you wrote:

A useful term is "pulsating DC", or perhaps unipolar pulses, if you
wish.

Harvey

On Sat, Oct 13, 2018 at 08:40 AM, <maxim.vlasov@...> wrote:

6802 shares the 6800 instruction set, however for the inverse assembler for
HP/Agilent 165xx, 166xx and 167xx still a different adapter is required due to
the slightly different bus timing (or one can be made by using a simple 5V
tolerant CPLD). Mostek/WDC 650x & Motorola 680x are completely different
animals architecture wise.
The TASM PC (for DOS) cross assembler can be used to compile and link the code
natively for 6802/6800. IDA disassembler will re-create the disassmbled code
to the level of the original source (or sometimes even better documented).
HP/Agilent INVASM will disassemble in real-time all the event driven routines,
for example interrupts, insitu on the running oscilloscope.
By disassembling and recompiling the original source (disassembly done
automatically by IDA) the generated ELF (embedded linker file with symbol
data) can be loaded into the HP/Agilent 16505A or Agilent 167xx software
analyzer suite to display the statistical distribution and recurrence of the
service routine calls. This sometimes very handy to analyze the real-time FW.
I've done a few projects in the past for 68040/PPC in that way.

...

Actually, the 167xx doesn't always need a special adapter. There's a good thread on HP/Agilent disassemblers here:



In post #3 in that thread there's an example of using a 16702B logic analyzer to probe a 6802 processor using flying lead probes directly to the processor pins (no adapter). The thing being probed was a Tek 2465.

On the 2445A/2465A and 2465B/2465B, Tek uses bank-switched memory, making it even more fun to untangle the code. The 2465 does not have bank switching. (Maybe IDA handles bank switching?) If someone wants to head down the disassembly path, here's some info on how the banks are handled, specifically for a 2465A, but I think the B series is the same:



I've done some disassembly of the code along with real-time tracing to figure out how some things work. It's time consuming and some of the code seems a bit hack-y as it was ported from one platform to the next.

-mark

Harvey White wrote:

The state of LA disassembler probes never reached a point where useful
work could be done, and are in fact a tantalizing way of wasting money.
It seems like it should be possible, was sold as the software engineers
panacea, but it never is.

There are some situations where the LA can be of use, but mostly for
tracking specific events under specific conditions, IMHO.

Indeed, but I find that the LA disassemblers are problematic. It is difficult
to tell with a piplined processor whether the memory reads you are processing
are reading data, or reading instructions. Without a probe specific to the
processor that can make those determinations, you are just looking at
data translated to assembler mnemonics... not useful. The 8086 was the first
commonly used microprocessor to suffer this problem... and solution. Intel
included extra pads that brought out pipeline tracking information for emulators
and logic analyzers.

Tracking specific events under specific conditions is where a LA shines.

The largest problem is that the disassembler probes for given microprocessors
always lags the deployment of those microprocessors, and the fast evolution of
new processors means that the art is always running away from your investment
in probes.

Now for the 6800 and such, you could find the most up-to-date probe,
so that becomes less of a factor for that generation of processors,
I'd think.

Possibly, most of the older processor's pods have been long since scrapped,
but some are certain to still exist.

I just ditched some 6502, Z80, and 8085 emulators... They probably are still
available from the recycler if anyone is interested.

A far better way of understanding an assembly program is to use a
good disassembler, that allows you to use your own labels for data and
jump addresses, and it is generally free. Plus, the software interface to
the hardware processors is surprisingly slow to change, and simple and
cheap to adapt.

Hmmm, got one for the 6800 series? I have core images...

A couple, actually. Sourceforge, and github are littered with them,
particularly the 6809, which is an upfeatured 6802 used in the automotive
industry.

PHK, Poul-Henning Kamp wrote a nice one that actually analyzes the code
by executing it. He used it to disassemble the code in some HP counters.

...

IIRC, the 6802 did more integration of the RAM into the processor. I
think that the DM5010 uses one as well

Tek tended to use the 68B02, which is a 6802 without the internal RAM.

-Chuck Harris

On Sat, 13 Oct 2018 16:05:14 -0400, you wrote:

Harvey White wrote:

<snip>

The largest problem is that the disassembler probes for given microprocessors
always lags the deployment of those microprocessors, and the fast evolution of
new processors means that the art is always running away from your investment
in probes.

Now for the 6800 and such, you could find the most up-to-date probe,
so that becomes less of a factor for that generation of processors,
I'd think.

Possibly, most of the older processor's pods have been long since scrapped,
but some are certain to still exist.

I just ditched some 6502, Z80, and 8085 emulators... They probably are still
available from the recycler if anyone is interested.

I probably would have liked the ones for the 8085 and the 6502, just
because. Every once and while, I need to look at some of those old
ones. Right now it's the 6802 that I need to look at.

A far better way of understanding an assembly program is to use a
good disassembler, that allows you to use your own labels for data and
jump addresses, and it is generally free. Plus, the software interface to
the hardware processors is surprisingly slow to change, and simple and
cheap to adapt.

Hmmm, got one for the 6800 series? I have core images...

A couple, actually. Sourceforge, and github are littered with them,
particularly the 6809, which is an upfeatured 6802 used in the automotive
industry.

I found a few, they want DOS.

I have one that I wrote that runs under windows and is gui driven.

PHK, Poul-Henning Kamp wrote a nice one that actually analyzes the code
by executing it. He used it to disassemble the code in some HP counters.

Hmmm, some people want money for those things, not that I begrudge him
the income, but I tend to go to open source.

That's what mine does, although I get tired of writing tools to make
tools....

...

IIRC, the 6802 did more integration of the RAM into the processor. I
think that the DM5010 uses one as well

Tek tended to use the 68B02, which is a 6802 without the internal RAM.

The one in the DM5010 isn't, I think, and actually has internal RAM.
For analysis cases, all it does (of course) is to change the location
of some of the RAM.

Harvey

-Chuck Harris

There are many disassemblers that actually emulate the target
code to determine the exact way it operates... all in software.

CAL01 doesn't have much to do with CAL02.

Which attenuator settings give you the RANGE error when running
CAL02?

-Chuck Harris

maxim.vlasov@... wrote:

PHK is an open source legend. His disassembler is available
for free on github.

PHK wrote the NTP routines for openbsd.

-Chuck Harris

Harvey White wrote:

On Sat, 13 Oct 2018 16:05:14 -0400, you wrote:

...

PHK, Poul-Henning Kamp wrote a nice one that actually analyzes the code
by executing it. He used it to disassemble the code in some HP counters.

Hmmm, some people want money for those things, not that I begrudge him
the income, but I tend to go to open source.

That's what mine does, although I get tired of writing tools to make
tools....

...

IIRC, the 6802 did more integration of the RAM into the processor. I
think that the DM5010 uses one as well

Tek tended to use the 68B02, which is a 6802 without the internal RAM.

The one in the DM5010 isn't, I think, and actually has internal RAM.
For analysis cases, all it does (of course) is to change the location
of some of the RAM.

Harvey

-Chuck Harris

Hi Maxim,

The normalizer is just a resistor and a trimmer capacitor
in parallel, but in series with the center conductors of
a male and a female BNC connector. It is built in a little
Pomona box.

You can do the same thing with a scope probe, using the
probe's trimmer capacitor to square up the waveform on
one channel, and the C205 to square it up on the other.

I doubt it needs adjustment, assuming that you haven't moved
it already.

That CAL03 throws a LIMIT on CH3 and 4 makes me even more
certain that your problem is your generator.

-Chuck Harris

maxim.vlasov@... wrote:

To be more concrete I've thrown to IDA the 2465a ROM files. 160-3302-09 & 160-3303-09 are the part number downloaded from here:


The code structure is quite interesting. The bank switching routines are in the first 2K RAM working area. I've quickly found the voltage reference setting routine:
/g/TekScopes/photo/74577/22?p=Name,,,20,1,20,0

See the comments in the code. The 0xAC=172d code thrown in the DAC sets the reference voltage of 1.36V:
1ma*(4095-172)*4/4096=3831uA. Solving for x=TP2421 voltage:
x*14.2KOhm/13.0KOhm + 681Ohm*(4095-172)*0.004A/4096 = -x
x=(4095-172)*0.004A/4096*681Ohm/(1Ohm+14200Ohm/13000Ohm) = -1.247V

The above assumes that the DAC is calibrated for the 1mA reference current.

Here are some other examples of the DAC and the counter access:
/g/TekScopes/photo/74577/21?p=Name,,,20,1,20,0
/g/TekScopes/photo/74577/20?p=Name,,,20,1,20,0

The code is complex in structure due to the ugly banking implementation. There are similar sections in all four 32K ROM pages. DAC is accessed all over the place in byte fashion and also by direct 16 bit X or even S register store. The DAC work area in the first 2K of RAM is also used heavily and many locations are duplicated.

If completely stuck, then I'll try tracing the LIMIT error, but looking just at the ADC routine complexity (uses almost 200 bytes of various runtime data to do the conditional branching) likely it will consume all the time for several months...

Thank you, Chuck,

I haven't touched the capacitors yet. I've tried all 3 AWGs and got the same result. CAL01 had to run again this time with 7834a, since the steps with the extenal DSO scope were not aligned correctly. Now it's fine, but still LIMIT error. I'll try using the high resolution HDO6034 scope at work to check the AWG output before connecting to 2445a in CAL02. But I can assume that it will be fine since all the equipement at work is fresh out the calibration lab.

On Sat, 13 Oct 2018 18:45:03 -0400, you wrote:

PHK is an open source legend. His disassembler is available
for free on github.

THe internet is being particularly obtuse tonight, or at least
duckduckgo is...

Have a name I should look for? Perhaps that'll help.

Sorry, and thanks.

Harvey

PHK wrote the NTP routines for openbsd.

-Chuck Harris

Harvey White wrote:

On Sat, 13 Oct 2018 16:05:14 -0400, you wrote:

...

PHK, Poul-Henning Kamp wrote a nice one that actually analyzes the code
by executing it. He used it to disassemble the code in some HP counters.

Hmmm, some people want money for those things, not that I begrudge him
the income, but I tend to go to open source.

That's what mine does, although I get tired of writing tools to make
tools....

...

IIRC, the 6802 did more integration of the RAM into the processor. I
think that the DM5010 uses one as well

Tek tended to use the 68B02, which is a 6802 without the internal RAM.

The one in the DM5010 isn't, I think, and actually has internal RAM.
For analysis cases, all it does (of course) is to change the location
of some of the RAM.

Harvey

-Chuck Harris

You could try:

<>

-Chuck Harris

Harvey White wrote:

On Sat, 13 Oct 2018 23:11:02 -0400, you wrote:

You could try:

<>

Thanks, downloading and I will evaluate it.

Wouldn't have thought of that one. Mine's written in Lazarus Pascal,
which is my preferred "goto" for windows style programming.

For microprocessors (ARM), it's C (because a certain company does not
generate a C++ project at all).

Harvey

-Chuck Harris

Harvey White wrote:

On Sat, 13 Oct 2018 18:45:03 -0400, you wrote:

PHK is an open source legend. His disassembler is available
for free on github.

THe internet is being particularly obtuse tonight, or at least
duckduckgo is...

Have a name I should look for? Perhaps that'll help.

Sorry, and thanks.

Harvey

After the code disassembly, seeing that the FW writes 0xAC to the DAC for the U2521 channel 0, the reference voltage on TP2421 is supposed to be 1.24692V
but I measure TP2421=-1.2524V, which is 4392ppm lower. I wonder how accurate it supposed to be.

Try to socket tomorrow U2420 and measure the resistors R2422, R2421, R2521 & R2520 separately.

One way of attack would be by using the Logic Analyzer to find the corresponding to CAL02 routine code and understand it in the details (I'm moving forward with IDA disassembly).

The other - a bit more simplistic - by using the LA to decode/demultiplex the digital sequence at the input of the DAC and multiplexers. It's assumed that in the static o-scope operation, the levels produced by the multichannel DAC are static. Hence, I could compare the code written to the DAC and the de-mulitplexer against the voltage setting at the output. For that there is Agilent 16702a+16534a+16710a setup on my bench. However, I believe that once the voltage settings will be proven static after de-multiplexing, the high resolution voltmeter will be required to find whether the output corresponds to the input digital settings.

Also even more interesting exercise can be done to analyze the performance of the multichannel successive approximation ADC. I try connecting the LA to the DAC, U2510 comparator output (to be socketed too) or even the port 3 input buffer U2220 and the multiplexer controls for U2401, U2601 & U2501. Again, assuming that the input to the ADC at the runtime is static for some signals, use those to find the end of conversion value (also this would help understanding the successive approximation FW routine).

On Sun, 14 Oct 2018 at 04:42 <maxim.vlasov@...> wrote:

After the code disassembly, seeing that the FW writes 0xAC

Funny, this is two codes off from my derivation of the voltage, from
assumed 1.36V & -1.25V references. This is a 12 bit DAC, do you ever see
the remaining nibble written?

to the DAC for the U2521 channel 0, the reference voltage on TP2421 is
supposed to be 1.24692V
but I measure TP2421=-1.2524V, which is 4392ppm lower. I wonder how
accurate it supposed to be.

R2520/2521 are both specified 0.5%, and so is R2013, although that one is
additionally specified for low TC. Assuming R2013 and R2521 track
reasonably in temperature, given the trimming you should be able to get
well under 0.5% accuracy.

Now, the DAC calibration procedure is actually against J119 pin 13, which
looks to be the DLY REF 0 output from the A5 board. Maybe you have leaky
S&H caps or something dragging on that line, pulling your calibration to
one side? Note that the DLY REF outputs are pretty high impedance. If you
have something dragging on the line, you'd see U2620B railing to one side
or the other...

Siggi,

In the given code snippet, the X register is 16 bit and the full 16 bit write is performed. The DAC port has two bytes: 0x87F for the MSByte and 0x880 for the LSByte. The X register is loaded with the 0x00AC absolute value.
As we look at the bits of the MSByte (0x87F), the bit 7 is the interrupt interval counter/timer reset control. The bits 4-6 are the channel code selects for the demultiplexer.
BTW, as you can see in some other examples, the DAC is accessed in parts. But I've seen a few places (could only find it by LA) where the DAC is addressed indirectly and the Tek programmers even use the stack pointer as the register to write the data into the DAC!!! The code is scarce indeed and was written different programmers.

And you are exactly to the point, IMHO, that if I follow the DAC calibration procedure, the DAC is railing indeed to the right side or even just a bit smaller. Can put the delta cursor over the 11th vertical division or a bit further right! Therefore I also assumed that there is something weird with the DAC and something is dragging the line.
I'll measure all the resistors and levels with 6.5 digit multimeters and re-calculate the values and voltages. Logically if this is not the resistors then either the caps or the DEMUXers and/or OPAMPS.
Even a small leakage in the de-muxer will create the voltage offset.
So the goal is check the DAC reference circuit in the first step, since now the digital part of the circuit behavior is known.

I little type: instead of "Can put the delta cursor over the 11th vertical division or a bit further right!", please read "I can't put the delta cursor over the 11th vertical division or a bit further right!"

"I little type" -> A little typo

bloody autocorrector!

I have always been afraid to look into the ROM on these scopes.

I like to think nice thoughts of Tektronix, but there really is
no excuse for the rough edges the "A" and "B" scopes have...

Maybe you will be the one to fix the warts that Tektronix's
bean counters forced engineering to leave behind?

One thing, if you can move the cursor past the bounds of the graticule,
you have found your problem.

That can only really happen if the vertical/horizontal amplifiers
are not calibrated to match up with the graticule lines on the
CRT.

If the horizontal/vertical amplifiers are not calibrated to match
up with the graticule lines, the vertical attenuator steps, and the
horizontal time/div settings will always give LIMIT readings, which
is what you are seeing.

Go back and do the CRT ADJUSTMENTS section, CAL 01, and CAL 02 again.

The CRT ADJUSTMENTS section is the basis for everything to do with
showing pretty green lights on the screen in a linear undistorted
fashion.

If the cursors overrun the horizontal graticules, you have likely
botched the first step of CAL 01.

If the cursors overrun the vertical graticules, you have likely
botched the first step of CAL 02.

Think through how you do them again, and ask questions if something
confuses you at all. If you get these steps wrong, you have no hope
of ever getting rid of the LIMIT error.

-Chuck Harris


maxim.vlasov@... wrote: