Skip to main content ↑ ↓

Messages

This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.

Messages - Coldblackice

2
General discussion / Any recommendations for a good bench power supply?
I'm in the market to get a bench power supply, but am not sure which route to go. I'm willing to spend more if it's a quality tool that gives more value (and long-lasting) over a ~$75 supply, but I also have to acknowledge that I'm only a hobbyist, and don't necessarily need anything crazy. I've seen some decent looking ones on Amazon, despite knowing they're China-quality tools, but the top reviews on the best concern me.

I would love if there was a comparable to the Siglent 1104X oscilloscope, something that more or less is a widely agreed upon tool/recommendation. But I'm up for any suggestions, new or used tools.
3
Bus Pirate Development / Re: Bus Pirate - Community Firmware 7.0
Quote from: USBEprom on
Hi guys.
S_1-29092019.hex and U_1-29092019.hex are exactly the same S_1-28102018.hex and U_1-28102018.hex as before but rebuilt with the agatti fix in spi.c.
They were obtained by using the compression option "1" of MPLAB so to be in full agreement with the latest recommendations issued about the compilation of the repositories using MPLAB in order to build new firmwares for the Bus Pirate v3 and v4.
Compression option "1" assure right timing that option "s" may not ensure.
The only differences with the previous firmware S_1-28102018.hex and U_1-28102018.hex is that the original spi.c was patched with the agatti fix (the updated version of spi.c is in the compressed archive attached):

https://github.com/BusPirate/Bus_Pirate/issues/122#issuecomment-470428292

From the checks I made Bus Pirate works, flashrom works, avrdude works, all is working, but you use them at your own risk, I do not take any responsibility about the possibility of damaging your Bus Pirate or whatever, expecially talking about of the unsafe version!
About the SAFE and UNSAFE version, please also read this:

http://dangerousprototypes.com/forum/index.php?topic=8760.msg70072#msg70072

Attention please!
First to attempt to use U_1-29092019.hex (UNSAFE version of the firmware) you have to evaluate what is the silicon revision of the PIC used in your device, paying much attention to the fact that you might damage your device or whatever!
By doing it you must to assume all the responsibility for your action, even if actually should be no side effect in activating the Hardware I2C mode without honoring the silicon hardware revision of the PIC, because simply then it would not work.
There was a warning message in case the silicon hardware revision of the PIC had not been the expected one, but I do not know if this warning is still present and active in the nowaday new firmwares and I do not have a Bus Pirate wich has one of the buggy silicon revisions of the PIC in order to check it.
You use it at your own risk, I do not take any responsibility about the possibility of damaging your Bus Pirate or whatever!

Thanks a lot to agatti for having fixed the repository and freed the HARDWARE mode inside of I2C protocol!

Please note that both S_1-29092019.hex and U_1-29092019.hex were compiled with MPLAB-X IDE v5.00 and the XC-16 v1.35 compiler on Ubuntu 18.04 computer because the latest repositories are not natively compatible with MPLAB-X IDE v4.xx and earlier and both of them require the new bootloader v4.5 in order to work completely (http://dangerousprototypes.com/forum/index.php?topic=8498.0#p67056 and http://dangerousprototypes.com/forum/index.php?topic=8498.0#p67127).
Otherwise if do not, enter BOOTLOADER using command "$" will not work (https://github.com/BusPirate/Bus_Pirate/issues/58).
Actually it is not really a problem on the firmware side but rather of the bootloader.
In order to fix the matter it is need to upgrade the bootloader to the new revision v4.5:

http://dangerousprototypes.com/forum/index.php?topic=619.0#p67037

https://github.com/BusPirate/Bus_Pirate/issues/38

https://github.com/BusPirate/Bus_Pirate/issues/58

With the firmwares was also provided a pre configured environment that anyone can use with minimal changes to simplify the upgrade of the only firmware or together the bootloader and the firmware in a single step.
The archive also provides further improved instructions on how to use the whole thing under any operative system (Window, Linux and Apple), simply follow them:

"How to use UPGRADE_TO_BL_v4.5.bat.rtf" (specific instructions for Windows users)
"How to update with pirate-loader.rtf" (generic cross-platform instructions for Windows, Linux and Apple users)

Please note that the package is a 7z (7zip) archive because the maximum allowed size in the forum is 1 MiB.


Be seeing you.

U.Sb





Thanks USB, you are truly the hero Gotham deserves :D All your effort is much appreciated.

What firmware version are you currently preferring/choosing to use, out of curiosity?
4
Bus Pirate Development / Re: Bus Pirate - Community Firmware 7.0
Quote from: USBEprom on
I made two versions that i named 09032019_OPT1_SAFE.hex and 09032019_OPT1_UNSAFE.hex.
Both of them have all the features enabled, BASIC too, the command line allows up 256 characters.
...
Be seeing you.

U.Sb

Quote from: USBEprom on
Hi guys.
Today while I was doing some tests with some SPI memories I have sadly noticed that FLASHROM no longer works properly.
The latest working firmwares are version S_1-28102018.hex and U_1-28102018.hex which are located here:

http://dangerousprototypes.com/forum/index.php?topic=8498.msg67796#msg67796

All the firmwares released later do not work properly with FLASHROM probably due to some incompatibility introduced with the patch used to correct timing in the protocols 2-WIRE, 3-WIRE and 1-WIRE, as the culprit seems to be due to the management of delays:

https://github.com/BusPirate/Bus_Pirate/issues/23#issuecomment-435584095

Indeed, using the commands "&"  and "%" of the Bus Pirate directly from the terminal no delay is introduced as if they were ignored.
For its part FLASHROM in my case is able to read the chips but not to delete/write them.

Be seeing you.

U.Sb

U.Sb, you're doing the lord's work: thanks for all your effort + explaining/information. It's really appreciated.

On that note, I'm trying to get a handle on what's the latest development as far as these recent two posts of yours. In the first, are those SAFE + UNSAFE versions still valid? Are they the best to choose from in your opinion?

As for the issues with flashrom, prior versions of flashrom will still work with these latest firmwares, however, I'm assuming?
5
General discussion / ChipWhisperer?
Has anyone used or had any experience with a ChipWhisperer tool? Any chance that there are (or could be) any third-party/Chinese clones of these? Looking to do some hardware chip exploring/interfacing, and this seems like a great tool potentially
7
Open Bench Logic Sniffer / What's the best software for OLS? What do you use?
I've been looking around for a new logic analyzer, but as I have an OLS, I thought I would give it another try, despite hearing that it was abandoned a while back.

What's the best software to use for it? And the latest firmware? Any chance that it could work with Saleae software? I hear that the Chinese clones are able to, just not sure how that's done.
8
Bus Pirate Support / Re: Possible to diagnose an unresponsive hard drive?
[quote author="USBEprom"]Hi Coldblackice.
I am sorry for the problem you are dealing with.
Sadly I know nothing, so I can not to help, sorry.
However, Am I pushy if I ask if is it a self-powered external hard disk?
Thanks.

Be seeing you.

U.Sb[/quote]

Thanks USB, and no worries at all. It's an internal 4TB Red 3.5" internal drive. The painful irony is that it's an RMA replacement Western Digital sent me for a failed 3TB Red drive of theirs that stopped working >:( Extremely angry with them, and also the hard drive storage industry in general: I think it's absurd that we, the people, tolerate such high failure rates (relative to the other computer hardware) such as this. There's no way we'd tolerate RAM modules or CPUs suddenly dying not working as often as hard drives do. [/rant]

Anyway, I did recently buy two external WD 8TB drives and then shucked them, extracting the internal 8TB Red drives. Why do you ask?
9
Bus Pirate Support / Possible to diagnose an unresponsive hard drive?
Does anyone have experience or know-how for using the buspirate to diagnose Western Digital hard drive issues?

[BACKGROUND]
I have a Western Digital Red 3TB hard drive that suddenly stopped appearing in Windows and even BIOS, despite feeling the drive's motor power up just fine. I'm gutted about this since there was no warning or indication whatsoever via the drive's SMART data or any performance issues, and the drive wasn't overheated or physically touched or moved in any way at all.

Since I can still feel the drive's motor revving up when powered and there's also no clicking or beeping, I'm hoping this might possibly be a PCB issue, which I'm hoping I could fix or at least determine if it's the problem, so I could try finding another PCB to attempt a swap (after transferring the PCB data between the boards).

I've googled and found others attempting similar, but it seems to be with Seagate drives (and a common firmware bug with them). From what I've read, Seagate has an extensive debugging interface accessed through a hard drive's back diagnostic port, however, Western Digital drives do not have the same extensive diagnostic abilities through the port. Someone commented that WD's port is used just for flashing/dumping from the PCB's flash chip.

Any suggestions? Does anyone have experience diagnosing/troubleshooting a Western Digital PCB with a buspirate? Hopefully there's some debugging possibility through WD's port, so I can determine if the PCB is the issue... and not the drive heads or platters.

Thanks!
10
Bus Pirate Support / Re: Is there a command to read an entire chip at once?
Thanks USb, much obliged. I was hoping it might be possible to do a single command and then have the entire memory returned all at once at the terminal. I thought about doing a READ repeat for some super high number beyond what the chip would have, hoping that the read would stop once it reached the end of the chip's memory. But my experiment seemed to show that the READ will loop back around to the first byte of memory and continue.

Why am I wondering this? Mostly for my own future reference, but prompted by a task I'm working on, trying to troubleshoot/diagnose a Western Digital hard drive that suddenly won't appear in Windows or even BIOS anymore -- when trying to dump the drive's controller PCB's chip, Flashrom gets stuck trying to read the chip, BUT I can talk with the chip over the buspirate/putty manually just fine. I think maybe the chip isn't already pre-programmed into flashrom's database.

So I thought I'd do a manual read command in putty and then save the entire output bytes into a file (after cleaning up the hex formatting) and save that as the ROM output. I knew I could look up the chip and actually even had the datasheet already open, but I was hoping there was a simpler way to read an entire chip with a single command without needing to cross-reference any external data or sources. Thanks for the input + post reference!
11
Bus Pirate Support / Is there a command to read an entire chip at once?
Can the buspirate determine the size of a chip? Wondering if it's possible to determine the size of a flash/BIOS chip using just the terminal (putty) + manual commands without needing to cross-reference datasheets or use flashrom.

Secondly, is it possible to do a single READ command that reads (and prints) the entire chip's memory without needing to know the number of bytes the chip has and using that number for the repeat-function (e.g.,
Code: [Select]
[0x3 0 0 0 r:XXX]
)?
12
Bus Pirate Support / Re: "VREG TOO LOW, is there a short?"
Thanks USB, I appreciate it. Good to know about the 150mA. And also good to know about the possibility of relying on a mainboard to power a chip, and then tapping into it with a Bus Pirate while it's getting powered from its host. In my current situation, I have the chip fully removed from the board by itself, but that's something I'll have to try in the future for curiosity (and for future potential chips/projects).

That being said, correct, I do currently have the BIOS chip removed from the mainboard and attached to the Bus Pirate alone. I seem to have found a solution, though I'm not sure if this is a sign of damage: if I keep trying to turn on the power supply a few times in a row, it eventually turns on.

Any idea why this might be? Sometimes it takes two W's, and I believe other times 3. I hope I haven't unintentionally bypassed a protection mechanism by doing this and potentially damaged either the chip or the Bus Pirate :/

Code: [Select]
Ready
SPI>W
VREG too low, is there a short?
POWER SUPPLIES OFF
SPI>W
POWER SUPPLIES ON
Clutch engaged!!!
SPI>v
Pinstates:
1.(BR)  2.(RD)  3.(OR)  4.(YW)  5.(GN)  6.(BL)  7.(PU)  8.(GR)  9.(WT)  0.(Blk)
GND     3.3V    5.0V    ADC     VPU     AUX     CLK     MOSI    CS      MISO
P       P       P       I       I       I       O       O       O       I
GND     3.33V   4.85V   0.00V   0.00V   L       L       H       H       L


And for reference:

Code: [Select]
SPI>i
Bus Pirate v3.b clone w/different PIC
Community Firmware v7.1 - goo.gl/gCzQnW [HiZ 1-WIRE UART I2C SPI 2WIRE 3WIRE KEYB LCD PIC DIO] Bootloader v4.5
DEVID:0x044F REVID:0x3043 (24FJ64GA00 4 B5)
http://dangerousprototypes.com
CFG1:0xF9DF CFG2:0x3F7F
*----------*
Pinstates:
1.(BR)  2.(RD)  3.(OR)  4.(YW)  5.(GN)  6.(BL)  7.(PU)  8.(GR)  9.(WT)  0.(Blk)
GND     3.3V    5.0V    ADC     VPU     AUX     CLK     MOSI    CS      MISO
P       P       P       I       I       I       O       O       O       I
GND     3.33V   4.84V   0.00V   0.00V   L       L       L       L       L
POWER SUPPLIES ON, Pull-up resistors OFF, Open drain outputs (H=Hi-Z, L=GND)
MSB set: MOST sig bit first, Number of bits read/write: 8
a/A/@ controls AUX pin
SPI (spd ckp ske smp csl hiz)=( 1 0 1 0 0 1 )
*----------*

(I'm using a Sandbox Electronics authorized clone. I was a student with very little money at the time, otherwise I would've bought the normal version!)
13
Bus Pirate Support / "VREG TOO LOW, is there a short?"
I'm receiving this error, despite the self-test reporting everything as working/fine. I have the pirate hooked up to a BIOS chip, trying to talk with it over SPI.

Any ideas? I have a v3b sandbox electronics version, v7.1 firmware and v4.5 loader. Really frustrated trying to figure this out! Any help would be greatly appreciated
14
Bus Pirate Support / Is this JTAG-able?
I have a Samsung S3 phone that I need to downgrade from 4.4.2, which locks/prevents the use of custom bootloaders. I've seen some people that offer a service to JTAG-downgrade the bootloader, and so it seems that it's possible.

Would this be possible to do with the Bus Pirate? If so, how?

I realize it would be much slower than an actual JTAG device, of course. It's just all I have to work with at the moment.

( ! ) Fatal error: Uncaught exception 'Elk_Exception' with message 'Please try again. If you come back to this error screen, report the error to an administrator.' in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
( ! ) Elk_Exception: Please try again. If you come back to this error screen, report the error to an administrator. in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
Call Stack
#TimeMemoryFunctionLocation
10.01822470408session_write_close ( )...(null):0
20.01852602024ElkArte\sources\subs\SessionHandler\DatabaseHandler->write( )...(null):0
30.01862602800Database_MySQL->query( ).../DatabaseHandler.php:119
40.06332741560Database_MySQL->error( ).../Db-mysql.class.php:273