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

[DerKammi]

GREAT, going to try this asap. Thanks fremen. Willing to post the source?

[sokoloff]

This might be considered "salami pricing". The company I used to work for made a product to read electrical power meters. They also made a reader/programmer to program these same meters. The reader sold for $3000 and the reader/programmer for $5000. I worked on this line of products so I knew the only difference was the code contained in the eprom that told the unit what to do. I asked a marketing representative how they could justify charging that big difference for basically no physical difference and he told me they were charging for functionality.

Exactly.

People don't want to buy a quarter-inch drill; they want a quarter-inch hole.

The programmer product had additional functionality that the customer values; it also has additional coding, sales, and support costs on top of what the reader-only unit has. It's not reasonable for a business to solely price products based on the physical cost plus a fixed markup.

When it comes to test equipment, I don't mind companies that try to segment the market this way. I also don't feel bad about using hacks to modify my own test equipment as I see fit. I choose to support manufacturers with reasonable policies on these things.

[zov]

Thanks for your kind words!
About CYCLONE configuration. I am pretty sure there isn't NIOS processor inside the configuration. It needs a program memory
but the size of the configuration data provides strong evidence that there is only pure configuration without any program code.
NIOS can run from internal memory but there is very little one in used CYCLONE, only 30 kB and that memory is needed for waveform sample storing (see below).
No doubts that existing configuration read waveform samples from the flash into the internal memory buffer (16kB BTW from 32kB available) before
provide that to the output. 250Msamples/s is at the upper limit of the used CYCLONE chip and the flash can't provide that speeds of reading anyway.
About reverse engineering CYCLONE configuration from its uncompressed/compressed data (they only differ by sizeof data, no extra encryption) I think it is out of our capability.
About 3000000 configuration bits needs some automated software tools to restore a source design. And BTW in which forms, Verilog, VHDL, schematic? Didn't hear
about such capabilities anyway. If we made a new configuration we certainly can made a special mode in it where SPI interface of FP MCU would be directly
translated to the flash pins so no problem reprogramming it with any new data from USB interface.
And last but not least for the moment. I have already a few ideas about implementation of such configuration especially about its DSP part. But now it's time for me going on vacation
so I can start this work only as early as end of the March / beginning of the April. So you could consider any new desired functionality for a while and then I try implement it later if possible.
Of course without fremen participation all that could not be possible as I am not familiar with FP MCU programming and debugging.

[fremen67]

I have already a few ideas about implementation of such configuration especially about its DSP part. But now it's time for me going on vacation so I can start this work only as early as end of the March / beginning of the April. So you could consider any new desired functionality for a while and then I try implement it later if possible.
Of course without fremen participation all that could not be possible as I am not familiar with FP MCU programming and debugging.

Welcome Zov! I would be glad to help 

[fremen67]

GREAT, going to try this asap. Thanks fremen. Willing to post the source?

Thank you! Waiting for your feedback. As soon as it is stable, I will open a github and post the source. I am still working on this version right now. I should have waited some more days to finish it but it is the week-end and I know you want homework 

[rhb]

@fremen67 Will the new FW run on the FeelTech FP or is it just a PC UI at this stage?  It looks very nice.  I got the impression it was PC only, but I've been more focused on my Zynq adventures and haven't kept up. 

As I read PM0075 p 19, although the flash is read protected, we can force a mass erase and reprogram the device.  Is that correct?

I've ordered a couple of the ST Link programmers from eBay.  I'm sure I could use one of my dev boards, but when I saw yours I went looking and at  $2.54 decided it was well worth having a couple.

I'm very much looking forward to getting my borked V 3.1 unit working properly.

Many thanks to all for their work on this.  I find a delicious irony in forcing FeelTech to accept GPLed FW on their hardware.

[fremen67]

@fremen67 Will the new FW run on the FeelTech FP or is it just a PC UI at this stage?  It looks very nice.  I got the impression it was PC only, but I've been more focused on my Zynq adventures and haven't kept up

It is both. The firmware is for a bluepill board which by-passes the Feeltech FP but it could also work as well in the Feeltech FP. The UI is the other part, modified Feeltech PC Software to be able to talk to the new FW. The main modification in the PC Software is not only the look of the UI but the fact that it reads back values from the new "FP" when they change, and also allows new functions that have been added (like output range limit for DUT protection). Those functions are handled directly in the new FW, not in the UI.

As I read PM0075 p 19, although the flash is read protected, we can force a mass erase and reprogram the device.  Is that correct?

Yes the feeltech FP can be reflashed. I have a second unit (15Mhz) that I will reflash later on when working on the LCD part.

I've ordered a couple of the ST Link programmers from eBay.  I'm sure I could use one of my dev boards, but when I saw yours I went looking and at  $2.54 decided it was well worth having a couple.

In fact the bluepill board is not my dev board. I just modified the FW which is running on my dev board (HY-STM32) to run on this low cost board. This should allow every one to give it a try for 2 or 3$.
If you are interested, please join and flash a blue pill : the more feedback, the best for the quality tests 

[soundtec]

Ive got the various bits of kit needed for the jailbreak on order ,its somewhere between here and Shenzen town now. Im an old fashioned valve/tube/lamp guy and even though Ive tinkered around with computing for over 35 years, a code buster,Im not .
The spirit of human endeavor I've found on the FY6600 topic transcends flags ,politics and media driven stereotypes by a mile,and it gives me hope for the future ,a million miles from the sheepish mass social media frenzy that dictates the lives of so many nowadays.
Too many names to mention for their contributions ,saluts to all who've got involved.

[DerKammi]

GREAT, going to try this asap. Thanks fremen. Willing to post the source?

Thank you! Waiting for your feedback. As soon as it is stable, I will open a github and post the source. I am still working on this version right now. I should have waited some more days to finish it but it is the week-end and I know you want homework 

I did some testing yesterday but somehow the PC software stops working as soon as I connect the FPGA wires, maybe some wire up fault on my side. Not sure yet.

Had to stop my hobby time due to a water fountain in the garage due to the freezing temperatures. Nice cut in the piping

Back on it this evening I hope.

Can I add you on my Github to keep things in one place?

[DerKammi]

Thanks for your kind words!
About CYCLONE configuration. I am pretty sure there isn't NIOS processor inside the configuration. It needs a program memory
but the size of the configuration data provides strong evidence that there is only pure configuration without any program code.
NIOS can run from internal memory but there is very little one in used CYCLONE, only 30 kB and that memory is needed for waveform sample storing (see below).
No doubts that existing configuration read waveform samples from the flash into the internal memory buffer (16kB BTW from 32kB available) before
provide that to the output. 250Msamples/s is at the upper limit of the used CYCLONE chip and the flash can't provide that speeds of reading anyway.

All makes perfect sense. Writing waveforms in a piece of RAM and putting it out on the DAC is indeed the limit of the device as I thought.

About reverse engineering CYCLONE configuration from its uncompressed/compressed data (they only differ by sizeof data, no extra encryption) I think it is out of our capability.
About 3000000 configuration bits needs some automated software tools to restore a source design. And BTW in which forms, Verilog, VHDL, schematic? Didn't hear
about such capabilities anyway.

The synthesize thing is giving a complete different output than one would image, so too bad then

If we made a new configuration we certainly can made a special mode in it where SPI interface of FP MCU would be directly
translated to the flash pins so no problem reprogramming it with any new data from USB interface.
And last but not least for the moment. I have already a few ideas about implementation of such configuration especially about its DSP part.

Interesting

But now it's time for me going on vacation so I can start this work only as early as end of the March / beginning of the April. So you could consider any new desired functionality for a while and then I try implement it later if possible.
Of course without fremen participation all that could not be possible as I am not familiar with FP MCU programming and debugging.

We are not moving that fast, so a vacation is pefect for you to come up with some nice ideas

[DerKammi]

fremen67, what is you clock config? I made an config with CubeMX as attached

[cybermaus]

It's not working!

I stared at the wires on Fremen67's foto's and PDF diagram, checked, double-checked, and its not working.

Symptoms:
- Both LED's on the bluepill are on
- No signal on the channels
- PC does see the COM10 connecting on USB
- PC software does work on COM10 with original FB
- PC software tells me nothing connected on the PORT with bluepill

So, I stared at the wires for a while. Unfortunately my wires are not the same rainbow as fremen's, but I tried to match them.
And also my bluepill has its headers on the other side of the board, so you have to think mirrored.
But still, I am pretty sure they are all correct.

Someone else wants to stare at my wires for a while, and point out where I went stupid?
Thanks, photo's attached.

(Note the white-gray on the 4-pin is unclear, because the white teared a strip of black along, making it also gray-ish, and the gray is reflecting light, making it also white-ish. And I have two red's. sorry, but so does Fremen67)

[cybermaus]

Ripped it all out, did it again, not taking note of fremen's original colors, but instead making sure they were nicely and easily aligned.
Neatness if often the key, makes it all better to work with.
Used the PDF to check each one of them, rather then the foto's

Exact same result.

[cybermaus]

Thinking about it:

Since it is not even showing as connected, it is tempting to think the problem may be in the TTL-UART wiring.
However, that would only be true if the software is such that it still acknowledges the UART if it has a problem with the FPGA connection.

So question to Fremen:
- If the FPGA connection is not properly there, does the software still talk successful with the PC?
- if not, could it easily be made in such a way, to benefit diagnostics?

Alternatively, could there be error-flashing on the LED? (blue pill led, or if real FB, power led)
Something like:
- FPGA not responding, flash 2x
- UART not responding, flash 3x
- LCD not responding, flash 4x


Just a friendly suggestion of course, not intending to bother you too much because I am apparently bad at wiring things.

[DerKammi]

Had some more looking into the signals from the bluepill and it does not send any signals on de spi bus.

When de FPGA is connected I cannot connect to the micro but as soon as I disconnect all spi wires I get a connection to the micro again.

The FPGA ready signal is going low but after that all is silent. Some IO mapped wrong maybe? I swapped some wires back and forth but with no different results.

[Scratch.HTF]

I decided to turn my FY6600 (60 MHz) into a high frequency clock generator (this was my intention when purchasing the FY6600) with the unit set to Square (required for a proper output - the waveform data is at full scale for each transition), along with fitting in a GPS disciplined oscillator module (with an additional power supply and line filter with an IEC input so that the unit can be grounded) and PLL multiplier for the waveform timebase.
Since the NB3N502 (powered by +5V) was tuning to the third harmonic of the +3.3V level clock applied to the clock input pin; a miniature 1uH series inductor was enough to cure this problem; the buffered clock output also has problems with duty cycle and ringing at frequencies below 1 MHz.
Relays (telecom type) marked "A" are switched together and I wired the NB3N502 to be switched between x2 and x5.
The NB3N502 PLL clock multiplier was stable up to 190 MHz at +5V even though the input frequency had some jitter due to a characteristic of the generator where the DAC clock is fixed at 250 MHz (and that the PLL has some degree of input stabilization) – I did get the PLL multiplier (using a +5V supply) to output a stable 250 MHz clock with a stable 50 MHz input, and it appeared to work at up to 320 MHz – despite the minimum output frequency specification of 14 MHz, it was stable right down to a 2 MHz output!

Stable frequency ranges with this circuit were (using a TI 74HC74 connected to +5V):
0.5x (direct via 74HC74 divide by 2): 0-16 MHz
1x (PLL x2 and 74HC74 divide by 2): 1-34 MHz
2x (PLL x2): 2-76 MHz
2.5x (PLL x5 and 74HC74 divide by 2): 2.5-27.5 MHz
5x (PLL x5): 5-190 MHz

[fremen67]

@cybermaus & @DerKammi

Red led ON means problem during initialization. In that case serial link does not work (I should have spend for time on that.. I know ).

Try this: just connect the 4 wires ribbon (+5V, ground, TX, RX) and ground /FPGARDY(PA1) and SPI2_MISO(PB14) on the bluepill.

Initialization should complete now ans serial link should work (Red light flash when receiving data).

Not sure you both have 3.1 version... Maybe some timings issue...

I will be busy till late today... sorry I can't help more right now...

In all cases, modified PC software should work with original FP.

[DerKammi]

How nice is that. Just wanted to test... And lights out... Grid down

[cybermaus]

That's impressive! I don't think I will be able to do that.

Trying now though....

[cybermaus]

Well, power stayed on here, so I think you did something wrong.

Only connected 4-wire plus gnd, b14, a1
Same result (both LED solidly on)

Tried 3 startup-modes:
- First power, then USB-UART
- First USB-UART then power
- Both connected, then press reset button
All same result

Also, I had a logic analyzer on the UART, and other then power-on spike, I never got any byte in either direction.

Indeed, I have a 3.1



Also going outside now. Its nice weather.

[sokoloff]

Well, power stayed on here, so I think you did something wrong.

[DerKammi]

Well it was a big power out in the region, but I think I can be pretty sure that it wasn't my fault

But power is back no and did some testing again and the result is the same, connect anything to the FPGA and it won't init.

[cybermaus]

Tangent: In the nineties, at a business relation in financial centre Londen (I am in ICT), right at the time they were making even transformer intelligent with a simple protocol superimposed on top of the power lines..... a large data center UPS gave just the right noise on the line to confuse the utilities' district distribution. They put a large portion of London's banking district without power twice that day, and then got into a legal shouting match with the utilities.

Moral: It could have been you! Did you install a proper EMI filter on the FY6600?

[DerKammi]

I understand what you are saying, but...

I have done way worse things to the grid without EMI filters in the line.

But the statement of the grid company is that something had to do with the cold weather. Vague general statement they made. But I feel safe doing it again 😂

[cybermaus]

...read waveform samples from the flash into the internal memory buffer (16kB BTW from 32kB available) ...

Remember there is two channels. So that would be all 32KB used up, with not a single byte left for anything else.

I do not know much about FPGA, but maybe those registers and stuff are not RAM, but CLB & IOB states, and not counted toward its memory?