Experimenting with Jalapeno firmware...

[Red_Wolf_2]

Oh god... experiencing problem after flash:

[2013-07-04 12:31:24] Started cgminer 3.3.1
[2013-07-04 12:31:27] BitForceSC detect (2:3) 2nd init failed (0:-7) - retrying

[2013-07-04 12:31:28] BitForceSC detect (2:3) init failed 3 times 3.31s
[2013-07-04 12:31:28] BitForceSC detect (2:3) error identify reply (0:-7)
[2013-07-04 12:31:28] Disabling extra threads due to dynamic mode.

 :[

The red light is flashing on/off 2-3 times a second. When I hook up JTAG (AVR DRAGON) it flashed quietly like normal and I can still re-program it.

I flashed with the untouched firmware 1.2.5. Anyone know whats wrong? :/

EDIT: Alright, after very quick trial and error, this has to do with the "#define __ASIC_FREQUENCY_ACTUAL_INDEX   7".

Apparently 7 doesn't work on mine. I got 5 working fine, will try and adjust with 6-8-9

I have the same problem with my Jalapeno.
I have flashed it with default __ASIC_FREQUENCY_ACTUAL_INDEX=7
and got this problem.
Reflashed with __ASIC_FREQUENCY_ACTUAL_INDEX 5   - same problem again...
with __ASIC_FREQUENCY_ACTUAL_INDEX 1 - same problem.
Also after upgrade there is only one big LED4 blinking and LED1 (power), but before upgrade there 2 LEDs on the other side of board was on too...


How can I get it fixed?

Thanks

Switch to the latest versions of mining software, also check the firmware you used, there is another define (#define __PRODUCT_MODEL_JALAPENO__) which must be set for the Jalapeno line of products. If you have anything else defined it will probably upset it.

[crescendo]

I saw this one, it is nice one.

[colorprint]

Switch to the latest versions of mining software, also check the firmware you used, there is another define (#define __PRODUCT_MODEL_JALAPENO__) which must be set for the Jalapeno line of products. If you have anything else defined it will probably upset it.

reflashed with this change (#define __PRODUCT_MODEL_JALAPENO__ ) - no result again

[mrrad]

try ck's http://ck.kolivas.org/apps/cgminer/BitForce_SC/BitForce_SC_1.2.5ck.elf.zip  you dont have to compile it use it at the memories stage..

[colorprint]

try ck's http://ck.kolivas.org/apps/cgminer/BitForce_SC/BitForce_SC_1.2.5ck.elf.zip  you dont have to compile it use it at the memories stage..

I have flashed it, and it ended with chip near LED7 fired up after 5 seconds I have turned it on after reflashing  

[frostedflakes]

Don't know if this is typical for newer Jalapenos, but mine actually came from BFL with two chunks of the heatsink cut out over the fan and JTAG1 headers. Mine also didn't have a JTAG2 header soldered on. So didn't need to remove the heatsink to put the JTAG cable on and program the μC (of course didn't open it up and realize this until after I had already ordered a JTAG cable w/grabber kit that still hasn't arrived yet for like $10 off eBay).

http://img843.imageshack.us/img843/9178/c7dv.th.jpghttp://img15.imageshack.us/img15/1646/m435.th.jpghttp://img543.imageshack.us/img543/2346/mcf7.th.jpghttp://img801.imageshack.us/img801/2996/0ghf.th.jpg

Was getting ~5.8GH/s with default firmware (not sure why but was running pretty high straight from the factory, but also had what seems to be fairly high HW error rate, about 2%, so effective hash rate would actually be a bit lower). Flashed an unmodified 1.2.5 to it and now getting 8.1GH/s-8.3GH/s, depending on how many engines initialize and at what speed they initialize. Even more hardware errors now, though, looks like roughly 4%. Might be some other issue with my setup.

Going to try letting it cool down for a bit here sometime and seeing if I can get it to reinitialize at a higher hash. Looks like currently it's only initialized with 13 engines on on chip 3 and 14 engines on chip 7, but they are clocked super high, 305MHz for chip 3 and 296MHz for chip 7. The #define __ASIC_FREQUENCY_ACTUAL_INDEX should be whatever the default is, 7 right? I didn't realize it would clock them that aggressively.

Before I was getting about the same number of engines initializing, 13-14, and they were clocking at 190-200MHz I think (again depending on whether you were cold booting and starting up the unit after it had been running for a bit).

[chanberg]

nice fan man.. Surprised the 92mm noctua's dont come braided

[frostedflakes]

It actually did come with some nice sleeving. It was pretty stiff and hard to deal with inside the cramped Jalapeno case, though. So just cut the sleeve off, far easier to route the fan ribbon cable inside the case without it.

And yeah made a huge difference in noise, really happy with the fan. The stock one was unbearable.

[chanberg]

It actually did come with some nice sleeving. It was pretty stiff and hard to deal with inside the cramped Jalapeno case, though. So just cut the sleeve off, far easier to route the fan ribbon cable inside the case without it.

And yeah made a huge difference in noise, really happy with the fan. The stock one was unbearable.

i hear you, but although that stock fan is loud, it hauls butt and moves a lot of air

[frostedflakes]

Definitely. Always a tradeoff.

[lightfoot]

This thread inspired me, so after getting my 5gh/s jally last Tuesday I ran it (5.1gh/s, 34 C), and ordered a Dragon.

Dragon came on Tuesday, flashed the unit with the stock 1.25 firmware (speed 7) and performance went to 7.3gh/s. Nice. Temp went to 40c, I noticed one chip was putting out 3% error rate, other was at zero %.

This evening I flashed it with diagnostics set to one (to try to get more cores), speed to 8. Performance is around 7.7gh/s, Temp is 45C, one chip is putting out close to 9% error rate.

Looks like one of my chips is a tad bit substandard. Not sure if going to 9 will speed me up more or overwhelm the slower chip, but in either case the heat increase is substantial.

I've ordered some artic heat sink pads to replace the wimpy ones on the unit now, but for a $169 or whatever I paid for this when I ordered it in Jan it's not too bad. I might back the speed back down to 7 since the higher error rate might not be worth it, or should I go to 9?

Thank you everyone for the help.

[yachtsman]

This thread inspired me, so after getting my 5gh/s jally last Tuesday I ran it (5.1gh/s, 34 C), and ordered a Dragon.

Dragon came on Tuesday, flashed the unit with the stock 1.25 firmware (speed 7) and performance went to 7.3gh/s. Nice. Temp went to 40c, I noticed one chip was putting out 3% error rate, other was at zero %.

This evening I flashed it with diagnostics set to one (to try to get more cores), speed to 8. Performance is around 7.7gh/s, Temp is 45C, one chip is putting out close to 9% error rate.

Looks like one of my chips is a tad bit substandard. Not sure if going to 9 will speed me up more or overwhelm the slower chip, but in either case the heat increase is substantial.

I've ordered some artic heat sink pads to replace the wimpy ones on the unit now, but for a $169 or whatever I paid for this when I ordered it in Jan it's not too bad. I might back the speed back down to 7 since the higher error rate might not be worth it, or should I go to 9?

Thank you everyone for the help.

I am in a very similar boat as you. I have both jallys set to 9. One Jally has normal hw errors while the other is through the roof. Plus my average speeds are all over the place.

http://eligius.st/~wizkid057/newstats/userstats.php/1Cx2wsdoBjdJMxEvZiXGUMMAoUPddt6cnA

[lightfoot]

I am in a very similar boat as you. I have both jallys set to 9. One Jally has normal hw errors while the other is through the roof. Plus my average speeds are all over the place.

http://eligius.st/~wizkid057/newstats/userstats.php/1Cx2wsdoBjdJMxEvZiXGUMMAoUPddt6cnA

Define through the roof? I don't think error work is sent back; I think it's just dropped. Mine now is 2.5% overall, 0% on one chip, 5% on the other. But in a technical sense, a chip core that is 25% bad is still doing 75% of the work and contributing to my overall dollars.

Perhaps.

C

[kano]

I am in a very similar boat as you. I have both jallys set to 9. One Jally has normal hw errors while the other is through the roof. Plus my average speeds are all over the place.

Define through the roof? I don't think error work is sent back; I think it's just dropped. Mine now is 2.5% overall, 0% on one chip, 5% on the other. But in a technical sense, a chip core that is 25% bad is still doing 75% of the work and contributing to my overall dollars.

Perhaps.

C

75% of 9 = ... 6.75
so obviously if you run it at 8 and only get less than 15% you are ahead

[lightfoot]

75% of 9 = ... 6.75
so obviously if you run it at 8 and only get less than 15% you are ahead

Exactly. I should get cgminer running so I can see how many cores are running on each CPU, and if that changes by my moving the diagnostic level from 10 to 1. Right now I backed out my 8 change yesterday to 7, left the diagnostics set to low, and am getting 4% failures on the bad chip instead of the 2% before. So I might have enabled another core that is throwing 2% errors overall on the chip.

The trick with running faster is it burns more heat, it seems to be going up exponentially and not linerally as I clock up, more heat=more wear=more power (which is a hill of beans right now, even with the laptop the whole shooting match only pulls 40 watts).

Next up is to try powering the system off a 12 volt battery to see if a perfectly smooth power input reduces errors. If some of the error is caused by instabilities due to the cheap-o-power supply, clean DC might mean more cores to bear which would mean more $$$$

C

[nebiki]

hello. i have this jalapeno which has 15 active engines on both chips, reported max hashrate is 8745MH/s and it runs at freaking 2.6V. my other one has 15 engines on both chips, reported max hashrate of 7569MH/s and runs at 3.5V. both very low hw error rate (bfg reports <0.5%). if i apply some pseudo-logic to this, i'd think that the 8745 one is a beast which could run even higher. is it possible with current fw to get this done?

[frostedflakes]

Sounds like you lucked out, got some great chips in your Jalapenos.

There's a setting __ASIC_FREQUENCY_ACTUAL_INDEX=7 in the firmware source code that you can try changing to 8 or 9. My understanding is that this will clock the ASICs more aggressively than the default value of 7. As few HW errors as you're getting I bet there's still quite a bit of frequency headroom for the chips.

[lightfoot]

Indeed. I've found that going beyond 7 does weird things for my Jally; staying at 7.3gh. Did note that uing the Artic heat pad has reduced my temps to 40c, which is very nice actually. And I found a 10 pin header that I am going to sand down to fit under the sink so I can stop taking it off all the time. Want to flash on demand. :-)

Speaking of which, is there a way to identify the number of active cores using BFGMiner, or do I have to install CGMiner?

[derr777]

i use cgwatcher to find number of engines and speeds on powerup..

[frostedflakes]

Don't know if this is typical for newer Jalapenos, but mine actually came from BFL with two chunks of the heatsink cut out over the fan and JTAG1 headers. Mine also didn't have a JTAG2 header soldered on. So didn't need to remove the heatsink to put the JTAG cable on and program the μC (of course didn't open it up and realize this until after I had already ordered a JTAG cable w/grabber kit that still hasn't arrived yet for like $10 off eBay).

http://img843.imageshack.us/img843/9178/c7dv.th.jpghttp://img15.imageshack.us/img15/1646/m435.th.jpghttp://img543.imageshack.us/img543/2346/mcf7.th.jpghttp://img801.imageshack.us/img801/2996/0ghf.th.jpg

Was getting ~5.8GH/s with default firmware (not sure why but was running pretty high straight from the factory, but also had what seems to be fairly high HW error rate, about 2%, so effective hash rate would actually be a bit lower). Flashed an unmodified 1.2.5 to it and now getting 8.1GH/s-8.3GH/s, depending on how many engines initialize and at what speed they initialize. Even more hardware errors now, though, looks like roughly 4%. Might be some other issue with my setup.

Going to try letting it cool down for a bit here sometime and seeing if I can get it to reinitialize at a higher hash. Looks like currently it's only initialized with 13 engines on on chip 3 and 14 engines on chip 7, but they are clocked super high, 305MHz for chip 3 and 296MHz for chip 7. The #define __ASIC_FREQUENCY_ACTUAL_INDEX should be whatever the default is, 7 right? I didn't realize it would clock them that aggressively.

Before I was getting about the same number of engines initializing, 13-14, and they were clocking at 190-200MHz I think (again depending on whether you were cold booting and starting up the unit after it had been running for a bit).

And it looks like my Jalapeno bit the dust. RIP.

Last night one of the ASICs seem to have stopped working, hash rate dropped down to ~4GH/s or so and only chip #7 was showing up when running java API stats. Then got home tonight and found the red status LED on the Jalapeno flashing quickly and cgminer unable to communicate with it.

Maybe I pushed the little guy too hard. Any ideas for reviving it or is it probably toast? Tried power cycling the unit but no luck. Going to leave it unplugged for a bit then try starting it up again and see if that does anything.

EDIT: Huh. Well that seemed to get it going again, at least for the time being. Still only recognizing processor 7, though, processor 3 no longer active and hashing.