Hi guys. While I was checking what the user Lincon wrote here in the forum about an issue that concerns the LSb/MSb setting is not honored when sending data in script mode:
I found that something is wrong with BASIC script mode because with the latest firmwares 09032019_OPT1_SAFE.hex and 09032019_OPT1_UNSAFE.hex (viewtopic.php?f=28&t=8498&start=120#p68332) based on the current repository the Bus Pirate resetting itself while running scripts, so that BASIC does not work anymore:
Hi guys. The user coelner has opened an issue on github about the failure of avrdude with the Bus Pirate and the firmware v7.x (U_1-05112018.hex and S_1-05112018.hex [ viewtopic.php?f=28&t=8498&start=120#p67834 ]):
Sadly I have not any chip to test this. I have avrdude-6.3-mingw32, AvrDude GUI v1.0, avrdudess_GUI_ 2.4-6.1 and avrdudess_GUI_2.6-6.3 but I need the chip... Is there somebody who can verify the thing or that know a revision of the firmware for the Bus Pirate which is surely working for him? This could be used for comparison. Thanks!
Hi guys. I noticed that while performing MACRO (1-50) which show the 8-byte ROM identifier of the device placed on the specific address chose, then the resulting final message does not match to the device on which the query was made. So for instance while querying for device 3 on the 1-WIRE bus by performing MACRO (3):
1-WIRE>(3)
Then the response show the device numbered as n+1, or 4 rather than 3 as actually it should be in this case:
I guess this behavior could be related to the fact that the numbering does not start from 0 because that is the purpose of MACRO (0) that on the Bus Pirate show the list of available macros, do not the 8-byte ROM of the device number 0 on the 1-WIRE bus, though I can very well be wrong.
Hi guys. If I have not misunderstood to enable Overdrive (~160kps) on the 1-WIRE devices that allow for it, not all 1-WIRE slaves support Overdrive (~160kps), it is need to send 0x69 (Overdrive Match ROM command) in normal speed followed by the 8-byte ROM identifier in overdrive speed or by sending 0x3c (Overdrive Skip ROM command) in normal speed. This one immediately puts all overdrive capable slaves on the bus into overdrive mode. Once a slave is in overdrive mode, all subsequent communication must take place at overdrive speed. (http://forum.arduino.cc/index.php?topic ... msg1486950) The Bus Pirate provide Overdrive (~160kps) support but (https://github.com/BusPirate/Bus_Pirate ... 4c968ba4e1) actually it can not use it because in order to do so would need to go from Standard (~16.3kbps) to Overdrive (~160kps) and the other way around, keeping active pull-ups and power supply, which is not currently allowed. In fact, once one of the two items has been set, Standard (~16.3kbps) or Overdrive (~160kps), to change it it is need to return to the menu with the "m" command, thus immediately making the power supply and the pull-up resistors are deactivated, therefore it is in no way possible to initialize the slave devices that support it in the Overdrive mode (~160kps). Even using externally powered external pull-up resistors it does not improve the thing, especially when working with emulated 1-WIRE slave devices, as this could result in the risk of damaging the Arduino board and or the Bus Pirate itself. In my opinion a solution would be to be able to switch from Standard (~16.3kbps) to Overdrive (~160kps) and the other way around without contextually deactivating power supply and pull-up resistors on the Bus Pirate side. I do not know if this is possible or not, even if it can be recommended, it is only a thought of mine that I want to share.
Hi guys. For your reference and knowledge: https://github.com/BusPirate/Bus_Pirate/issues/109 Sump is not working, just tested it. Old firmwares v5.10, v6.1, v6.2 and v6.3 are working fine while sadly instead since the very first release of the v7.0 it never worked, not even the upgrade provided here viewtopic.php?f=28&t=8498#p65290 and of course none of the firmwares I built and shared on the dangerousprototypes forum too. It is not a matter of client due the fact that the problem exists both with ols-0.9.8 and ols-0308 from Jawi which work like a charm with the firmwares mentioned above. Although the client fails to successfully start SUMP on Bus Pirate with firmware v7.x., metadata of the Bus Pirate on the client ols-0.9.8 are correctly acquired without any problem. The problem is that 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! By starting acquisition it does not start if not spontaneously after some time and ending with meaningless spurious patterns, something like as in attachment.
Hi guys. By testing 2WIRE protocol with the new firmware U_1-28102018 I built (viewtopic.php?f=28&t=8498&start=105#p67796) I found the same issues as for I2C SOFTWARE protocol. By choosing ~5KHz, ~50KHz or ~100KHz, does not matter what of them, the 2WIRE clock is alway about ~700Hz, while by choosing ~400KHz it is about ~200kHz that is the half of the value set.
Hi guys. By testing 3WIRE protocol with the new firmware U_1-28102018 I built (viewtopic.php?f=28&t=8498&start=105#p67796) I found the same issues as for I2C SOFTWARE protocol. By choosing ~5KHz, ~50KHz or ~100KHz, does not matter what of them, the 3WIRE clock is alway about ~700Hz, while by choosing ~400KHz it is about ~200kHz that is the half of the value set.
Hi guys. In order to investigate a weird behavior in the I2C protocol while using HARDWARE mode (https://github.com/BusPirate/Bus_Pirate/issues/54), I built a new firmware for my Bus Pirate v3 (viewtopic.php?f=28&t=8498&start=60#p66716) starting from the latest repository (https://github.com/BusPirate/Bus_Pirate ... master.zip). Inside the Bus_Pirate-master.zip archive, at the path Bus_Pirate-masterscripts, there is a C source named I2CEEPROMWIN.c from which I built the executable for Windows. Seems to me I2CEEPROMWIN.exe does not work as expected since always it fails while reading the starting address simply by omitting him and shifting up all the bytes towards the high putting in the end a dummy 0x00 value. Here is an example. This is the real content of the chip:
Also seems to me I2CEEPROMWIN.exe does not work while writing because although no alarm is displayed and indeed it is declared that everything is done successfully, actually the contents of the chip have not been altered in any way. From the source (I2CEEPROMWIN.c) the syntax is this:
That it is not clear as it states that the address must be 2 bytes, while actually using
I2CEEPROMWIN.exe com3 0 R TEST 2048 0000 I2CEEPROMWIN.exe com3 0 W TEST 2048 0000
or
I2CEEPROMWIN.exe com3 0 R TEST 2048 00 I2CEEPROMWIN.exe com3 0 W TEST 2048 00
It does not make any difference for the result. Maybe the fault it is due the syntax I use that is wrong, maybe it does not work anyway. Is there somebody here who can explain the thing? What it is wrong?
Hi guys. Is there somebody here who know the whole differences between SOFTWARE and HARDWARE mode in I2C protocol? I thought the only difference was about how synchronization is generated for the bus, but I am not sure it is just that. In fact in the recent past thanks to agatti it was possible to free the HARDWARE mode for the I2C protocol also with Bus Pirate v3 (https://github.com/BusPirate/Bus_Pirate/issues/39) but although in my device I have a silicon revision B8 (DEVID:0x0447 REVID:0x3046 = 24FJ64GA002 B8) I noticed a weird behavior. The weird thing is that while play I2C on a serial EEPROM using HARDWARE mode I can hit the chip only the first time, performing new access the answers are always wrong (0xFF). So, for example, while performing read of data from a given block of memory I get them right only the first time because by repeating the command I get wrong data as 0xFF. In order to fix I have to reset the Bus Pirate with command "#" and setting again all the I2C parameters. (Macro (1) always works also by repeating it). Instead using SOFTWARE mode I have not any problem performing all the commands I want without getting wrong answers. I know that due the different PIC used the Bus Pirate v4 has always had the HARDWARE mode unlocked as opposed to v3, which also depends on the silicon revision (http://ww1.microchip.com/downloads/en/D ... 00470j.pdf). Is there someone who owns the v4 and can confirm that it is the intended behavior? Otherwise it is very likely to be a bug. Thanks!
Hi guys. I have some questions about BASIC that maybe somebody of you, I think Sjaak for sure, is in the position to answer. I was able to build my own version of the firmware for the Bus Pirate v3 where all the features are unlocked, BASIC too (dangerousprototypes.com/forum/download/file.php?id=12196). In order to reach the goal among the other things I had to switch #define PGMSIZE 1024 to #define PGMSIZE 512. I do not understand some things. I wanted to verify the exact amount of the space of RAM available in BASIC. Seems to me that factory firmware v5.10 allows up 65535 lines for BASIC. I have downloaded the factory firmware v5.10 into my Bus Pirate revision 3, then I switched to BASIC where I put in a simple sequence of REM in order to evaluate how much room should be avalaible to storage scripts in BASIC. I was able to enter more than 700 program lines occupying 3kB into the RAM, but I could enter other lines apparently without any problem. So apparently by reserving 1024 bytes for the BASIC should be possible to enter more than that quantity of bytes, that it sounds weird. Indeed this does not match with the value 1024 that is used into #define PGMSIZE. I have not gone over and I have updated my Bus Pirate with the firmware v7.0 that I built. With it I was able to insert up 128 lines of program which are exactly 511 bytes, I could not go further. This match with the value 512 that I put into #define PGMSIZE. Now I know that although into both the firmwares v5.10 and the v7.0 that I built from myself BASIC was unlocked and command line up to 256 characters, the v7.0 that I built myself it has many unlocked features than v5.10, but I do not understand such a big gap based on using the value 1024 or its half. So my question is, is there some way to predict the exact amount of available space for BASIC by evaluating the features unlocked into the firmware before build it? Honestly I did not expect a real value of 32767 lines (half of 65535 lines), but not even a such big gap:
#define PGMSIZE 1024 (factory firmware v5.10) = over 3kB, I do not even know exactly what it actually is, I have not verified precisely.
#define PGMSIZE 512 (firmware v7.0 built by myself) = up 511 bytes, not one more.
Hi there, I'd like to know how to query SD cards in SD mode. By following some documents on the net I understood how to query them in SPI mode but I couldn't find any example about to do the same thing in SD mode. It exist some flow chart that shows how initialize SD cards in SPI mode but nothing for the SD mode. Actually SPI initialization and query is very simple, not so for SD mode. Is here somebody that can explain how to do it or even merely put a link to a document that explains it?
Hi there! Maybe this has already been written, so sorry. I wonder if bitbang mode can be gained also with simple terminal (Hyperterminal, Teraterm and so on). In mine when I tossed 0x00 20 times nothing happened. What's the trick? Thanks in advance and regards.
Hi there! I have to ask a question about the support to the family 25VFxxx by SST. From what I know starting from flashrom v0.9.7-r1764 was added support for the SST25VF020 and SST25VF020B chips. I need to work on those chips but sadly I was only able to get flashrom-v0.9.6.1-r1704 that works with Windows systems and it doesn't work with either SST25VF020 and SST25VF020B. Is there somewhere a newer version that work with Windows systems and supports both SST25VF020 and SST25VF020B? Thanks in advance and regards.
