This looks like an instance of #1560 which is hopefully fixed by #1596. Without applying the patch, you should be able to work around the issue by calling channel.sync() instead of the init (this is effectively a blind init with proper register init).
Your procedure otherwise looks fine to me. The clk_div pins defaults to high-Z (divide-by-1) which should work fine. If you want to avoid synthesizing the CPLD bitstream, you can download it from the M-Labs build server: mirny.jed
Thanks for this - I still get the MUXOUT error even using the patched code without BLIND=True using both CLK_SEL=0 and 2, but I will check the output tomorrow when I get access to a frequency counter and see if that is updating. I will also try flashing the .jed from the M-Labs build incase that makes it work.
Using the example code from Sebastian (example #3 here https://forum.m-labs.hk/d/109-mirny-coding-examples) I did at least get 144ish MHz output so the boards must be alive at any rate!
Just to be sure: is the "patched code" the one from the pull request? If not, could you try with it?
I'm sorry, I forgot that the workaround I gave doesn't do the job: the registers are not fully initialized in the current code (charge pump bleed current needs to be set as well, see PR) so sync() alone is not sufficient.
airwoodix yes I am using your updated code, and have installed it into a new local env for testing. I have Mirny CH0 on a frequency counter (currently stuck working remotely) and this did not clear the MUXOUT error, I have been running with Blind=True to bypass this.
I think there might be something else wrong here on my board: I can always read and write from the CPLD, and the registers have the right numbers in but the resulting behaviour is not always reproducible (the red LEDs are a bit random) but when I see an output of e.g. 148 MHz (achieved using Sebastian's example #3 mentioned above) I cannot control the RF switch using self.ch.sw.on(), but if I write to reg2 of the cpld then I can turn things on and off that way, but not always. It is almost as if the outputs are latching, which is similar to the issue described for the CLK_DIV pin.
I need to check using the m-labs mirny.jed incase my build has an error so I will get back to you early next week once these things have been checked.
and this did not clear the MUXOUT error
Did you cycle power before trying the patched code? I'd systematically do this to avoid having the ADF5356 in an uncontrolled state and getting confusing results. I'm looking forward to the outcome with the new mirny.jed build.
What do you expect from the "new mirny.jed"? Nothin has changed since the latest released version (0.2.4), right?
rjo making sure there are no build errors. Very unlikely though, I agree.
rjo I also agree it is unlikely to change, but want to make sure I haven't wasted anyones time with a bad build. Given others have got the ADF3536 working with this code, hard to see what the issue might be unless the clock divider (for example) on v1.0 boards is not behaving as expected. I will get the board scoped out tomorrow and try and see if I can check this, but if you have any experience or ideas I am open to suggestions
@airwoodix Success: I have a solution. Using CLK_SEL=1 (external SMA) and running a 125 MHz from the neighbouring DDS board the mirny behaves as excepted - I can control the frequency on each channel and the RF switches work reliably.
Using CLK_SEL=0 or 2 (Internal OSC or MCX) fails, even when trying the mlabs mirny.jed. Looking at the schematics for v1.0rc5, it looks like there is an issue in the clock chain as the MCX and OSC are combined on a Si53340, then fed into input CLK0 of Si53312. As even with the SMA input connected to the board the initialisation only works with CLK_SEL=1, the Si53312 looks to be operating and IN_SEL0 driving the right output. I am guessing IC17 is the culprit, as both of the other clock modes work.
I tried playing around with the CPLD initialisation to toggle through different chip-select values as the initial testing of v1.0 showed the clk_select was not driving low (https://github.com/sinara-hw/mirny/issues/7#issuecomment-479927215) but this didn't solve the problem. For now, I am happy to run using the external SMA clock so thanks very much for the help.