FeelTech FY6600 60MHz 2-Ch VCO Function Arbitrary Waveform Signal Generator

[DC1MC]

Based on my bus probing, there is a pretty simple command protocol.  The UI shows the user what the current parameters are and transmits the changes. At boot time it sends the boot time settings to the AWG.  Other than an ACK/NACK, there is no reason in AWG mode for any traffic from the AWG board to the UI board.

So IMHO, the first step is to figure out what the UI sends to the AWG when you change a setting.  Forget the counter function until the AWG works.  That's the part that's valuable.  You can buy a much more capable counter on eBay for $12-15.


As for reading the FW, read the Fraunhofer paper, implement it and get back to us with the FW dump. We'll be happy to take it from there.

I've had to fix a few million lines of other people's code.  At a certain point, it is easier and quicker to simply consider the problem and write the code from scratch.  I think that is true in this case.  Using the device as an AWG only requires sorting out the command set.  I'll gladly write code to control the AWG via RS-232.

The more I look into this stuff, the more I believe that rewriting the firmware is the best way to do it, the Fraunhofer method it's a PITA and reversing the screwed up crap in their firmware it will be most likely useless and a waste of time. I've seen that STM offers a lot of libraries for everything from serial and LCD driving to graphical and mathematical routines and I doubt that our Chinese friends used something else, new and original. And if they did, it's the buggy part. Not to mention that in this situation nobody can claim or hinder us with DMCA and copyright shite.

Now on the actual work, Rhb, could you kindly share your actual findings, which one is the clock line, what freq it used, are there direction switching signals and R/W selector or anything of importance of your findings. I will try to hook tomorrow my scope, the LA it's still on its way to me.  I should at least see how the bus it's structured physically and if I'm extremely lucky the protocol used. Hopefully more forum members will use their powerful test gear and lend a hand.

See you tomorrow,
DC1MC

[rhb]

I did very little.  I hooked up the MSO LA lines and rotated the knob.  I'd never used the LA function before, so it was mostly an instrument training session.  I'm afraid I lost my notes in the process of reorganizing my workspace.  The clock was quite slow, KHz IIRC.  My biggest problem was sorting out the MSO UI.

IIRC 0 at one side was the clock and  4, 5 & 6 or 3 were signal lines. 

I was not very happy with the LA function.  So I suggest setting single shot mode on as many lines as possible, pressing all the buttons and turning the knob.  then go to the next set of lines and repeat in a systematic fashion.

I'm jammed up the next two weeks, but will be able to work on this after that. 

[Chris56000]

Hi!

The more I look into this stuff, the more I believe that rewriting the firmware is the best way to do it, the Fraunhofer method it's a PITA and reversing the screwed up crap in their firmware it will be most likely useless and a waste of time. I've seen that STM offers a lot of libraries for everything from serial and LCD driving to graphical and mathematical routines and I doubt that our Chinese friends used something else, new and original. And if they did, it's the buggy part. Not to mention that in this situation nobody can claim or hinder us with DMCA and copyright shite.

I couldn't agree more!

A quick question tho' - are there standard code libraries available to enable a (reasonably nice!) text/graphical interface to be designed with choice of coloured selections for settings, functions, and a good font, such as Helvetica, Gill Sans or Frutiger? (the one the UK NHS uses for Hospital internal signage!)

(I realise Gill Sans isn't commonly found on T & M Equipment, but it does have the advantage of being clear and easy to read on graphic LCD modules!)

Better still, are there programs available that allow a U.I. to be designed by graphical means on a PC that compile source-code from this, or am I looking at a mega-costly un-affordable solution for this aspect of the firmware?

Chris Williams

[Yansi]

STemWin. But... you better make your own library, before you adapt that bastard for a custom LCD.

[DC1MC]

Some initial bus sniffing of the communication, VERY preliminary results:

Control connector, 8 pins, FS1

 1 - PA0 = Some kind of -POWER_GOOD, is connected to a transistor on SP with the base at 3.3V

 2 - GND

 3 - PA1 = Not found yet

 4 - PB11 = BitX FP -> SB

 5 - PB12 = BitX FP -> SB

 6 - PB13 = CLOCK, 18MHz !!!, 32 clocks/transfer.

 7 - PB14 = BitX FP -> SB

 8 - PB15 = BitX FP -> SB

So, it seem that most of statements up until now regarding the communication protocols were false, including some assumptions of mine. 

The clock is a respectable 18MHz, the data bus seem to nibble oriented, 4bits / clock, 32 nibbles  or 16 bytes or 4 x 32bits values.
No matter how small is the change ( for example just moving the encoder one position, there is a minimum of 16 transfers, or 64 x 32bit values.
So I have the feeling that each time the SB it's fully programmed, no matter how small it's the change !!!

Also barring pin 3 (PA1) doing any direction switch, the data transfer seem to be strictly from FP to SB, I have no idea how the stored waveforms are read back, if they are read.
Have a look on the pictures attached, made with my crappy TBS1104, there are 3 bits and the clock is on the yellow trace.

TODO:

 - See what is happening with pin 3, it really the transfer uni-directional ?
 - See which bit is which ?
 - Connect a proper LA (if it will ever arrive) and get a number of transfers
 - Decode the protocol and how the calibration constants are loaded.
 - The waveforms are actually stored in the SB flash and the FP just tell the SB which one to load ?

 Happy New Year !!!

[rhb]

The bus should have traffic to the front panel in counter mode.

[DC1MC]

Could be, after I'll get my LA, I'll first try to find the bit positions, putting something like 12,234,567,890 Hz and looking at the patterns. Once the bits and transfers from FP to SB are done, then follows the frequency meter mode, prolly pin 3 will switch the direction.
I'm actually curious what is happening, but it's interesting, 18MHz clock, that's a lot for the little MCU, really interested on how it was implemented.

[Yansi]

Regarding the pins sniffed:

PB12 is likely SPI2_NSS
PB13 is likely SPI2_SCK
PB14 is likely SPI2_MISO
PB15 is likely SPI2_MOSI

As PB11 can be I2C2_SDA or USART3_RX, I'd assume it is either the RX port of UART3, or more likely a second NSS (chipselect) for the SPI.

18MHz corresponds to a PCLK divided by 2. 18MHz is nothing to be afraid of. This ain't arduino for kids. Those other  pins aroun the clock pins are definitely the SPI peripheral. There is no way it will be different. PB12 most likely the chip select signal and PB11 maybe second chip select signal.

Now you can start sniffing the data from the SPI.

[Chris56000]

Hi!

Just a quickie one!

I've been reading the STM32F103C8 Datasheet, I was just wondering if Pins PA4 to PA7 are the ones returning from the main PCB (Altera Cyclone Arbitrary W.F. Data out perhaps?) that indicate to the STM32 MCU what waveform is being generated?

These are given in the STMJ32 Data as:-

PA4:- SPI1_NSS/USART2_CK/ADC12_IN4;

PA5:- SPI1_SCK/ADC12_IN;

PA6:- SPI1_MISO/ADC12_IN6/TIM3_CH1;

PA7:- SPI1_MOSI/ADC12_IN7/TIM3_CH2.

Monitoring these four lines whilst changing the waveform-type/amplitude/frequency, etc., using the front-panel controls would suggest this to be the case - I'm assuming these parameters are stored in the Winbond Flash, so it might be worth a continuity-prod or two to see if PA4 to PA7 on the STM32-etc., goes back to the Winbond!

Chris Williams

PS!

I've just realised Member DC1MC only mentioned an 8-pin interface connector plug between FP and SB, but there has to be another one for the 3.3V/5V supplies, earth, etc., so it's possible there may be another multi-plug with some more STM32 lines on it!

BTW, I won't get my generator at least until I'm back on duty @ work Tuesday, but I can surmise one or two things from the information already given so far!

[Yansi]

Now there seems to be a mess in the thread.

What pins are connected in between the MCU and the other board?

Or how did you come up with the SPI1 pins?

//And note there won't most likely be any "waveform indication pins" - why would they? You have full duplex rather high speed SPI bus already there.

[Chris56000]

PPS!

Just a thought - I've just been reading Carmine Noviello's book "Mastering STM32" (V0.21), Section 20.2.1 "Flash Memory Unlocking", p. 573, where the Author clearly recommends the line:-

HAL_StatusTypeDef HAL_FLASH_Lock();

be included in the code to prevent inadvertant over-writing of the flash memory due to transients, power-faults, etc., etc., - what's the betting the Chinks (accidentally-on-purpose?!) left this line out of their code to ensure the things'd fall over before the warranty expired to try and get back development costs in the hope disgruntled users would buy replacement/upgraded/newer units?!

Chris Williams

[Chris56000]

Hi!

Now there seems to be a mess in the thread.

What pins are connected in between the MCU and the other board?

Or how did you come up with the SPI1 pins?

The SPI1 pins are given in the STM32F103C8 datasheet pin-out table.

Member DC1MC mentioned only one 8-pin plug, none of which carry power-supply voltages, so there has to be another connector for these, so if more than two/three pins are used on a second or further connector plug, there's every possibility of there being further connections back to the MCU!

Chris Williams

[rhb]

The cable between the front panel and main board is a 12 wire cable split into two groups of 4 & 8.  The 4 pin  group is  Gnd, Rx, Tx and 5V.  There are no other wires between the FP & MB.  My main board is marked V1.5.

BTW Mine was working fine for a couple of hours after I completed the grounded plug installation feeding my scope and a counter.  I shut the bench down for the night using the power strip.  When powered up the next morning it looked *exactly* like @canyon's photos at the start of the reflashing thread.

[Chris56000]

Hi!

Fair enough, Member rhb's identification of the connections rules out a direct connection from PA4-PA7 back to the WinBond, and also indicates the 3.3V reg for the STM32 will (or should be!) on the front panel PCB.

That does suggest the data control interface on lines PB12-PB15 could possibly be bi-directional, I don't think Tx and Rx will be anything like fast enough to carry waveform parameter data back.

I'll get started on a FP schematic as soon as I get my hands on my unit when I'm back at work!

Chris WIlliams

[rhb]

SU1 on the FP board is an AMS1117 3.3 V LDO regulator.

[Yansi]

Hi Chris,

have you read what I have written or are you deliberately ignoring my posts? I have already written you that SPI2 is used and identified the pins accordingly.

I do not know where did you get that those pins PA4 to PA7 are used in the FY6600 to communicate with the FPGA board. Or have I missed a post about them?

[DC1MC]

On my device there are 2 separate cables between FP and SB,

One 4 pin, J1
5V
GND
TxD
RxD

And the 8pin data cable that does not carry any power, it just have a GND wire.

The clock and data pins I have described in previous post.

I will see when my LA will arrive if the protocol is a variant of SPI or some other non-standard, simpler stuff. Even if the Intronix it's a bit old, it should be capable of decoding all SPI versions.
It's very likely that the SPI serializer block is used, because 18MHz it's really difficult to do by bitbanging. What it's left to see it's to see if they used the SPI interface in a sane way or in some perverted mode.
Dear members that already have a logic analyzer, please connect and determine at least the purpose of pin 3 (PA1), is it a direction switch or what.

come on, you collected all this coll gear, use it this year 

 

[Yansi]

Well... I don't have the FY6600 to begin wirt.  Maybe if one could donate or lend me one for reverse engineering? Germany somebody? 
This way I can only give expertise on STM32 device side.

They use the SPI2 for sure. Just identify the rest of the GPIOs where do they end on the FPGA board.

[DC1MC]

Well... I don't have the FY6600 to begin wirt.  Maybe if one could donate or lend me one for reverse engineering? Germany somebody? 
This way I can only give expertise on STM32 device side.

They use the SPI2 for sure. Just identify the rest of the GPIOs where do they end on the FPGA board.

There is just ONE GPIO left to be identified (PA1).
It will not survive too much afrer my LA will arrive and it will be identified .

On the other side, if you're close to Mannheim, I can drive to you with my FY, assuming that you have a proper LA and scope, we can even try to reproduce the Fraunhofer experiment .
The problem is that my LA is scheduled to arrive on 8.01, exactly when my vacation is over

 

[Yansi]

Thanks for your interest, unfortunately not anywhere close around Mannheim.  But Germany is the closest place where someone could have one 

I should be doing different things, than playing with electronics anyway... but you know it: Everything is better than to do some boring obligatory work for ... 

[g0mgx]

The 4 pin  group is  Gnd, Rx, Tx and 5V.  There are no other wires between the FP & MB.  My main board is marked V1.5.

The 4 pin cable is from the USB to 232 CH340 device on the main board to the FP. As far as I could tell that 5V line was the only power feed to the FP so there must be a 3.3V reg on the FP board.

Mark
G0MGX

[DC1MC]

Gentlemen, let's focus on the important things, there is no other power line to the FP except the 5V0 coming along with the serial interface cable, the FP has 3V3 LDO  on PCB and this is that. Once I'll be able to get more friendly with KiCAD I may drawn a schematic, of I could draw it on paper faster and have some kind soul put it in his schematic capture program and produce a PDF out of it. This is really the least of our concerns here.

The data communication seem to be done over an SPI interface, that makes sense, it's bidirectional and easy to implement in FPGA. One of the signals that it's not part of the SPI interface is just a pull down transistor and another it's a mystery one that seem to stay unused at lest in the simple tests I've done.

Now, please, pretty please with sugar on top, could someone hook an Logic Analyzer on the SPI interface and get some traffic sniffed, she/he'll be my hero, because my LA coming form UK it's stuck on "Arrival Scan" and Germany it's fully stopped now . Come on, out of 5-6 people that spend time modding this generator it HAS to be one willing to donate a bit of time with an LA.

Waiting for good news,
DC1MC
   

[DC1MC]

OK, here are some more snapshots, taken with my most craptacular Craptronis scope EVAR, TBS1104, if you ever see one, destroy it with fire and a large hammer

Legend:

Yellow - SPI CLK
Blue   - PB15 MOSI
Lila     - PB12 SPI_NSS
Green - PB11 Used as another CS


There seem to be at least 2 SPI devices, form the miserable screen I just can see that there are data transfers when at least one tof the selector signals is in 0 and mone when both are 1, this is as expected
Another thing is that the word size is set to 16 bits.
And yet another thing is that there are a crapload of transfers, to just change the the last digit of the frequency  .

Right now I've reached the limits of this Fully Feature-Free (TM) (C) Tektronix piece of junk, so please try to reproduce my experiments with a better scope and suggest me please a better scope in 500EUR range, this POS has to go.

Enjoy the (crappy) shots I've made with our data transfers.

[Chris56000]

Hi!

I would like to have a go at this myself – can anyone who's a bit more "au–fait" with Logic Analyzers than I am suggest what sort I'll need – does it need an expensive "all bells and whistles" instrument that can decode the logic–bits into a hex byte, or it it possible to make up some sort of SPI decoder for the STM32 that can display the data in some form of human–readable format?

I do have an Zicon Electronics 16–channel one that displays on an ordinary oscilloscope – is this suitable for reading the SPI Lines?

Chris Williams

[g0mgx]

I'm happy to put some time into this, the problem is I have no experience with SPI comms and hence I dont know what I am doing.

I've attached a 'scope grab of each pin (pin 2 is ground for sure) and also the drivel I get when I try and decode this.

I'm not sure what line is CS?

If anyone wants to give me some guidance I am happy to help, otherwise I have to retreat to the sidelines and hope to learn.

I will now start a search on you tube for sniffing SPI and see what I can find.....

Pin 1:


Pin 3:


Pin4:


Pin 5:


Pin 6:


Pin 7:


Pin 8:


Some total Drivel:


Mark
G0MGX