Skip to main content

Topics

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

Topics - USBEprom

1
Bus Pirate Support / "=X/|X Converts X/reverse X" no longer works.
Hi guys.
By testing "=X/|X  Converts X/reverse X" with firmware U_1-29092019.hex and S_1-29092019.hex I built (http://dangerousprototypes.com/forum/index.php?topic=8498.msg70165#msg70165) I found that it no longer works:

Bus Pirate v3.5
Community Firmware v7.1 - goo.gl/gCzQnW [HiZ 1-WIRE UART I2C SPI 2WIRE 3WIRE KEYB LCD PIC DIO] Bootloader v4.5
DEVID:0x0447 REVID:0x3046 (24FJ64GA00 2 B8)
http://dangerousprototypes.com
HiZ>|0x89
0x01 = 1 = 0b00000001
HiZ>=0x89
0x00 = 0 = 0b00000000
HiZ>


As far as I can understand from the repositories I have archived, the problem starts with releases S_1-28102018.hex and U_1-28102018.hex.
(http://dangerousprototypes.com/forum/index.php?topic=8498.msg67796#msg67796).

"=X/|X  Converts X/reverse X" in all the firmwares released later do not work properly.

Be seeing you.

U.Sb

https://github.com/BusPirate/Bus_Pirate/issues/154
2
Bus Pirate Development / Bus Pirate resetting itself while performing BASIC scripts.
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:

viewtopic.php?f=4&t=10260

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:

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

Be seeing you.

U.Sb
4
Bus Pirate Support / avrdude support broken.
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 ]):

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

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!

Be seeing you.

U.Sb
5
Bus Pirate Development / Problem with 1-WIRE MACRO (1)...MACRO (50).
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:

ADDRESS MACRO 4: 0x81 0x00 0xA0 0x90 0x19 0xDA 0x00 0x03

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.

(https://github.com/BusPirate/Bus_Pirate/issues/116)

Be seeing you.

U.Sb
6
Bus Pirate Development / Possible improvement for 1-WIRE protocol.
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.

(https://github.com/BusPirate/Bus_Pirate/issues/117)

Be seeing you.

U.Sb
7
Bus Pirate Development / Sump is not working.
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.

Be seeing you.

U.Sb
8
Bus Pirate Development / 2WIRE clock is not correct.
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.

https://github.com/BusPirate/Bus_Pirate/issues/111
https://github.com/BusPirate/Bus_Pirate/issues/23
https://github.com/BusPirate/Bus_Pirate/issues/39
9
Bus Pirate Development / 3WIRE clock is not correct.
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.

https://github.com/BusPirate/Bus_Pirate/issues/111
https://github.com/BusPirate/Bus_Pirate/issues/23
https://github.com/BusPirate/Bus_Pirate/issues/39

Be seeing you.

U.Sb
10
Bus Pirate Support / I2CEEPROMWIN.c (Bus_Pirate-master/scripts/)
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:

0x01 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x1F
0x02 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x2F
0x03 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x3F
0x04 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x4F

and this is what I2CEEPROMWIN.exe actually read:

0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x1F 0x02
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x2F 0x03
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x3F 0x04
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x4F 0x00

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:

pc_serial [com?] [chip addr 0-8] [R/W] [file] (read len) (mem addr)

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?

Thanks!

Be seeing you.

U.Sb
11
Bus Pirate Support / Questions about HARDWARE mode with I2C protocol
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!

Be seeing you.

U.Sb
12
Bus Pirate Support / Questions about how much is the room for BASIC scripting.
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.

Thanks.

Be seeing you.

U.Sb
13
Bus Pirate Support / How to query SD cards in SD mode?
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?
 
Thanks in advance and regards,
 
U.Sb
14
Bus Pirate Support / Bitbang mode and terminal program, how?
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.

Happy new year to everyones,

U.Sb
15
Flashrom / Win Flashrom v0.9.7-r1764 and SST25VF020/SST25VF020B.
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.
 
Happy new year to everyones,
 
U.Sb