Products > Test Equipment
FeelTech FY6600 60MHz 2-Ch VCO Function Arbitrary Waveform Signal Generator
DaveR:
Hi Fremen - I think the problem stems from trying to upload a waveform into Loading Area 1. I've just been testing with a reflashed bluepill and the Startup Config set to Default and, although the "No answer from generator" - freeze - force shutdown - Error 380 sequence is the same, the program looks uncorrupted when it restarts but won't communicate with the FY6600 until the box has been restarted, then everything appears to be normal again (this is the "minor corruption event" that both soundtec and myself have mentioned).
However, looking in LA 1 to see what was there, I found a partial waveform: it was 75% of the sine wave which I'd made two or three attempts to send there, so I resent the sine wave again and the transfer completed ok. Then I tried sending an AM waveform to LA 50: no problem; sent it LA 51: no problem; sent it to LA 1: error sequence starts. Looking in LA 1 after everything was running again, there was 25% of the AM wave and the remainder of the previous sine wave; sent the AM wave again: error sequence - restart everything - check in LA 1, there was 50% of the AM wave and the remaining 50% of the old sine wave (see attached). Sent the AM wave again: error sequence etc., and LA 1 now has 75% of the AM wave and 25% of the sine wave (see attached). Tried twice more to send the rest of the AM wave, but LA 1 is stuck with 75% AM and 25% Sine wave. Tried sending an FM wave to LA 1: error sequence etc., and now there's 50% FM + 25% AM + 25% Sine in there (see attached). Are we looking at a bug in the new wave transfer protocol, which only appears to affect LA 1 (and maybe others, but not 50, 51 and 55, according to my testing)?
I suspected that during the these tests corrupted data would have been lurking in M1, so I then tried to expose it, but loading M1 just returned Ch2 back from Random51 to SINE (reversing the last previous change), and restarting the program with M1 enabled was also normal. Then I tried sending a sine wave to LA 1 with Startup set to use M1, fully expecting everything to break completely, as per last night's tests, but after going through the error - restart sequence again I looked in LA 1 and found a 100% sine wave! So this time the transfer had worked ok, immediately before comms were lost, and the program restarted ok afterwards. Next, I sent an AM wave to LA1 again: it completed ok, no error sequence, no restarts necessary. Then the same thing with an FM wave: perfect. Then a Sawtooth: perfect again, so now it appears that the comms / transfer protocol has settled down and become stable. Restarted the program and the FY6600, and sent two more waveforms to LA 1 without a problem, but the next one, an AM wave, failed after two blocks (now watching the status bar at the bottom of the window - no need to restart everything now, as I know there will be 50% of an AM wave and 50% of a sine wave sitting in LA 1 :) ).
Now I was wondering why it wasn't doing last night's catastophic crashes any more, so I restarted everything again, turned on M1, and sent a blank wave to LA 1, which failed after 3 blocks. After restarting, LA 1 contains just the remaining 25% of the earlier sine wave, but everything else is still working and Error 380 seems to have gone missing. Time to give up!
Perhaps once the transfer problem has been sorted out, the M1 corruption problem will disappear with it. After a cup of tea, I'll try last night's procedure again with a clean reflash, just to make sure it still happens as it did.
Regards,
Dave
DaveR:
More testing:
Tried a new bluepill, freshly flashed, did same procedure as last night, got same result. Reflashed, tried again without saving any config data to M2, but still same result. Both transfers to LA 1 failed after two blocks, and both produced Error 380.
Decided to go back to the previous BP, which was apparently working ok when it was disconnected, in order to check LA 1 contents, and got an immediate Error 380 from it! So it was actually corrupted but still working earlier?
Regards,
Dave
fremen67:
--- Quote from: DaveR on October 06, 2019, 03:52:09 pm ---More testing:
Tried a new bluepill, freshly flashed, did same procedure as last night, got same result. Reflashed, tried again without saving any config data to M2, but still same result. Both transfers to LA 1 failed after two blocks, and both produced Error 380.
Regards,
Dave
--- End quote ---
Thank a lot Dave for your time.
There was definitely a bug in the PC Software regarding the new wave transfer protocol coding. The bug was invisible on my test system as it is quite "slow" (Virtual machine). When running PC Software directly on the host system I could trace it with my logic analyzer :phew:
There was a de-synchronization between the PC and the MCU which led to the MCU waiting for a wave block (1/4 of a wave) while the PC was still asking the authorization to send it.
When it that waiting state, the MCU does not reply to other commands.
This synchronization problem could happen randomly on any block, hence the partial waves.
The corrupted data in M1 is still a mystery for me as I was not able to reproduce it.
I attached a modified version of PC software (just the wave transfer for now, not yet the error 380 handling).
Let see if you are able to reproduce the flash corruption with this version now…
I will also modify the FP firmware so that it will return to a normal waiting state alone if the block wave is not coming.
DaveR:
That seemed to have got it sorted, Fremen. I did lots of transfers without a problem, saved four different config sets and swapped from one to another several times, and everything was fine. Then I restarted the box and the program and immediately got error 380 again. The hex file attached is taken from the MCU while still attached to the FY6600 and powered up, so you should be seeing the contents exactly as the software saw them. M1 was enabled, so I'll try again with M1 off to see if that's where the problem is coming from.
Regards,
Dave
DaveR:
Here's something to think about, Fremen: I didn't reflash the bluepill, but on a whim I started up the Feeltech software v6.0, and it worked perfectly, with all the saved config sets loading ok. Then I closed it and restarted v0.81 and 0.81 was happy again! No error 380, and everything working. Closed and restarted 0.81 four times, no problem. Closed the software and shutdown the FY6600, restarted the software and turned on the FY6600, error 380. Started v6.0, works fine. Closed 6.0 and started 0.81, working again. Closed the software and shutdown the FY6600, restarted the FY6600 then the software, working fine. Closed the software and shutdown the FY6600, restarted the software and turned on the FY6600, error 380.
I don't think you'll find any corrupted data, because it's probably something else that's causing the error, still linked to the transfer protocol. I didn't have any problems with v0.8 until last night, when I tried waveform transfers with it for the first time. It seems that the software is very stable until you do an upload, then something untoward happens causing error 380. It may be significant that the error occurs when the software is running before the FY6600 is turned on, as the error pops up when the COM port is selected - and you did say that COM port handling was still a work in progress, so perhaps it will sort itself out as work progresses?
Regards,
Dave
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version