Quote from: zefir on February 15, 2014, 10:18:26 AM

Hm, this to me looks like a power issue - at least the effects you observe are similar to what we had here until we got the DCDC stabilized.

First of all, try to not go below 200 MHz sysclock, since I am not sure if the PLL settings are correct for low values or how low it can really get. Operating the chip at 200MHz even without cooling is no problem.

Then ensure the supply voltage is above 0.85V and ripple is within valid tolerance. Same goes for reference 1V8, reset and SPI signals. If you got access to the register, I guess you did that correctly. You can try to stress-test the inter-chip SPI by continuously reading the register of each chip over a longer period to ensure there are no issues.

Usually, the serious troubles begin when you supply the chips with work and they start to hash. The power draw immediately spikes for order of magnitudes and if DCDC is not capable to handle that, the voltage ripple eventually will exceed the tolerance. The chip then usually resets itself, and with that you usually lose access to it, since the chip becomes unaware that it is part of a chain. To regain access to it, you need to HW reset the whole chain and re-enumerate the chips again.

A strong indication that the chip was reset after it started hashing is the inability to read out its register, i.e. you e.g. write 0x0a02 to get register of chip 2, and you read back 0x0a02 instead of 0x1a02, meaning there is no chip 2 in the chain any more.

We detected problems in the DCDC by scoping the levels long term and triggering for levels outside the tolerance range.

As for your other issue with the endianess of the job command: the provided driver uses 8bit transfers and the create_job() function prepares the data for byte-wise operation. If you are not using 16bit and did not modify the source code, please post a trace of the related SPI transfer and I will double check with my logs.

zefir,

So my core voltage was a bit low - I had it at the lower end at 0.82V. I started with changing that to 0.84V as that was easy (to get to 0.85V I need to muck with the trim registers in the power supply - the documentation isn't really clear and I can way over volt the chip if I get it wrong so I didn't want to try that right away).

Things did get much better, but still not 100% so I think you are spot on for the power issue. All four chips are at least claiming they can process jobs.

When I was getting that single nonce that was with sending the data you had posted directly rather than going through create_job. If I fix the endianness with create job I get no results I am using a byte wise SPI transfer so I believe any 16 bit endiness issues should be ok.

The data I am uploading to chip 1 is (this is in transfer order):

17 01 49 4b f3 70 41 71 f3 e8 3f ea 17 04 10 d8
dc 17 8f 80 2f 12 6d cd b7 e4 2c 25 0a d8 18 a3
1f 8c 01 8e 98 d6 52 66 1f 27 19 10 0a b6 00 00
00 00 ff ff 00 1d ff ff ff ff

I did try faster PLL's and am not seeing any difference in behavior.

I will work on getting the voltage up to 0.85V.

Thank you!