I think the component on the left is the following:ARM STM32F303VC LQFP100
Datasheet: http://www.keil.com/dd/docs/datashts/st/stm32f3xx/dm00058181.pdf
Topic: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support (Read 81287 times)
October 24, 2014, 05:09:02 AM
I have a very crappy photo to go on from my phone, but after some enhancement with photoshop I think the component on the left is the following:
ARM STM32F303VC LQFP100
Datasheet: http://www.keil.com/dd/docs/datashts/st/stm32f3xx/dm00058181.pdf
I think the component on the left is the following:ARM STM32F303VC LQFP100
Datasheet: http://www.keil.com/dd/docs/datashts/st/stm32f3xx/dm00058181.pdf
October 24, 2014, 05:07:42 AM
It's very rare that voltage controllers have some control/monitoring over I2C, SMBUS or SPI. Those voltage controllers are propably from Linear LTCxxxx. Without extra rheostat (MCP4017 for example) in voltage loopback it's impossible to control voltage thru software.
October 23, 2014, 08:22:31 PM
Here's my annotated image.. (the power connector at least look like mine, so I suspect we have somewhat similiar hardware, but I have not opened mine up yet)
So it seems like there are 4 voltage regulators (one for every 2 chips), and we'd need to know what part number they are. Sometimes the VRM (voltage regulator module) chips have I2c or some other direct digital interface to tell you stuff like power, set voltage, etc.
But the biggest problem is I think there's a mystery microcontroller on the board, which is likely what is in charge of setting up the VRMs. So we have to know what it is first. The best case is if we get support from the manufacturer, but unless it's Innosilicon, who might give you info because they want to sell chips, I doubt you'll get much.
So it seems like there are 4 voltage regulators (one for every 2 chips), and we'd need to know what part number they are. Sometimes the VRM (voltage regulator module) chips have I2c or some other direct digital interface to tell you stuff like power, set voltage, etc.
But the biggest problem is I think there's a mystery microcontroller on the board, which is likely what is in charge of setting up the VRMs. So we have to know what it is first. The best case is if we get support from the manufacturer, but unless it's Innosilicon, who might give you info because they want to sell chips, I doubt you'll get much.
October 23, 2014, 02:24:46 PM
The board:
Is connected to the control unit, which is connected to the raspberry pi:
Is connected to the control unit, which is connected to the raspberry pi:
October 23, 2014, 01:38:12 PM
That depends on your board layout and voltage regulators. If you've got an A2 terminator I'd be quite interested in trying to reverse engineer this. Otherwise we likely need at least the schematics of the board.
So no means to change the voltage by software? I thought I read in this topic that it could be controlled by i2c?
Can you take a picture of your hash board? How's it wired to the raspberry pi? Can you identify the voltage regulator/controller chip?
October 22, 2014, 04:20:29 AM
That depends on your board layout and voltage regulators. If you've got an A2 terminator I'd be quite interested in trying to reverse engineer this. Otherwise we likely need at least the schematics of the board.
So no means to change the voltage by software? I thought I read in this topic that it could be controlled by i2c?
October 21, 2014, 10:45:42 AM
Having some trouble with getting 0x04 responce on the 0x04 reset command.
I'm doing the HW reset as described. The signals from raspi passed through level shifters.
Chip select DI CLK are ok. I see 0x04 passing into the chip but there is nothing at the output.
The VDDcore is 0.7 volts. Maybe it is too low?
I'm doing the HW reset as described. The signals from raspi passed through level shifters.
Chip select DI CLK are ok. I see 0x04 passing into the chip but there is nothing at the output.
The VDDcore is 0.7 volts. Maybe it is too low?
That's pretty likely too low. I had similar issues when I was running the chip that low. 0.8V seems to be pretty reliable for at least basic comms for most chips. A couple wouldn't hash at that voltage but once I brought it up to about 0.84V they were fine.
Of course, now those chips run hotter than the others
I know it is an old topic but I have a question. I am working on the firmware for the A2's, which are pretty much the same as the A1's. However, it seems to be possible to adjust the VDD_Core voltage by software. How did you guys change the VDD_CORE voltage???
Greatly appriciated,
emdje
That depends on your board layout and voltage regulators. If you've got an A2 terminator I'd be quite interested in trying to reverse engineer this. Otherwise we likely need at least the schematics of the board.
October 19, 2014, 11:13:57 AM
Having some trouble with getting 0x04 responce on the 0x04 reset command.
I'm doing the HW reset as described. The signals from raspi passed through level shifters.
Chip select DI CLK are ok. I see 0x04 passing into the chip but there is nothing at the output.
The VDDcore is 0.7 volts. Maybe it is too low?
I'm doing the HW reset as described. The signals from raspi passed through level shifters.
Chip select DI CLK are ok. I see 0x04 passing into the chip but there is nothing at the output.
The VDDcore is 0.7 volts. Maybe it is too low?
That's pretty likely too low. I had similar issues when I was running the chip that low. 0.8V seems to be pretty reliable for at least basic comms for most chips. A couple wouldn't hash at that voltage but once I brought it up to about 0.84V they were fine.
Of course, now those chips run hotter than the others
I know it is an old topic but I have a question. I am working on the firmware for the A2's, which are pretty much the same as the A1's. However, it seems to be possible to adjust the VDD_Core voltage by software. How did you guys change the VDD_CORE voltage???
Greatly appriciated,
emdje
June 23, 2014, 03:26:09 PM
We have some level shifters we made for the ref boards. We could make a bigger batch for sale. Any interest out there?
Pardon my ignorance, but what is this board for?
June 12, 2014, 09:38:44 PM
https://i.imgur.com/a5H8z8t.jpg
We have some level shifters we made for the ref boards. We could make a bigger batch for sale. Any interest out there?
We have some level shifters we made for the ref boards. We could make a bigger batch for sale. Any interest out there?
June 01, 2014, 01:25:24 AM
Driver is for RaspPi with direct communication thru SPI. I'm using microcontroller that is a brigde between chain of chips and host thru RS485 comm port. So I needed to write own "driver". Obviously I was looking at that piece of code, but it's not secret that looking at someone's code is painfull 
It give me quite good amount of headache but it helped a little bit too. It only confirms that chip behavior is very dependent on command. exec_cmd function needs long list of parameters to be sucesfully executed...
It give me quite good amount of headache but it helped a little bit too. It only confirms that chip behavior is very dependent on command. exec_cmd function needs long list of parameters to be sucesfully executed...Hm, I tried to write the driver source code as self-explanatory and readable as possible, sorry if it was not as helpful as it could have been. Anyway, for one prototype I once ported the code to an STM32 controller, and after adapting the access to the SPI interface, it worked mostly unchanged. Unless you have a very resource-limited uC working with, I won't expect any issues.
Otherwise feel free to ask for clarifications, I'm helping out as far as possible.
Zefir, your code in cgminer is some of cleanest there is in there. Please don't let anyone tell you otherwise.
I wrote my own test code for A1s using the Pi and my feedback about the datasheet is that it was well written and (mostly) easy to understand. In combination with this thread I was able to get going in no time. I mean compare this to the (missing) bitfury docs and you'll see the difference.
+1 on Zefir's work from me too!
(and it was indeed quite a task to put something together to cover for Bitfury's omission)
May 31, 2014, 07:19:54 PM
Driver is for RaspPi with direct communication thru SPI. I'm using microcontroller that is a brigde between chain of chips and host thru RS485 comm port. So I needed to write own "driver". Obviously I was looking at that piece of code, but it's not secret that looking at someone's code is painfull It give me quite good amount of headache but it helped a little bit too. It only confirms that chip behavior is very dependent on command. exec_cmd function needs long list of parameters to be sucesfully executed...
It give me quite good amount of headache but it helped a little bit too. It only confirms that chip behavior is very dependent on command. exec_cmd function needs long list of parameters to be sucesfully executed...Hm, I tried to write the driver source code as self-explanatory and readable as possible, sorry if it was not as helpful as it could have been. Anyway, for one prototype I once ported the code to an STM32 controller, and after adapting the access to the SPI interface, it worked mostly unchanged. Unless you have a very resource-limited uC working with, I won't expect any issues.
Otherwise feel free to ask for clarifications, I'm helping out as far as possible.
Zefir, your code in cgminer is some of cleanest there is in there. Please don't let anyone tell you otherwise.
I wrote my own test code for A1s using the Pi and my feedback about the datasheet is that it was well written and (mostly) easy to understand. In combination with this thread I was able to get going in no time. I mean compare this to the (missing) bitfury docs and you'll see the difference.
May 31, 2014, 07:14:07 PM
Got my PCB made this week. Anyone else working on a reference build? Would love to compare notes
https://i.imgur.com/J34PiOI.jpg
https://i.imgur.com/J34PiOI.jpg
I am selling 2 extra boards that I had made at cost ($25). I am in the US, quick shipping.
Does this work and do you have the BOM? How much for all the parts except for the A1 chips?
yes and yes. Oh, I dunno $50 maybe
May 31, 2014, 05:24:48 AM
Driver is for RaspPi with direct communication thru SPI. I'm using microcontroller that is a brigde between chain of chips and host thru RS485 comm port. So I needed to write own "driver". Obviously I was looking at that piece of code, but it's not secret that looking at someone's code is painfull It give me quite good amount of headache but it helped a little bit too. It only confirms that chip behavior is very dependent on command. exec_cmd function needs long list of parameters to be sucesfully executed...
It give me quite good amount of headache but it helped a little bit too. It only confirms that chip behavior is very dependent on command. exec_cmd function needs long list of parameters to be sucesfully executed...Hm, I tried to write the driver source code as self-explanatory and readable as possible, sorry if it was not as helpful as it could have been. Anyway, for one prototype I once ported the code to an STM32 controller, and after adapting the access to the SPI interface, it worked mostly unchanged. Unless you have a very resource-limited uC working with, I won't expect any issues.
Otherwise feel free to ask for clarifications, I'm helping out as far as possible.
May 30, 2014, 05:12:42 PM
Finally!!!
Test vectors passed And I can confirm now that test job returns six nonces. 744ec1ec is the 6th one.
This chip is a nightmare for software writer. Behavior of the chip depends on the command. Some commands break chain, some don't return any value back to host uC. And datasheet is the worst I ever seen. Errors (register table for example) and lack of information. Without oscilloscope I would never guess how to "talk" with this chips. Many hours spended on discovering things that should be in datasheet.
http://imgur.com/MVtOniD
Test vectors passed
And I can confirm now that test job returns six nonces. 744ec1ec is the 6th one.This chip is a nightmare for software writer. Behavior of the chip depends on the command. Some commands break chain, some don't return any value back to host uC. And datasheet is the worst I ever seen. Errors (register table for example) and lack of information. Without oscilloscope I would never guess how to "talk" with this chips. Many hours spended on discovering things that should be in datasheet.
http://imgur.com/MVtOniD
I don't get it, doesn't this driver: https://github.com/ckolivas/cgminer/blob/master/driver-SPI-bitmine-A1.c cover the communication with the A1 chip?
Are you saying that there is something wrong with the driver?
It give me quite good amount of headache but it helped a little bit too. It only confirms that chip behavior is very dependent on command. exec_cmd function needs long list of parameters to be sucesfully executed... May 30, 2014, 03:56:45 PM
Finally!!!
Test vectors passed And I can confirm now that test job returns six nonces. 744ec1ec is the 6th one.
This chip is a nightmare for software writer. Behavior of the chip depends on the command. Some commands break chain, some don't return any value back to host uC. And datasheet is the worst I ever seen. Errors (register table for example) and lack of information. Without oscilloscope I would never guess how to "talk" with this chips. Many hours spended on discovering things that should be in datasheet.
http://imgur.com/MVtOniD
Test vectors passed
And I can confirm now that test job returns six nonces. 744ec1ec is the 6th one.This chip is a nightmare for software writer. Behavior of the chip depends on the command. Some commands break chain, some don't return any value back to host uC. And datasheet is the worst I ever seen. Errors (register table for example) and lack of information. Without oscilloscope I would never guess how to "talk" with this chips. Many hours spended on discovering things that should be in datasheet.
http://imgur.com/MVtOniD
I don't get it, doesn't this driver: https://github.com/ckolivas/cgminer/blob/master/driver-SPI-bitmine-A1.c cover the communication with the A1 chip?
Are you saying that there is something wrong with the driver?
May 30, 2014, 12:09:57 PM
Finally!!!
Test vectors passed And I can confirm now that test job returns six nonces. 744ec1ec is the 6th one.
This chip is a nightmare for software writer. Behavior of the chip depends on the command. Some commands break chain, some don't return any value back to host uC. And datasheet is the worst I ever seen. Errors (register table for example) and lack of information. Without oscilloscope I would never guess how to "talk" with this chips. Many hours spended on discovering things that should be in datasheet.
http://imgur.com/MVtOniD
Test vectors passed
And I can confirm now that test job returns six nonces. 744ec1ec is the 6th one.This chip is a nightmare for software writer. Behavior of the chip depends on the command. Some commands break chain, some don't return any value back to host uC. And datasheet is the worst I ever seen. Errors (register table for example) and lack of information. Without oscilloscope I would never guess how to "talk" with this chips. Many hours spended on discovering things that should be in datasheet.
http://imgur.com/MVtOniD
May 29, 2014, 04:28:23 PM
Got my PCB made this week. Anyone else working on a reference build? Would love to compare notes
I am selling 2 extra boards that I had made at cost ($25). I am in the US, quick shipping.
Does this work and do you have the BOM? How much for all the parts except for the A1 chips?
May 29, 2014, 03:39:37 PM
Inquiring minds want to know, what converter/driver/controller chips are you using ...
It's a secret
So far I experienced software problems. I can write to reg and read back. But when I upload test job then register[16] stays at 1 all the time. Chip gets hotter and hotter but no results. Any idea why?
May 29, 2014, 02:55:40 PM
Inquiring minds want to know, what converter/driver/controller chips are you using ...
It's a secret
Jump to: