jack44556677
New Member
I thought i would share my experience here in the hopes it might be useful to others, and to see if anyone can/would answer the questions i still have (despite ultimately succeeding) I struggled mightily to succeed and i'm hoping some of what I learned could help others avoid the same mistakes.
Firstly,
Open Questions (please chime in!) :
First I installed firrware v4.05 (spi), using flip, and the latest driver (libusb not winusb) from the RC19 v392 of the software. This seemed to be detected and I presumed/hoped would work correctly. I bought the cheapest soic 16 chip/test clip I could get my hands on ($7, $2+ if i wanted to wait for slow boat from china). If i did it again I would (at least) buy the $9 dollar one that came with cables attached, as I had to dangerously/recklessly bend the tiny pins in order to have the required room to connect standard dupont/breadboard connectors to them. Also fyi, the pins in the chip clip were not securely fastened and could be pushed up and down to protrude further or lesser out of the bottom of the connector.
Wrestling with the chip clip was tough, and although I could get it seated on the chip reasonably solidly - I do not know (without a schematic) how to verify that the leads were hooked up properly (and not shorting or connecting to undesired pins). With the chip clip side tips/tops flush against the chip/board - the chip legs/leads below were too small for me to get a multimeter probe in to check for continuity and/or shorting. By the end of this I had grown pretty accustomed to "that looks about right" and "what's the worst that could happen?". Is this the way it's done? Clip, jiggle, and pray until it works or you break something? I've seen D3m0n recommend abandoning the "convenience" of the chip clip for directly soldering leads several times...
After i got it hooked up / clipped to the chip and wired the way the manual instructed (with short test leads - apparently that is important. What happens when they are too long?) - with the notable exception of the vcc and hold pins on the chip clip which i connected to my bench psu set at 3.3v and a cautious 100ma (I think I may have tried 200ma for an instant too, just to see if it would still overdraw / short - which it did) and the chip clip ground hooked up to the negative of my power supply (my cheap power supply doesn't have a ground connector, or i would have tried that first). This didn't work. No chip detected and immediate hitting of the current limit which causes my psu (as a safety precaution) to drop the voltage to below the operating level of the chip.
Next I tried connecting the ground from the chip to the ground pin on the blackcat (leaving the power supply negative unconnected). The current meter in the psu showed no current while set this way (though it occurs to me that if there had been current, it proably wouuldn't be able to measure it with the negative disconnected anyhow). This also didn't work, no chip detected.
Desperate, and afraid one of my failed attempts had broken the chip, board, and/or blackcat, i tried using the modems normal power supply instead. I left the vcc, hold, and ground disconnected on the blackcat and the chip and tried again. Same result. Blackcat recognized but no chip detected. Then I connected the ground from the chip to the ground pin on the blackcat. Bingo. Something was detected, but with only a hex code identifier displayed. No ability to load scripts or interface, I hoped this was a fluke and not evidence that I had already broken one or more things beyond repair/use.
I tried again with the same setup. Again a device was detected, but it only had a hex code for an identifier and was clearly not supported by the firmware/software. However this time the hex code was different. I tried a few more times until i realized that the hex code identifying the chip was constantly changing and clearly junk data.
I did a quick sanity check, took the chip clip off and checked to see if the modem still booted as expected - which it, thankfully, did. I then went back to flip and flashed the 3.05 spi firmware that also comes with RC19 v392 thinking maybe that was the problem. I reconnected the chip as best I could, crossed my fingers, and let a rip.
The chip was identified! Hooray, or so i briefly thought. Looking at the read tab i saw nothing but junk data (I confirmed it was junk because it didn't remotely match an available full dump i found here, it was also mostly FF and wasn't static - it changed as i would scroll down and back up) and using the sb6121/sb6141 scripts (which dump twice and verify that they exactly match before saving them - the correct approach no matter what you are dumping) for reading always failed because the junk data was changing while dumping. At least the hex identifier for the chip was static - seemed like progress. I thought, "Maybe I just needed to go back to an earlier version of the firmware and software..." Looking back i think everything I saw was entirely a result of the chip clip not having good contact on the pins of the chip, but I am not 100% certain about this.
Skipping ahead, I tried several other previous versions of the software and firmwares. Each time it seemed like the dump was becoming more sane (though I now think this may have been a combination of luck and placebo) At one point simply changing the version of the driver in use (from one of the later libusb drivers to the earlier winusb drivers), and not even breathing towards the chip clip, made the "almost all ff" data look almost correct / matching with the good copy i had. Still the data was dynamically changing (I rationalized/guessed - maybe because the modem is fully powered and running - the vram values are changing - and this was to be expected. It is now my understanding that by supplying 3.3 to the hold pin (as even when disconnected from all external power the vcc pin on the chip was getting 3.3 from the modem power supplyy and the chip clip had a spliced wire connecting that and the hold pin even when not connected to anything else), this is not the case and the data ought to have been static)
I vaguely remembered that the 1.xx firmare versions were the ones that were out when I purchased the blackcat, and this lead me to use 1.09 (spi) and v275 (i did need to downgrade my driver version to the one included in v275). The dump was still much better / more sane, but obviously corrupted. I defeatedly thought, "maybe I had damaged the board" or, "maybe powering the board from the modem power supply is messing things up" but I now think it was always just the connection of the chip clip to the chip.
Recalling council given by d3m0n to other users with similar problems, I decided to be a little bolder (though not quite as bold as they had recommended - soldering the leads directly to the pins on the chip). I connected the chip clip again, doing my best to line it up by eye and making sure the tip/top of the clip was as flush against the board as possible. I tried again and got the best dump yet, but still with large FF blocks that shouldn't have been there and dynamically changing data.
I tried again, this time physically applying constant downward pressure on the chip clip and applying squeezing force to the two sides of the clip at the same time and tried reading again. For the first time ever - success! Elated, I let go of the chip clip and tried again - failure like before. I again manually held the clip down and on the chip sides and got my first full flash backup (the script i used ensured this was done twice and the dump verified to match exactly both times). Lactic acid building, I quickly flashed the forceware bin (3 something meg, not an 8 meg full image) to ufi1 and ufi2 and then took a final full image of the forceware loaded flash for good measure. You can imagine my excitement when the damn thing booted and ssh and webconfig were working as expected.
P.S. I'm not sure if they are false positives, but many of the downloaded software versions were detected as malware or worse by virustotal.com. I only used versions of the software that tested clean (but of course,, conversely, this is also not a guarantee that the software is clean). Also several of the software versions downloaded from this site are corrupt and certain files cannot be extracted as a result (including the software executable itself in at least one instance).
Also, I am not certain, but at some point with flashware 4.05 (spi) using the v392 software would not display a firmware version (showed blank) - but appeared to work anyway. This may have been due to the driver being used being older than the one supplied with v392 - but i haven't gone back and confirmed that.
Thanks for reading!
Firstly,
Open Questions (please chime in!) :
- @D3m0n and/or other admins/developers - especially now that these 1.x boards are no longer supported, could you please share the atmel firmware source code for them (i saw in a thread that you had done this by PM in the past)? How about schematics (if i may be so bold)?
- I need to cross compile a c++ application for this device and install it to autoboot on the modem. Can someone point me in the right direction to accomplish that? It seems /var/local/bin is read only no matter what I do (though I haven't tried changing any permissions yet). Will i have to make a custom firmware in order to accomplish this? Any direction on this would be greatly appreciated. The datasheet for the processor says it is mips, but forceware seems to say it's armv6....
- What software version is the latest that supports the 1.x boards properly? I downloaded every version available here and on archive.org and I think it is v392 (RC19). If they are not the same, what is the best/most reliable version to use? Same goes for the question below - is one better for 1.2 vs 1.7 vs 1.8?
- What version of the firmware is the best to use on the 1.x boards (and does the answer differ with particular version of 1.x board, eg v1.2, v1.7, v1.8). The latest one in the 392 package is v4.05 for spi, v2.01 for nand, and v7.05 for jtag. I ended up having so much trouble that I finally succeeded with v275 and v1.09 (spi), but I am not sure this was absolutely necessary (I was grasping at straws and throwing the kitchen sink at it). Same question for the driver as well (i presume the best driver to use is the one that is bundled with the BCUSB/FCUSB software version you retrieve the firmware from... is that right?)
- I've read that boards less than v2.2 have issues with supplying power to chips in circuit (which especially makes sense when usb 2.0 can only supply a max of 500ma), and using an external power supply was recommended instead. I have a benchtop psu but i didn't know how to wire it up or what max current to set to prevent potential damage. Does the positive go to vcc/hold (and optionally WP) on the chip and the ground of the chip go to the negative of the psu (leaving the blackcat with a floating/unconnected ground pin)? Or the negative from the psu to the blackcat ground? Or the ground from the chip to the blackcat and the power supply negative floating/unconnected? In my struggles i eventually gave up on the external power supply (I wasn't comfortable blindly giving the chip serious currrents, and i cautiously gave as much as 100ma - but it always hit the maximum current and dropped the voltage down immediately whenever i connected the positive and negative directly to the chip - and no draw when I left the power supply negative unconnected) and used the power supply of the modem itself to power the entire board. I found that if the ground from the chip to the ground of the blackcat was not connected, no flash could ever be identified.
- No matter what I could not get any version of the software to identify and flash the firmware itself - is there some "install dfu driver" step I missed to make that function work from inside the BC/FCUSB software? I had no choice but to install flip (and its ancient v5 jre) in order to flash the board.
First I installed firrware v4.05 (spi), using flip, and the latest driver (libusb not winusb) from the RC19 v392 of the software. This seemed to be detected and I presumed/hoped would work correctly. I bought the cheapest soic 16 chip/test clip I could get my hands on ($7, $2+ if i wanted to wait for slow boat from china). If i did it again I would (at least) buy the $9 dollar one that came with cables attached, as I had to dangerously/recklessly bend the tiny pins in order to have the required room to connect standard dupont/breadboard connectors to them. Also fyi, the pins in the chip clip were not securely fastened and could be pushed up and down to protrude further or lesser out of the bottom of the connector.
Wrestling with the chip clip was tough, and although I could get it seated on the chip reasonably solidly - I do not know (without a schematic) how to verify that the leads were hooked up properly (and not shorting or connecting to undesired pins). With the chip clip side tips/tops flush against the chip/board - the chip legs/leads below were too small for me to get a multimeter probe in to check for continuity and/or shorting. By the end of this I had grown pretty accustomed to "that looks about right" and "what's the worst that could happen?". Is this the way it's done? Clip, jiggle, and pray until it works or you break something? I've seen D3m0n recommend abandoning the "convenience" of the chip clip for directly soldering leads several times...
After i got it hooked up / clipped to the chip and wired the way the manual instructed (with short test leads - apparently that is important. What happens when they are too long?) - with the notable exception of the vcc and hold pins on the chip clip which i connected to my bench psu set at 3.3v and a cautious 100ma (I think I may have tried 200ma for an instant too, just to see if it would still overdraw / short - which it did) and the chip clip ground hooked up to the negative of my power supply (my cheap power supply doesn't have a ground connector, or i would have tried that first). This didn't work. No chip detected and immediate hitting of the current limit which causes my psu (as a safety precaution) to drop the voltage to below the operating level of the chip.
Next I tried connecting the ground from the chip to the ground pin on the blackcat (leaving the power supply negative unconnected). The current meter in the psu showed no current while set this way (though it occurs to me that if there had been current, it proably wouuldn't be able to measure it with the negative disconnected anyhow). This also didn't work, no chip detected.
Desperate, and afraid one of my failed attempts had broken the chip, board, and/or blackcat, i tried using the modems normal power supply instead. I left the vcc, hold, and ground disconnected on the blackcat and the chip and tried again. Same result. Blackcat recognized but no chip detected. Then I connected the ground from the chip to the ground pin on the blackcat. Bingo. Something was detected, but with only a hex code identifier displayed. No ability to load scripts or interface, I hoped this was a fluke and not evidence that I had already broken one or more things beyond repair/use.
I tried again with the same setup. Again a device was detected, but it only had a hex code for an identifier and was clearly not supported by the firmware/software. However this time the hex code was different. I tried a few more times until i realized that the hex code identifying the chip was constantly changing and clearly junk data.
I did a quick sanity check, took the chip clip off and checked to see if the modem still booted as expected - which it, thankfully, did. I then went back to flip and flashed the 3.05 spi firmware that also comes with RC19 v392 thinking maybe that was the problem. I reconnected the chip as best I could, crossed my fingers, and let a rip.
The chip was identified! Hooray, or so i briefly thought. Looking at the read tab i saw nothing but junk data (I confirmed it was junk because it didn't remotely match an available full dump i found here, it was also mostly FF and wasn't static - it changed as i would scroll down and back up) and using the sb6121/sb6141 scripts (which dump twice and verify that they exactly match before saving them - the correct approach no matter what you are dumping) for reading always failed because the junk data was changing while dumping. At least the hex identifier for the chip was static - seemed like progress. I thought, "Maybe I just needed to go back to an earlier version of the firmware and software..." Looking back i think everything I saw was entirely a result of the chip clip not having good contact on the pins of the chip, but I am not 100% certain about this.
Skipping ahead, I tried several other previous versions of the software and firmwares. Each time it seemed like the dump was becoming more sane (though I now think this may have been a combination of luck and placebo) At one point simply changing the version of the driver in use (from one of the later libusb drivers to the earlier winusb drivers), and not even breathing towards the chip clip, made the "almost all ff" data look almost correct / matching with the good copy i had. Still the data was dynamically changing (I rationalized/guessed - maybe because the modem is fully powered and running - the vram values are changing - and this was to be expected. It is now my understanding that by supplying 3.3 to the hold pin (as even when disconnected from all external power the vcc pin on the chip was getting 3.3 from the modem power supplyy and the chip clip had a spliced wire connecting that and the hold pin even when not connected to anything else), this is not the case and the data ought to have been static)
I vaguely remembered that the 1.xx firmare versions were the ones that were out when I purchased the blackcat, and this lead me to use 1.09 (spi) and v275 (i did need to downgrade my driver version to the one included in v275). The dump was still much better / more sane, but obviously corrupted. I defeatedly thought, "maybe I had damaged the board" or, "maybe powering the board from the modem power supply is messing things up" but I now think it was always just the connection of the chip clip to the chip.
Recalling council given by d3m0n to other users with similar problems, I decided to be a little bolder (though not quite as bold as they had recommended - soldering the leads directly to the pins on the chip). I connected the chip clip again, doing my best to line it up by eye and making sure the tip/top of the clip was as flush against the board as possible. I tried again and got the best dump yet, but still with large FF blocks that shouldn't have been there and dynamically changing data.
I tried again, this time physically applying constant downward pressure on the chip clip and applying squeezing force to the two sides of the clip at the same time and tried reading again. For the first time ever - success! Elated, I let go of the chip clip and tried again - failure like before. I again manually held the clip down and on the chip sides and got my first full flash backup (the script i used ensured this was done twice and the dump verified to match exactly both times). Lactic acid building, I quickly flashed the forceware bin (3 something meg, not an 8 meg full image) to ufi1 and ufi2 and then took a final full image of the forceware loaded flash for good measure. You can imagine my excitement when the damn thing booted and ssh and webconfig were working as expected.
P.S. I'm not sure if they are false positives, but many of the downloaded software versions were detected as malware or worse by virustotal.com. I only used versions of the software that tested clean (but of course,, conversely, this is also not a guarantee that the software is clean). Also several of the software versions downloaded from this site are corrupt and certain files cannot be extracted as a result (including the software executable itself in at least one instance).
Also, I am not certain, but at some point with flashware 4.05 (spi) using the v392 software would not display a firmware version (showed blank) - but appeared to work anyway. This may have been due to the driver being used being older than the one supplied with v392 - but i haven't gone back and confirmed that.
Thanks for reading!
Last edited: