SainSmart DDS120 & DDS140 USB Oscilloscope

[doctormord]

Doctormord
1) Improving performance of the input stage. Putting temperature variability to one side for a minute, I think that this is the key curve for a CD4052 is shown at attachment
I note two things.  Running the device at a higher voltage reduces both resistance and non linearity.

We don't have higher voltages available here. (Still unknown, how the negative voltage is generated)

In principle, the higher supply voltage should not cause a problem in terms of analogue inputs/outputs,  but the multiplexer select lines would need buffering.  So that is the quality approach
Secondly at 5V supply, and 0-1V operating range, linearity is not too terrible and resistance comes in at 400 ohms.  This is the "do nothing" approach!

I would rather change the multiplexers to 74HCxxxx.

I am guessing you are using Cyconsole to load up the FX2 with the other firmware and then re-enumerating? If we can get that path working it is going to save a lot of development time.

Actually the firmware is loaded to the Cypress RAM when starting the software (Pulseview). The Scope enumerates with the standard PID/VID when eeprom jumper is open. So firmware-changes could be done at runtime.

(The original firmware is still in the attached eeprom)

Zigrok/Pulseview includes a tool (Zadig) to change the driver for the Cypress on the fly. (WINUSB, libusb, libusbk.. )

Ganzuul,  if I am right that resistor is connected to IFCLK, which when driven by the FX2 can only take on values of 30 and 48Mhz.  So I think your aliasing explanation is right, you have 48/4

You may check if IFCLK is connected to CLKOUT somehow.

Curious, how does the ADC gets clocked?

Regarding the EZ-USB Technical Reference Manual:

http://www.cypress.com/?docID=48811

page 125, the IFCLK can only output 30/48MHz from its internal source. (I must review the trace at IFCLK and CLKOUT.)

Maybe its like:

24Mhz crystal -> PLL (48Mhz) -> /2 divider -> 8051 Core + CLKOUT [pin out] (24Mhz) -> IFCLK [pin in] + ADC_CLK (24Mhz)

At DDS120, it is not. So the ADC is running either running at 30 or 48Mhz.

[psynapse]

Hi Donut6,

Thanks again, it looks as though from the replies the install is correct

Does this command work?

Code: [Select]

wx-config --cxxflags

-I/usr/lib/i386-linux-gnu/wx/include/gtk2-unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread

If so, perhaps the Ubuntu wxwidgets package doesn't set up the include path correctly.

also

Code: [Select]

wx-config --list

    Default config is gtk2-unicode-3.0

  Default config will be used for output

  Alternate matches:
    base-unicode-3.0


But please leave it,  I will sort it after the weekend..... Your time better spent on advancing the code. 


Doctormord

I will get back to you on your observations, too little time today.  My apologies.  Only thing to note immediately, the 74HC4052 seems slightly worse in terms of resistance/linearity. From my standpoint, I would rather correct in software in the PC through a LUT.  But a redesign from scratch, I agree with you, always better to get the hardware right to start with. Weird about the negative rail generator.

[doctormord]

I actually connected CLKOUT to the CLKIN of the ADC (bypassed IFCLK) - works. Not sure if 12 or 24Mhz, but i dont see any change in samplingrate. (So even 240kHz in software shows valid data)

 

Only thing to note immediately, the 74HC4052 seems slightly worse in terms of resistance/linearity.

From http://www.nxp.com/documents/data_sheet/74HC_HCT4052.pdf

they perform much better.

[ganzuul]

How to implement -> EZ-USB TRM -> 9.2.8 Implementing Synchronous Slave FIFO Reads

From 9.3.2., i would guess, they're using EP2 or EP6 with 1024byte size (As the smallest received packets are 1k) . FLAGD is then programmed to represent a FIFOFULL state (15.5.3 ff page 223).

By that, the FIFO size could be increased up to 4k when needed (slower sampling)

The question is, will FLAGD be held "high" only as long as the FIFO is full, or has it to be reseted when it once triggered by "FIFO Full"? If so, this would mean:

ADC is sending data to the FIFO -> FIFO gets full -> FLAGD is triggered (going "high) -> this raises SLRD, so IFCLK is incrementing the FIFO pointer on each rising edge of IFCLK while SLRD is
asserted. -> Data is being sent -> FIFO pointer reaches 0x000. FLAGD is then to be cleared. For the time of data transfer, the scope is "blind".

This could be avoided if switching from EP2 <-> EP6 respectively. So one FIFO gets filled by the ADC, while the other is being sent to the host.

A totally different approach would be (9.3.4 Auto-In / Auto-Out Modes page 111 ff), with direct streaming.

This has to be clarified by someone who knows. 

O0

USB spec says all transfers are initiated from the host, which could result in huge variances to when the host polls the device. Isochronous mode decreases this variance a lot, and for our purposes iso means we require less from the 4K buffer.

EP2 can be configured to be 4x 1K, and it doesn't look like to me that there are any special considerations to this. It's just a single 4K buffer. Meanwhile in the examples I've looked at, EP6 is used for iso and they recommend 512 for iso. I'm not sure if one can use EP2 and get full bandwidth for iso, but I also don't think it's unreasonable to demand we get an entire USB 2.0 host controller all to ourselves so we don't need to share resources.

To logically couple the device to the host, I think each host -> device poll should tell the device to keep alive. Since this is an RX-only application we don't have to care about latency, so we can let big buffers take care of perceptual continuity. We won't know exactly when a signal arrived unless we code that information into one of the analog channels. I can't think of an application where we'd need to know the device time accurately though...

[psynapse]

Just briefly.

I have been digging aroung in the firmware, trying to find out more about the DDS140 94(0A) command which gives continuously sampled 240Khz data.  I have tracked down the special wavetable that is invoked only for this timebase rate (which strangely is only available when you select 1second timebase)

Coming to grips with the wavetable editor,  the FIFO read mode has 4 states, lasting 1,99,99,1 clock intervals.  And 48Mhz/200=240khz.  There maybe hardware reasons for the speed limit, and at higher rates there will certainly be USB transfer rate limits, but I shall be playing with these values to see what other timebase rates could be available (as the only truly continuous data mode for the DDS140)

In agreement with what doctormord says, this wavetable mode would see the ADC running at full speed and the fifo taking 1 sample in every 200 48Mhz clock periods.  I have no way of knowing, but it seems distinctly possible that this is the standard mode for the DDS120. Change the state periods, change the overall sampling rate.  I need to find the wavetables in the DDS120 in order to know more.

For DDS140 owners, the pattern 63h 63h only seems to appear once in the eeprom image, and these are the two 99d clock period waits in the fifo load.

The downside is that the scope software is simply not capable of handing the inrush of data. Custom display software needed.  More on Monday

[doctormord]

 

My testings with sigrok are not consistent at the moment. I thought, it should be fine to connect CLKOUT to CLK_ADC to have em running, but the readings makes no sense to me.

Mostly i get some 00 00 00 FF FF 00 FF garbage. This might be due to aliasing from the hostsides sampling frequency, as this could altered from 100k to 24M. Also the second port does not geive any results at all. Might be, that because the input multiplexer is not set valid and the corresponding output pin (FX2LP) is in tri-state. Couldn't check any further. Having another FX2LP logic-analyzer connected gives nothing valuable, as it is limited to 24M, so heavy aliasing in the results.

[psynapse]

Doctormord,

When you talk of CLKOUT, I presume you mean pin 1 on the FX2.   IFCLK on pin 75, is the usual clock as you know.  I note that both CLKOUT and/or  IFCLK can be inverted under software control and that both can be prescaled.  So even if there is no difference in frequency, there will be differences in both skew and phase between the two.  And as you rightly say,  without a logic analyiser of 250Mhz or more, you will not be able to visualize the problem.

Have you measured the frequency on the two pins?  On the DDS140 these are fixed, ie once the firmware setup routine has run, these are static values.  If this is true for the DDS120 too, and both clocks run at 48Mhz, it suggests that your explanation that the FX2 subsamples the ADC (running at 48Mhz) at a 1/N rate, and in all probability this is achieved by reprogramming the GPIF wavetable.  If both these assertions are true, then the DDS120 is already delivering maximum performance, and the question becomes one of best firmware/software to support transfer.  If IFCLK is running at 30Mhz, flipping a bit in firmware should get you the performance you seek.  (The only way the DDS140 gets "more" performance is by buffering in the ADC values at 80Mhz into SRAM and then replaying them out to the FX2 FIFO at 48Mhz.  But that extra performance is at a high price)

So I have not given much help, except to say I think your analysis is correct.

Back to the Fête

[doctormord]

Yes, CLKOUT can be scaled (:1, :2, :4), while IFCLK is fixed to 30/48MHz when used as output. CLKOUT is always the same as Core-Clock, they share the same pin/divider. I need to measure CLKOUT to see what's going on. At 48MHz, the ADC would be slightly overclocked. But if this is true, they would advertise as 100Msps.

[psynapse]

At 48MHz, the ADC would be slightly overclocked. But if this is true, they would advertise as 100Msps.

Maybe even 200Msps 

"ADC slightly overclocked" In the DDS140, and several rigol oscilloscopes the 40 meg part is overclocked at 80 or even 100Mhz.  It seems to work, although I expect badly.  The ADC is 5 bits of capacitive stages and 3 bits of flash,  I am taking this to suggest thay you might get 6 bits at 80Mhz

My 74lvc74s have arrived:- the trouble is that the are ssop (I had thought they were soic).  When I have good enough eyes to solder them,   I will measure the clock rates on the DDS140.

Ganzuul:

I have not had the time to look this weekend, but I had understood that the four buffers could be set up as a ring of four, one filling, one emptying and (in steady state) one full buffer waiting to be sent and the fourth empty buffer waiting to be filled.  I will look into it more.

[doctormord]

I checked for the clocks at CLKOUT and IFCLK, they're the same at all times. Samplingfrequency does not affect anything, so the ADC and8051 are running at 48MHz all the time. Dunno if the phase-shift is important to note. (Blue is CLKOUT, Red is IFCLK)

(Only had a Rigol 1052E unaltered avail.)

Code: [Select]

Analog Ch  State   Scale    Position   Coupling  BW Limit  Invert
CH1        On      1.00V/   40.0mV     DC        Off       Off
CH2        On      1.00V/   -2.04V     DC        Off       Off

Analog Ch  Impedance   Probe
CH1        1M Ohm      10X
CH2        1M Ohm      10X

Time    Time Ref    Main Scale    Delay
Main    Center      5.000ns/      -409.3000ns

Trigger  Source      Slope    Mode      Coupling     Level    Holdoff
Edge     CH2         Rising   Auto      DC            1.12V   500ns

Acquisition    Sampling    Memory Depth    Sample Rate
Normal         Realtime    Normal          500.0MSa   



[ganzuul]

psynapse, I think the ring buffer you described is optimal.

As for squeezing more information through USB 2.0... The best scheme I have been able to come up with is to connect the two channels, interleaving them together and setting the gain so that information from the higher-quality side of the ADC pipeline is preferred. This just means that fewer bits are wasted as noise, rather than each bit representing more sampling information.

There doesn't seem to be enough gates running at 1 instruction per cycle, 16 bit wide, to allow for better processing gain.


Other than that, I'll probably start scraping together money for the new Rigol scope! Its price/performance really appeals to me.

[psynapse]

Sorry for not replying sooner, a friend with problems came to stay.

Doctormord:
Thank you for the information.  That seems completely consistent with the idea that the FX2 simply takes 1 in N of the samples always made at 48Mhz and transfers those.

Ganzuul:
Which Rigol are you thinking about buying?

All:

I have only found a few minutes to experiment.  However I can confirm that the two bytes I identified in my earlier post are indeed those responsible for determining the sample rate.  I have changed 63h to 31h, changing the default sampling period from 200 cycles to 100 cycles (1+49+49+1).  The measured clock rate is now 480khz and wireshark shows that all the samples are presented to the PC.

The PC software does display the acquired data (very slowly) ,  but as Doctormord has already noted with the DDS120,  the acquired data arrives independently of the go commands and there is a growing backlog of data as time passes.

All this means that a small firmware modification will allow the DDS140 to function in the same way as the DDS120 when necessary, and with many timebases possible.

So now the question is generating some PC software that actually works.

I shall start looking at the DDS120 firmware now to see what zaps are possible to the timebase.

[mmark]

Donut6

Both already installed ..... the dreaded path problem then. I will look in the morning, but thanks anyway

Doctormord

Thank You. Yes, I remember somebody had a problem, but had not remembered the .bin solution.  I followed your post in order to get the hex out of the DDS140 to start with.  Very glad I did!  And now you mention it I remember a hex to bin converter somewhere in the cypress software

All
Sorry, away from keyboard this weekend , it is our village fête this weekend

I was able to compile scope.cpp after installing libglu1-mesa-dev (in addition to libusb-1.0.0-dev and libwxgtk3.0-dev) on ubuntu 14.04...

Since I only have a DDS120, I am currently trying to get it to work with that. I added a test for 0x8102:0x8102 and it is found, but I am getting an assertion "../src/common/glcmn.cpp(59): assert "IsShownOnScreen()" failed in SetCurrent(): can't make hidden GL canvas current" when starting and no GUI elements are drawn. This is in a VM, I'll try on a real PC later tonight...

Mark

[ganzuul]

Ganzuul:
Which Rigol are you thinking about buying?

***

All this means that a small firmware modification will allow the DDS140 to function in the same way as the DDS120 when necessary, and with many timebases possible.

So now the question is generating some PC software that actually works.

The cheapest one, the DS1054Z! 

Really glad to hear the DDS140 can function the same way. Have you been able to determine if the JTAG fuse is blown on the CPLD? If not, that's quite interesting. =)

Since I only have a DDS120, I am currently trying to get it to work with that. I added a test for 0x8102:0x8102 and it is found, but I am getting an assertion "../src/common/glcmn.cpp(59): assert "IsShownOnScreen()" failed in SetCurrent(): can't make hidden GL canvas current" when starting and no GUI elements are drawn. This is in a VM, I'll try on a real PC later tonight...

Mark

Starting the scope with strace, such as '$ strace ./scope' gives a lot more information about what the program is doing. It sounds very likely to be an issue with OpenGL support in the VM though.

[psynapse]

Ganzuul,

Not a JTAG expert. how do I determine if the fuse is blown and how do I get useful information.  I have a "bus pirate" which will do jtag, but what questions do I ask the CPLD (if the fuse is not blown).  And I have no idea (yet) on how to interpret the results !  Is there a "disassembler" that will give me a pseudo schematic representation of the way the logic is "wired"

Mmark,

Welcome aboard.  Yes I already have libglu1-mesa-dev installed, but no compile    Are you 32 or 64 bit Ubuntu 14.04. I run both, Perhaps you would be so kind as to post the binary .... if nothing else it will highlight what other dependencies I am missing.
EDIT:  My mistake, I thought I had libusb installed, but had failed to install the dev.   Now, like you, I get

./src/common/glcmn.cpp(59): assert "IsShownOnScreen()" failed in SetCurrent(): can't make hidden GL canvas current

And this is on a machine as real as you can get

[ganzuul]

psynapse,

I'm not an expert. Far from it. What I know is that Altera must release a complete JTAG-related description file, on request if needed, for them to be allowed to claim IEEE 1149.1 compliance. This lets you perform a JTAG boundary scan, and enumerate what I presume to be a kind of API.

There are a myriad of companies who provide the service of "code extraction". CPLDs are non-volatile, so they don't store their information in an EEPROM. Still, the companies say they can extract the firmware and apparently there have even been complaints that the fuse-blowing mechanism of the MAXII can be circumvented. - I very much doubt that these companies employ Ion Beam Workstations etc. to do the code extraction, but rather they have simply read a lot of product manuals.

There are talks, by smooth speakers with pleasant English accents, who do a good job of explaining the RE bits:



I'll see if I can find out how to dump MAXII firmwares, and report my findings.


psynapse, Mmark,

I got scope.cpp to compile and run on Ubuntu 14.01 LTS, but not capture data. I use the proprietary AMD driver. The trick was to save the Makefile that donut6 quoted into a file named "Makefile" in the same directory as scope.cpp, and run 'make scope' from the CLI.

I have the DDS120 though, and libusb isn't happy with me simply changing ven/dev ID in scope.cpp. I will have to review the discoveries made about the control codes, and what libusb expects out of udev etc. etc. strace produces a huge amount of information. Perhaps a log analyzer exists for it already...

[psynapse]

Ganzuul,

Many thanks, there is a lot of useful information in your post. I'll dig out the bus pirate and see what I can do.

Mmark,

I think we are getting the error on execution because (as it says in the glcmn.cpp source)

bool wxGLCanvasBase::SetCurrent(const wxGLContext& context) const
{
// although on MSW it works even if the window is still hidden, it doesn't
// work in other ports (notably X11-based ones) and documentation mentions
// that SetCurrent() can only be called for a shown window, so check for it

wxASSERT_MSG( IsShown(), wxT("can't make hidden GL canvas current") );

My challenge is finding out which window!

I also get several

(scope:7780): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17

warnings

BTW,  I do not know libusb, but note that the eeprom (for both the DDS120 and DDS140) store the following data in their first 8 bytes
0 0xC2
1 Vendor ID (VID) L=47h
2 Vendor ID (VID) H=05h
3 Product ID (PID) L=31h
4 Product ID (PID) H=21h
5 Device ID (DID) L
6 Device ID (DID) H
7 Configuration byte

To my mind that means that the USB code should be 0547:2131.  I cannot square that with Donut6s code, and when I have fixed my problems I will check this out. Donut6,  your code is proving really useful, could you give an idea on the VID/PID issue?

[donut6]

psynapse,

Check out page 53 of the EZ USB TRM PDF - C2 load format. Apparently, the VID/PID/DID here isn't used by most applications.

On the assertion error. This line:

Code: [Select]

    glPane->SetCurrent(*m_context);

Must be called too early. (I'm using debian/kde)

So, delete that line, and move it later on... not sure where!

Try here after Layout() is called (later on in the same function):

Code: [Select]

    this->Layout();
    glPane->SetCurrent(*m_context);

edit: and add Show() and Raise() while we are at it:

Code: [Select]

    this->Layout();
    this->Show();
    this->Raise();
    glPane->SetCurrent(*m_context);

good luck!

[psynapse]

Donut6,

yep, those code mods worked a treat.

First time I have connected the scope to my linux system, and of course you are right, it enumerates at 8312 8312

A word to the folk like me. running scope as root does not work.  I had to change the permissions in dev/bus/usb/XXX/YYY to allow myself access and the application works.
Obviously more work to do, but the fundamentals (ie the difficult bit) are done.

 Well done donut6

EDIT:
Started playing with the code and note that the 39khz mode does not acquire.  Have added a menu option for the 940A command (which is 240khz), and at first that did not work either.  That is simply explained :- the FIFO never shows full (because it is never full!).  By the simple expedient of commenting out the line
 
    if (w == 0x21) // fifo full

the software is forced to get data from the buffer, which it does! And everything works This is clearly not the right coding solution however.  In addition, if this is the way the DDS120 normally works, the software as it stands will not handle that device.

None of this should be seen as criticism:- I am delighted to get my hands on some code that works, and works under linux . As I have already said, Donut6s work is a really sound foundation on which to build. Bravo.

[mmark]

Psynapse & Donut6,

got the original scope.cpp to work on my real linux box (again, ubuntu 14.04, nvidia X11 server...). Did not try the suggested changes to see if those make it run in the VM as well.

I tried for quite a while to get my DDS120 to work with scope.cpp, but I never got any scope data from USB. After installing USBPCap and wireshark I saw that the original software (well, I only tried the Rocktech BM102) does not do any FIFO checking at all with the DDS120. Instead, there is a 0x33:0x0 command from the host and then an interrupt transfer for every frame. So I went ahead and implemented the asynchronous interrupt transfer and got some data, YEAH!! (never die much of USB programming before, so my code my look strange...) Then I also tried just the synchronous transfer without the FIFO check and this works as well. I tried this on Linux and MacOS and it works on both!

Funnily enough you don't need any initialization with the DDS120, just polling for data works right away after plugging it into the USB port.

I removed all the graphics related code for my test since I mainly develop on MacOSX these days and didn't have wxWidgets installed. If anybody is interested, my code (as well as Donut6's) is attached below. The paths in the Makefile are expecting libusb-1.0 to be installed in /opt/local/lib and /opt/local/include (as it is if you use macports to install libusb-1.0 and didn't change the default path), you need to change those if your libusb-1.0 is installed somewhere else.

My plan is use Qt/Qwt to develop a simple scope program for MacOSX and Linux (I am quite familiar with Qt and Qwt, so I prefer that over wxWidgets, but that's just my personal preference).

BTW: it's kinda strange that zip attachments are allowed on eevblog, but not tar.gz...

Cheers,

mmark

[donut6]

mmark,

Nice one!

I believe OpenHantek is a Qt app. Perhaps a candidate for forking?

As for next steps. Speeding up the USB transfer? Custom firmware (maybe more important for the DDS140?) and a dedicated USB capture thread on the app side.

[doctormord]

Hmm, maybe channel interleaving or differential input, there are actually 2 multiplexers free to use. )

Good work guys!

[psynapse]

Looks like this community is cooking!

On the "PC" based app, I am torn between the work that Donut6 has already done and the QT approach .... I have quite a few ideas I was planning upon putting into the Donut6 code, mainly linked on the display side (zooming, scrolling, interpolating, soft trigger etc).

Mmark, I am tempted to use the same continuous data mode (from the DDS120) on the DDS140 as my default data collection mode (but keeping the other high speed flash sampling mode for sampling above 10/20 megs)  :- I am fairly confident that I can add a few lines of code to the firmware to get a range of timebases up to 8Msps  per channel, 12 is less clear and anyway represents the upper limit of sustained throughput for a device on USB. At the moment I have the 940A mode running at (2x)480Khz rock steady.

Donut6, do not want to tread on your toes, do you want to sort the DDS120 data acquisition mode in the software, or should I have a go.

Doctormord,

I would suggest that (for DDS120 users) channel interleaving might be really useful, doubling the maximum acquisition rate, but wouldn't that need a small hardware modification? There are several ways of tackling that problem,  which one are you thinking of?  Differential input, I am not so sure about .... I would probably forget to respect the common mode voltage and connect the two probes across two lines at 18v!

All:  If I revisit the firmware with a view to adding new continuous mode time bases, one of the easiest patches is to steal an existing command from the following table:
DW    case22
DW    case23   
DW    case24   
DW    case33   
   DW    case34
   DW    case35
   DW    case50
   DW    case60
   DW    case61
   DW    case62
   DW    case63
   DW    case70
   DW    case71
   DW    case72
   DW    case73
   DW    case74
   DW    case75
   DW    case76
DW    case77
DW    case78
DW    case79
DW    case7A
DW    case7B
DW    case7C
DW    case7D
DW    case90
DW    case94
DW    caseD0
DW    caseD1

Which code is the best candidate? (patching a new address into this table is a change of just two bytes to existing firmware, the wavetable modification firmware can be put up in unused eeprom)

[ganzuul]

I'm really impressed with this all too. The thread has exceeded all expectations.

OpenHantek is GLPv3, has lots of code comments, and has a qmake build system set up. I have a little experience with Nokia Qt from before, so I might be able to make useful contributions once I re-orient myself to Qt on Linux.


psynapse,
Regarding the CPLD; According to bullet point 4 from the bottom of the list on page 9 of http://www.altera.com/literature/an/an489.pdf one can verify that the bytes written are being read back verbatim. This of course means that the entire user flash memory can be read just like we did with the EEPROM. I'm unsure if the UFM actually contains the code we expect, but it would seem highly redundant if it didn't.


Could you describe which two bytes in the firmware to patch, and if there's a special trick to it, how to do it? It could be beneficial if we try them all and come up with a short list for further consideration.

[psynapse]

Ganzuul,

The big question is which two bytes!

1)  At the moment I patch manually (using cytools) the two bytes in the ram copy of the wavetable, these are two contiguous bytes of 63x 63x. If you dump the eeprom in cyconsole you will get the following line

0A40  00 00 3F 01 63 63 B8 01 01 01 07 02 00 00 01 00 .

Those two 63 are the wait periods for the second and third period of the state machine.  In total the wait period is 1+63x+63x+1 =200d and 48Mhz/200=240khz.  To invoke this mode you need a 940A call, which you can get by selecting the 1s timebase (from the drop down list). For example, my DDS140 is running with the two 63x changed to 31x, and its data rate is now 480khz (for each of the two channels).  With the warning that you could ruin your DDS140, you could change these values to anything between 1 and 63x, it may well be that the two byte can have different values too.

ALL WARNING!THIS APPLIES ONLY TO THE DDS140, AND YOU SHOULD VERIFY THE EEPROM CONTENTS ARE AS SHOWN ABOVE.  NOTE TOO THAT CYCONSOLE HAS A STRANGE HABIT OF CHANGING SOME LOW MEMORY AS WELL. SO DUMP THE BOTTOM 80x BYTES, PATCH THE TWO BYTES SHOWN ABOVE AND THEN CHECK THE LOW 80X BYTES FOR UNPLANNED MODIFICATION.  FOR SAFETY HAVE A COMPLETE COPY OF THE FIRMWARE FOR RELOAD IF NECESSARY

The same 6363 pattern exists in the DDS120

0A20 3F 01 63 63 B8 01 01 01 07 02 00 00 01 00 00 00

2) Note however that the two bytes I am proposing to patch (in my last post) is a  two byte address in the case jump table, so that I can redirect an existing command to some new code that will do this patch under software control. All that will then be necessary will be to issue a 940A command to update the wave table

I have not forgotten the JTAG on the CPLD,  I just have not got round to it!  I've downloaded the information you've flagged up and shall read it right away