agatti
commented
7 years ago @USBEprom can you please try past versions of the firmware to see whether the problem has always been there or if it's a new issue?
Closed USBEprom closed 6 years ago
agatti
commented
7 years ago @USBEprom can you please try past versions of the firmware to see whether the problem has always been there or if it's a new issue?
agatti
commented
7 years ago Incidentally, I tried to read a Microchip 24LC02B with my Bus Pirate v4 and I get the same result both in software and hardware modes, as long as the speed is less than 400kHz (as per datasheet).
USBEprom
commented
7 years ago @agatti
Thank you very much for your help sir! Since for what I know the only firmware for the Bus Pirate v3 which has the HARDWARE mode unlocked in the I2C protocol is what that I built by myself I can not test other releases. The firmwares I talking about are these:
http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&start=45#p66033
(built starting from the repository dated April 10, 2017)
and
http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&start=60#p66716
(built starting from the repository dated July 16, 2017)
Both two them have the issue I wrote but only while using HARDWARE mode. Instead when in SOFTWARE mode there are no problems, maybe Bus Pirate v4 behaves different. In my case the chip is a 24LC16 and it does not matter the speed. As per datasheet the chip is ranked 400kHz but actually it can also bear 1MHz speed, although for a single time because in HARDWARE mode the bug I wrote sadly it exists. It should be also considered that the facts that have emerged here are still valid:
https://github.com/BusPirate/Bus_Pirate/issues/39 https://github.com/BusPirate/Bus_Pirate/issues/23
So the timings for the HARDWARE mode are correct for all the speed into the menu, while for the SOFTWARE mode only the ~400kHz it is supposed to be so since its real value is about half of that (~200kHz)
Sorry I know nothing else. The only thing I can say is that due the HARDWARE mode into the I2C protocol has always been unlocked for the Bus Pirate v4, would be useful to test previous releases, of course factory version too.
agatti
commented
7 years ago Ok, I'll see what can be done. It'd help if I could get a logic analyser dump of the problem happening, but not just a screenshot but the signal dump so I could open the file in Logic and take a closer look at the timings and whatnot.
Unfortunately I still don't own a v3 board and the companies that still sell those boards don't seem to want to help its continued development, so it might take some time to sort this out I'm afraid.
We'll look into this for FW version 7.2, as software mode still works and we've been delaying the release for too much time already.
USBEprom
commented
7 years ago @agatti
OK sir, you are great! Thanks!!! Maybe I am wrong and actually it does not matter, but seems to me the problem only exists while doing sequential access. This because for instance by repeating [0xA0 9][0xA1 r][0xA2 9][0xA3 r] there is not any problem, while by doing the same with [0xA0 0][0xA1 r:37] it appears. Anyway here you go some of the captures I did:
I hope this is exactly what you asked for. If I misunderstood and it is not what you need, please feel free to let me know so that I can try to provide you the right thing. Thank you sir!
agatti
commented
7 years ago @USBEprom yes, the data is in the right format - thank you. I'll take a closer look at it this weekend.
marsfan
commented
7 years ago @agatti have you taken a look at sparkfun? Their board is a v3 with slight tweaks to the layout, and they seem to maintain support on it. I would guess that a majority of v3 boards sold today are because of them.
agatti
commented
7 years ago @Marsfan "Note: This product is a collaboration with Ian Lesnet. A portion of each sales goes back to them for product support and continued development." guess we should just close down shop then :)
marsfan
commented
7 years ago @agatti I don't think I follow. Ian is the original creator of the Bus Pirate, he works for Dangerous Prototypes, so it is logical that the product is licensed to him, I would guess that other companies pay a small portion of their BP sales to dangerous prototypes, if only to support them. I was just suggesting a site that still makes/supports the bus pirate.
agatti
commented
7 years ago @Marsfan fair enough, I was just sneering at the fact that money was still being paid for "product support and continued development", which in an ideal world would make this very project useless as DP would still fix firmware bugs and the like :) That said, maybe we're all better off to stick with technical issues only over here ;)
marsfan
commented
7 years ago @agatti I would not be surprised if that is something old that they are not aware about. Probably not worth bugging them over, I just wanted to select a good source for getting a v3. The only BP I have is that model, and it works like a charm with all of @USBEprom's builds.
USBEprom
commented
7 years ago @Marsfan
I agree. Since the PIC used in the Bus Pirate v3 has some problem requiring workarounds in order to gain I2C in HARDWARE mode, in my opinion it is really possible that it is something old that nobody has noticed until now, also because for what I know never it is existed any firmware for the v3 with natively unlocked I2C HARDWARE protocol. Someone should have compiled the firmware by himself finding the issue. Anyway due the HARDWARE mode into the I2C protocol has always been unlocked for the Bus Pirate v4, would be useful to know if at least one of the released firmwares it has not the problem.
agatti
commented
7 years ago @USBEprom can you please try to use the HW I2C on v3 now? I did some cleanups on those bits of code just now.
USBEprom
commented
7 years ago Sorry sir, I had and I have problems with the computer and only now I have seen your message. My bad! Because of this still now I can not build any new firmware with your changes because the computer where MPLAB is does not work and I have to repair it. Unfortunately I think it will be a long thing. I am really very sorry for all this.
agatti
commented
7 years ago @USBEprom no worries, if hardware mode on v3 doesn't work we'll get reports about that - I guess. However, if you happen to sort the issues out please give that a try and let us know!
USBEprom
commented
7 years ago @agatti
I am sorry to annoy. This afternoon I just got to restore my computer and now MPLAB works again. Then I tried to compile a new custom firmware from the current repository as it is today September 24, 2017, but unfortunately MPLAB gives me errors. I have errors even by using original configuration.h provided with the content of the repository and I have verified that by compiling a my backup of the repository dated July 20, 2017, it works, so I guess is not my MPLAB enviroment. As attachment I put the errors log I get while compiling option 1 and s with MPLABv3.65-XC16v1.31 that I am using. Thanks in advance.
agatti
commented
7 years ago Thanks for letting me know, I fixed the issue you've been experiencing. Please give it another shot when you've got the time.
USBEprom
commented
7 years ago @agatti
Thank you very much Sir, you are the best! I am sorry to keep annoy though. With the current September 25, 2017 repository I was able to build new customized firmwares using option 1 and option s but when I change line 382 and 391 inside the configuration.h file in order to unlock hardware mode for the I2C protocol, then MPLAB still gives me errors as shown in attachments:
O1.txt Os.txt configuration.h.txt (Please pay attention to the fact that in order to put here the configuration.h file I had to rename it as TXT)
Already in the past by myself I have built customized firmwares using the same setting in configuration.h as now and I have never had any problems in this regard. Sadly I guess there is still some problem somewhere. Thanks in advance.
NEWS.
@agatti
While testing the firmwares I just built I noticed that almost all the items in the menu are without options, which is pretty weird. Please take a look:
i 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>m
(1)>1 Clutch disengaged!!! Ready HiZ># RESET
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>m
(1)>2 Clutch disengaged!!! To finish setup, start up the power supplies with command 'W' Ready 1-WIRE># RESET
HiZ>m
(1)>3 Clutch disengaged!!! To finish setup, start up the power supplies with command 'W' Ready UART># RESET
HiZ>m
(1)>4 Clutch disengaged!!! To finish setup, start up the power supplies with command 'W' Ready I2C># RESET
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>m
(1)>5 Clutch disengaged!!! To finish setup, start up the power supplies with command 'W' Ready SPI># RESET
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> HiZ>m
(1)>6 Set speed:
(1)> Select output type:
(1)> Clutch disengaged!!! To finish setup, start up the power supplies with command 'W' Ready 2WIRE># RESET
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>m
(1)>7 Set speed:
(1)> CS:
(2)> Select output type:
(1)> Clutch disengaged!!! To finish setup, start up the power supplies with command 'W' Ready 3WIRE># RESET
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>m
(1)>8 Clutch disengaged!!! To finish setup, start up the power supplies with command 'W' Ready KEYB># RESET
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>m
(1)>9 This mode requires an adapter Clutch disengaged!!! To finish setup, start up the power supplies with command 'W' Ready LCD># RESET
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>m
(1)>10 Clutch disengaged!!! To finish setup, start up the power supplies with command 'W' Ready PIC> PIC># RESET
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>m
(1)>11 Clutch disengaged!!! To finish setup, start up the power supplies with command 'W' Ready DIO># RESET
Thanks in advance.
USBEprom
commented
6 years ago @agatti
Ok Sir, right now I am testing new firmware built starting from the latest repository dated January 07, 2018 and it seems that the problem into I2C protocol while in HARDWARE mode has been solved! Please, take a look at what follows:
i 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>m
(1)>4 I2C mode:
(1)>2 Set speed:
I do not know how and why but it is really gone, thank you very much Sir!
agatti
commented
6 years ago The only major change I can see on the I2C subsystem is building with Optimisation Level 1 by default, nothing much else. Oh well, if it works for you, that's still good to know!
Hi guys. Is there somebody here who know the differences between SOFTWARE and HARDWARE mode in I2C protocol? I thought the only one 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 doing thing on a I2C serial EEPROM via 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. Take a look at this:
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.4 DEVID:0x0447 REVID:0x3046 (24FJ64GA00 2 B8) http://dangerousprototypes.com HiZ>m
(1)>4 I2C mode:
(1)>2 Set speed:
In order to fix I have to reset the Bus Pirate with command "#" and setting again all the I2C parameters. Though 'Macro (1)' always works also by repeating it. Despite the second and subsequent times it does not work while reading, it does while writing although on the terminal is showing wrong characters (0xFF). Take a look at this:
I2C>[0xA0 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15]%:20[0xA0 16 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31]%:20[0xA0 32 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47]%:20[0xA0 48 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63]%:20 I2C START BIT WRITE: 0xA0 ACK WRITE: 0x00 ACK WRITE: 0x00 ACK WRITE: 0x01 ACK WRITE: 0x02 ACK WRITE: 0x03 ACK WRITE: 0x04 ACK WRITE: 0x05 ACK WRITE: 0x06 ACK WRITE: 0x07 ACK WRITE: 0x08 ACK WRITE: 0x09 ACK WRITE: 0x0A ACK WRITE: 0x0B ACK WRITE: 0x0C ACK WRITE: 0x0D ACK WRITE: 0x0E ACK WRITE: 0x0F ACK I2C STOP BIT DELAY 20ms I2C START BIT WRITE: 0xA0 ACK WRITE: 0x10 ACK WRITE: 0x10 ACK WRITE: 0x11 ACK WRITE: 0x12 ACK WRITE: 0x13 ACK WRITE: 0x14 ACK WRITE: 0x15 ACK WRITE: 0x16 ACK WRITE: 0x17 ACK WRITE: 0x18 ACK WRITE: 0x19 ACK WRITE: 0x1A ACK WRITE: 0x1B ACK WRITE: 0x1C ACK WRITE: 0x1D ACK WRITE: 0x1E ACK WRITE: 0x1F ACK I2C STOP BIT DELAY 20ms I2C START BIT WRITE: 0xA0 ACK WRITE: 0x20 ACK WRITE: 0x20 ACK WRITE: 0x21 ACK WRITE: 0x22 ACK WRITE: 0x23 ACK WRITE: 0x24 ACK WRITE: 0x25 ACK WRITE: 0x26 ACK WRITE: 0x27 ACK WRITE: 0x28 ACK WRITE: 0x29 ACK WRITE: 0x2A ACK WRITE: 0x2B ACK WRITE: 0x2C ACK WRITE: 0x2D ACK WRITE: 0x2E ACK WRITE: 0x2F ACK I2C STOP BIT DELAY 20ms I2C START BIT WRITE: 0xA0 ACK WRITE: 0x30 ACK WRITE: 0x30 ACK WRITE: 0x31 ACK WRITE: 0x32 ACK WRITE: 0x33 ACK WRITE: 0x34 ACK WRITE: 0x35 ACK WRITE: 0x36 ACK WRITE: 0x37 ACK WRITE: 0x38 ACK WRITE: 0x39 ACK WRITE: 0x3A ACK WRITE: 0x3B ACK WRITE: 0x3C ACK WRITE: 0x3D ACK WRITE: 0x3E ACK WRITE: 0x3F ACK I2C STOP BIT DELAY 20ms I2C>[0xA0 0][0xA1 r:256][0xA2 0][0xA3 r:256][0xA4 0][0xA5 r:256][0xA6 0][0xA7 r:256][0xA8 0][0xA9 r:256][0xAA 0][171 r:256][0xAC 0][0xAD r:256][0xAE 0][0xAF r:256] I2C START BIT WRITE: 0xA0 ACK WRITE: 0x00 ACK I2C STOP BIT I2C START BIT WRITE: 0xA1 ACK READ: 0x00 ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF NACK
Instead by 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!