It appears that you are reading your card in MSB format while it needs to be read in LSB order. In fact 0xC90xC4 0x08 0x89 is the ATR of the card even if actually 0xC9 MSB is equal to 0x93 LSB and not 0x92:
Hi guys. I took the trouble to analyze the behavior of the program with the help of the logic analyzer loaned to me by the usual friend of mine and I found the following. Once started, the program immediately initializes the Bus Pirate preparing it for reading / writing according to what is set in the command line, but it waits 8 minutes and 20 seconds to start reading / writing the chip! So actually the program is not as slow as it seems, it just waits for a long time before starting to do its job. It is not clear to me why such a long delay has been introduced (8 minutes and 20 seconds!), probably a typo or I do not know what else (could it be the compiler I use ? [MinGW & MinGW-W64], I do not think so, but I can not rule it out either and however, the timings are exact to the logic analyzer, so it remains a mystery to me). Decoding the I2C traffic with the logic analyzer it is obvious that, actually as already written by the author James Stephenson in his notes inside the C source, a 2 bytes addressing is used. This fact explains the behavior I detected when reading/writing a 24LC16 EEPROM, as this chip uses 1 byte addressing. I do not have a suitable chip available to verify the code but I must believe that it works correctly with chips that support 2 bytes addressing, as in the dangerousprototypes forum more than one user wrote that they used it without problems, even if there is the issue of 8 minutes and 20 seconds of waiting, which however may have been attributed to low clock rather than to a fixed delay:
So I took a look at the C source of the program, even if I totally have no skills as a programmer, and I noticed that on line 92 the command sleep (500) is entered. 500 seconds = 8 minutes and 20 seconds, bingo! That line is responsible for the 8 minutes and 20 seconds delay I mentioned in the opening, so I first modified it for 5 seconds of waiting and finally considering that time value too much, for a total of 3 seconds, that is:
92 sleep (3)
After that, I took care of line 24. In fact I had written in the first message that it is not clear at me what is meant with the phrase "the address must be 2 bytes", but now that it is I chose to change the related message in the command line. Then, since as I already wrote at the beginning the wording [chip addr 0-8] does not seem to make sense to me because in chips like 24FC64 the available blocks should be 8 numbered from 0 to 7 and not 9 numbered from 0 to 8, I also modified this message in line 24 and the code concerning it in line 28:
Once finished editing the C source, I compiled it to obtain the executables in 32bit and 64bit format that I enclose with the original and modified sources. As far as I can understand, the executables I have compiled work, but since I do not have adequate chips I can not fully test the result, if someone who can do it wants to try them and then report his impressions he is welcome, thanks!
Hi Ben100000. There you should read hexadecimal numbers, whether they are encrypted or plaintext. Maybe you have problems with connections to the DS2431 chip, or you have omitted something in the configuration of your Bus Pirate. Did you enabled PULL-UPs on your Bus Pirate? On your Bus Pirate are you using the STANDARD or OVERDRIVE speed? Which revision of the Bus Pirate are you using, 3 or 4? What firmware does your Bus Pirate have? Thanks.
It is surely possible to use his firmwares in order to do tests. The one he provides for the Bus Pirate v3 manages the I2C protocol only by firmware, it does not support it by hardware management and has the follow specifications:
I can not verify the one for the Bus Pirate v4. Please, pay attention to the fact that the ready to use hexadecimal files kindly provides by gdamjan are in lowercase format and therefore it is need to convert them to uppercase in order to use them with some Bus Pirate firmware update tools.
Thanks very much to gdamjan for the good idea and its brilliant implementation!
It would be nice to have a firmware with the JTAG fix from issue 134 in it, as it looks to be breaking reading the ChipID, chain length, etc.
Hi trcm and all. Here are firmwares busPirate-JTAG_SAFE_1.hex and busPirate_JTAG_UNSAFE_1.hex all of which have the JTAG fix from issue 134 (https://github.com/BusPirate/Bus_Pirate/issues/134) provided by Gabriel Smith as from his commit dated 21 May 2020 here:
Starting from https://github.com/BusPirate/Bus_Pirate/archive/dd7fbb0fedd27c08b9c33501ebbe4b28d8085cba.zip, firmwares busPirate-JTAG_SAFE_1.hex and busPirate_JTAG_UNSAFE_1.hex 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. As far as I can understand the repository already incorporates all the patches introduced up to the current date. Sadly at this moment I can not verify the functioning of the JTAG part, so I ask the courtesy at trcm or anyone else able to do it to try one of the two firmware and give a response, thanks.
About the SAFE and UNSAFE version, please also read these:
Attention please! First to attempt to use busPirate_JTAG_UNSAFE_1.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 Gabriel Smith for the fix he provided!!!
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.
I have a v3.6 Bus Pirate I bought a while ago that I'm only now getting started with. It has a v4.4 bootloader, but only v5.1 firmware. Are there any precompiled firmware files that I can use or would I need to compile them myself?
Here in this same thread in some previous posts there are several firmware for the Bus Pirate v3.x, the most updated ones are S_1-29092019.hex and U_1-29092019.hex you can find here:
Also, I think I saw somewhere there is a v4.5 bootloader. Would there be any reason for me to update that or should I be fine as I am?
That is correct, you saw right. Latest firmwares require the new bootloader v4.5 in order to be fully functioning. Without upgrading the bootloader to v4.5 it will not be possible to jump into bootloader from terminal using command $, so that instead it will be necessary to use jumper on PGD and PGC. If this is not a problem for you, you can very well leave it as it is and just update the firmware, there are no other contraindications than those described above. However, consider that updating the bootloader is no more complex than the firmware one and that several firmware releases that you find in this same thread in several previous posts incorporate both firmware and bootloader with instructions on how update each of them from Windows, Linux and Apple.
Sadly since the very first release of the v7.0, SUMP never worked, not even the upgrade provided here http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498#p65290 and of course none of the firmwares I built and shared on the dangerousprototypes forum too. Old firmwares v5.10, v6.1, v6.2 and v6.3 are working fine, though. As always tayken is right, the defect is due a problem while triggering, does not matter wich client is used, because the problem exists both with ols-0.9.8 and ols-0308 from Jawi. Acquisition does not start by honoring triggers settings and instead it activates itself spontaneously in an arbitrary way in its end displaying spurious signals on video also referred to disconnected inputs, namely inputs left free and therefore not physically connected to anything, floating.