search

BusPirate / Bus_Pirate

Community driven firmware and hardware for Bus Pirate version 3 and 4
625 stars 130 forks source link

Test hardware I2C on a v3 board with an A3/A4 or older MCU revision. #39

Closed agatti closed 7 years ago

agatti commented 7 years ago

Dangerous Prototypes' original firmware did not use hardware I2C due to hardware bugs in PIC24FJ64GA004 chips with revision A3 or A4.

Now that hardware I2C is enabled again and the appropriate workarounds detailed here have been applied, we need to test those on real hardware.

The catch: the code is experimental and it may or may not mess up with your hardware, just in case.

To test it, find out if your board is running one of those chips by using the i command, and if so make sure that BP_I2C_USE_HW_BUS is defined for Bus Pirate v3 in your copy of configuration.h, rebuild, and stress test I2C read/write/etc capabilities on the board.

USBEprom commented 7 years ago

Thank you very much sir. The answer at the command "i" of my Bus Pirate is this:

HiZ>i Bus Pirate v3.5 Community Firmware v7.0 - goo.gl/gCzQnW [HiZ 1-WIRE UART I2C SPI 2WIRE 3WIRE KEYB LCD PIC DIO] Bootloader v4.4 DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8) http://dangerousprototypes.com HiZ>

Before trying what you have suggested I must read well the documentation you provided because I fear to brick my Pus Pirate. When I will have understood well all the matter, then I will.

USBEprom commented 7 years ago

@agatti

OK, my Bus Pirate revision 3 uses a 24FJ64GA002-B8 which does not need any work around while in I2C mode, being it has not bug in that context. The PIC 24FJ64GA002-B8 only has the UART bug for which there is no work around, but that is another story. The weird thing is that you wrote to make sure that BP_I2C_USE_HW_BUS be defined into configuration.h but actually for what I can see it always has been so. I mean that into all the firmwares I built by myself the parameter BP_I2C_USE_HW_BUS was always already defined without the need to change it. That then honestly I have never read any document where it was suggested to change it. However my hardware has not the I2C bug so that likely it does not matter, but what could have happened if the PIC inside my unit was a revision A3 or A4? Just out of curiosity. I have downloaded all the stuff and I am going to build a new test firmware. later I will post the results. Thank you sir and happy new year!

News. Trying to build the test firmware while all the features are flagged, BASIC is active too and command line allow up 256 characters, which is the usual setting that I use into the configuration.h, I can not do the job. MPLAB gives me this message:

CLEAN SUCCESSFUL (total time: 60ms) make -f nbproject/Makefile-BusPirate_v3.mk SUBPROJECTS= .build-conf make[1]: Entering directory 'F:/MPLAB/Bus_Pirate-master31122016/Bus_Pirate-master/Firmware/busPirate.X' make -f nbproject/Makefile-BusPirate_v3.mk dist/BusPirate_v3/production/busPirate.X.production.hex make[2]: Entering directory 'F:/MPLAB/Bus_Pirate-master31122016/Bus_Pirate-master/Firmware/busPirate.X' "F:\MPLABX\XC16\bin\xc16-gcc.exe" ../1wire.c -o build/BusPirate_v3/production/_ext/1472/1wire.o -c -mcpu=24FJ64GA002 -MMD -MF "build/BusPirate_v3/production/_ext/1472/1wire.o.d" -g -omf=elf -DXPRJ_BusPirate_v3=BusPirate_v3 -no-legacy-libc -mlarge-code -mlarge-data -O1 -I"../../microchip/include" -I".." -I"../translations" -mcci -msmart-io=1 -Werror -Wall -msfr-warn=off -save-temps -finline "F:\MPLABX\XC16\bin\xc16-gcc.exe" ../base.c -o build/BusPirate_v3/production/_ext/1472/base.o -c -mcpu=24FJ64GA002 -MMD -MF "build/BusPirate_v3/production/_ext/1472/base.o.d" -g -omf=elf -DXPRJ_BusPirate_v3=BusPirate_v3 -no-legacy-libc -mlarge-code -mlarge-data -O1 -I"../../microchip/include" -I".." -I"../translations" -mcci -msmart-io=1 -Werror -Wall -msfr-warn=off -save-temps -finline "F:\MPLABX\XC16\bin\xc16-gcc.exe" ../baseIO.c -o build/BusPirate_v3/production/_ext/1472/baseIO.o -c -mcpu=24FJ64GA002 -MMD -MF "build/BusPirate_v3/production/_ext/1472/baseIO.o.d" -g -omf=elf -DXPRJ_BusPirate_v3=BusPirate_v3 -no-legacy-libc -mlarge-code -mlarge-data -O1 -I"../../microchip/include" -I".." -I"../translations" -mcci -msmart-io=1 -Werror -Wall -msfr-warn=off -save-temps -finline "F:\MPLABX\XC16\bin\xc16-gcc.exe" ../basic.c -o build/BusPirate_v3/production/_ext/1472/basic.o -c -mcpu=24FJ64GA002 -MMD -MF "build/BusPirate_v3/production/_ext/1472/basic.o.d" -g -omf=elf -DXPRJ_BusPirate_v3=BusPirate_v3 -no-legacy-libc -mlarge-code -mlarge-data -O1 -I"../../microchip/include" -I".." -I"../translations" -mcci -msmart-io=1 -Werror -Wall -msfr-warn=off -save-temps -finline nbproject/Makefile-BusPirate_v3.mk:317: recipe for target 'build/BusPirate_v3/production/_ext/1472/basic.o' failed make[2]: Leaving directory 'F:/MPLAB/Bus_Pirate-master31122016/Bus_Pirate-master/Firmware/busPirate.X' nbproject/Makefile-BusPirate_v3.mk:84: recipe for target '.build-conf' failed make[1]: Leaving directory 'F:/MPLAB/Bus_Pirate-master31122016/Bus_Pirate-master/Firmware/busPirate.X' nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed ../basic.c: In function 'bp_basic_enter_interactive_interpreter': ../basic.c:1360:7: error: 'BPMSG1052' undeclared (first use in this function) ../basic.c:1360:7: note: each undeclared identifier is reported only once for each function it appears in make[2]: [build/BusPirate_v3/production/_ext/1472/basic.o] Error 255 make[1]: [.build-conf] Error 2 make: *** [.build-impl] Error 2

BUILD FAILED (exit value 2, total time: 120ms)

32122016.txt

I can build the firmware only without changes into the configuration.h, so I have used the default one provided with the Bus_Pirate-master.zip. Next I will post how it works.

I do not want to abuse of your patience, but I have a doubt. I am babo as hell but seems to me that into the "Project Properties" of MPLAB while I choose "Optimizations" with this latest repository on the label "Do not override 'inline'" there is an automatically flag.

mplab

What "Do not override 'inline'" does and how it is supposed to be set correctly? Of course if you know, that it is highly probable. Thanks.

Latest news. Here is how it is now the menu of the firmware test:

Bus Pirate v3.5 Community Firmware v7.1 - goo.gl/gCzQnW [HiZ UART I2C SPI] Bootloader v4.4 DEVID:0x0447 REVID:0x3046 (24FJ64GA00 2 B8) http://dangerousprototypes.com HiZ>m

  1. HiZ
  2. UART
  3. I2C
  4. SPI x. exit(without change)

(1)>3 Set speed:

  1. ~5KHz
  2. ~50KHz
  3. ~100KHz
  4. ~400KHz

(1)>4 Clutch disengaged!!! To finish setup, start up the power supplies with command 'W' Ready I2C>

There is no trace of the new entries, am I wrong? The next step will be evaluate the clock speed into I2C mode.

OK, now it is the time. Here are the results:

cb036676-ce16-11e6-88d1-719459ee8eb9

For this report I have used ~400kHz in accordance with your settings. How it is possible to see the answer of macro (1) is 0xA0(0x50 W).

~400kHz

Bus Pirate v3.5 Community Firmware v7.1 - goo.gl/gCzQnW [HiZ UART I2C SPI] Bootloader v4.4 DEVID:0x0447 REVID:0x3046 (24FJ64GA00 2 B8) http://dangerousprototypes.com HiZ>

m

  1. HiZ
  2. UART
  3. I2C
  4. SPI x. exit(without change)

(1)>3 Set speed:

  1. ~5KHz
  2. ~50KHz
  3. ~100KHz
  4. ~400KHz

(1)>4 Clutch disengaged!!! To finish setup, start up the power supplies with command 'W' Ready I2C>W POWER SUPPLIES ON Clutch engaged!!! I2C>P Pull-up resistors ON I2C>(1) Searching I2C address space. Found devices at: 0xA0(0x50 W)

I2C>{0xA0 0xFF}{0xA1 r r} I2C START BIT WRITE: 0xA0 ACK WRITE: 0xFF ACK I2C STOP BIT I2C START BIT WRITE: 0xA1 ACK READ: 0x55 READ: ACK 0xFF NACK I2C STOP BIT I2C>

01012017

Thanks and happy new year!

agatti commented 7 years ago

Ok, I believe you just ran software I2C, and your clock speed was twice as what I got from my v4 board (222kHz vs 111kHz).

BP_I2C_USE_HW_BUS is by default defined only for v4 boards:

#ifdef BUSPIRATEV4

/**
 * Enable usage of the on-board hardware I2C bus.
 *
 * This is mandatory on Bus Pirate v4 hardware, optional on v3.
 */
#define BP_I2C_USE_HW_BUS

#endif /* BUSPIRATEV4 */

means that BP_I2C_USE_HW_BUS is only available for v4. If you remove both #ifdef BUSPIRATEV4 and #endif /* BUSPIRATEV4 */ then it will enable Hardware/Software selection also for v3. You can check if you did it correctly if the board prompts you for whether to use hardware or software I2C before asking you which speed settings to use.

About "Do not override 'inline'" - that has been enabled to speed up some operations so it has to stay ON. The only drawback is that it might make code slightly bigger - however not by much.

agatti commented 7 years ago

Also, sorry for the compilation failure, I moved a string too many to the v4 messages file - it should be fixed now.

USBEprom commented 7 years ago

@ agatti

Thank you sir for your tireless work. You are teaching me a lot! OK for the "Do not override 'inline'" label in MPLAB, I understood it. Though, do you mind another question just for be safe? I know I make a bunch of questions, but if possible I would like to know out which are the settings that you are using for the optimizations into MPLAB while you are compiling firmwares by yourself. settings So:

Do not override 'inline': [FLAG] or [NOT FLAG]? Unroll loop: [FLAG] or [NOT FLAG]? Omit frame pointer: [FLAG] or [NOT FLAG]? Unlimited procedure abstraction: [FLAG] or [NOT FLAG]? Procedural abstraction level: [FLAG] or [NOT FLAG]? Align arrays: [FLAG] or [NOT FLAG]?

Thanks!

However, going so far, I just downloaded the latest repository in order to take a chance of build a new test firmware. I made all the changes I need for, included enabling the Hardware/Software selection also for Bus Pirate v3 by changing the parameters for BP_I2C_USE_HW_BUS. I can not do the job because MPLAB still gives some errors. I have tried switching flag for the "Do not override 'inline'" into optimizations panel of MPLAB and I saw that the error messages are different based on if that parameter is flag or it does not. Here are the error messages split by flag and does not flag of the "Do not override 'inline'" parameter and also the configuration.h that I have used while I tried: ERRORS.txt configuration.h.TXT (Pay attention at the fact that "github" does not allow me to attach configuration.h, not even by compressing it as zip, so I had to change its extension as txt.)

I'm really sorry to still bother you sir. Thanks!

agatti commented 7 years ago

From your configuration.h file:

/** #ifdef BUSPIRATEV4

/**
 * Enable usage of the on-board hardware I2C bus.
 *
 * This is mandatory on Bus Pirate v4 hardware, optional on v3.
 */
#define BP_I2C_USE_HW_BUS

/** #endif /* BUSPIRATEV4 */

You forgot to close the comment for #ifdef BUSPIRATEV4. For now please use // to comment out those lines.

Regarding optimisation, I have optimisation level set to '0' and all I have on is just "Do not override 'inline'". The rest is all empty or disabled.

USBEprom commented 7 years ago

@ agatti

Thank you sir! You are really the greatest! Daebak! Ok, still you won while I am totally babo for true. It was exactly like you wrote. Now configuration.h is this: configuration.h.TXT (Pay attention at the fact that "github" does not allow me to attach configuration.h, not even by compressing it as zip, so I had to change its extension as txt.) Of course now I have been able to build the testing firmware. As you have suggested I have put flag only on "Do not override 'inline'" leaving the rest empty or disabled just like you are used to do. For Bus Pirate revision 3 optimizations 0, 2 and 3 are run out of space, the only valid ones are 1 and s, so i built by using them. Here you go the results of the tests that I made using ~400kHz as speed clock for the I2C bus. Still I used the Arduino in order to simulate the I2C bus.

cb036676-ce16-11e6-88d1-719459ee8eb9

As it is possible to see the answer at macro (1) is 0xA0(0x50 W).

~400kHz Software

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.4 DEVID:0x0447 REVID:0x3046 (24FJ64GA00 2 B8) http://dangerousprototypes.com HiZ>m

  1. HiZ
  2. 1-WIRE
  3. UART
  4. I2C
  5. SPI
  6. 2WIRE
  7. 3WIRE
  8. KEYB
  9. LCD
  10. PIC
  11. DIO x. exit(without change)

(1)>4 I2C mode:

  1. Software
  2. Hardware

(1)>1 Set speed:

  1. ~5KHz
  2. ~50KHz
  3. ~100KHz
  4. ~400KHz

(1)>4 Clutch disengaged!!! To finish setup, start up the power supplies with command 'W' Ready I2C>W POWER SUPPLIES ON Clutch engaged!!! I2C>P Pull-up resistors ON I2C>(1) Searching I2C address space. Found devices at: 0xA0(0x50 W)

I2C>{0xA0 0xFF}{0xA1 r r} I2C START BIT WRITE: 0xA0 ACK WRITE: 0xFF ACK I2C STOP BIT I2C START BIT WRITE: 0xA1 ACK READ: 0x55 READ: ACK 0xFF NACK I2C STOP BIT I2C>

Software 400kHz.txt

software 400khz

400kHz Hardware

HiZ>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.4 DEVID:0x0447 REVID:0x3046 (24FJ64GA00 2 B8) http://dangerousprototypes.com HiZ>m

  1. HiZ
  2. 1-WIRE
  3. UART
  4. I2C
  5. SPI
  6. 2WIRE
  7. 3WIRE
  8. KEYB
  9. LCD
  10. PIC
  11. DIO x. exit(without change)

(1)>4 I2C mode:

  1. Software
  2. Hardware

(1)>2 Set speed:

  1. 100KHz
  2. 400KHz
  3. 1MHz (1)>2 Clutch disengaged!!! To finish setup, start up the power supplies with command 'W' Ready I2C>W POWER SUPPLIES ON Clutch engaged!!! I2C>P Pull-up resistors ON I2C>(1) Searching I2C address space. Found devices at: 0xA0(0x50 W)

I2C>{0xA0 0xFF}{0xA1 r r} I2C START BIT WRITE: 0xA0 ACK WRITE: 0xFF ACK I2C STOP BIT I2C START BIT WRITE: 0xA1 ACK READ: 0x55 READ: ACK 0xFF NACK I2C STOP BIT I2C>

Hardware 400kHz.txt

hardware 400khz

Seems like in Software mode the real values for the speeds are roughly the half of their setting shown into the menu. This is the same behavior as with firmware revisions prior to applying the patch #23. With this firmware it seems that I2C is working just like prior the applying of the patch #23 and better due the fact now it is possible also to choose between Software and Hardware implementation of the I2C protocol. I will test that everything is OK, then I will post the response. But, however it will end, I do not know if I can drop this firmware to third, because based on what you wrote perhaps there may be risks with some Bus Pirate which uses PIC in revision A3 or A4. I will do not share the firmware with anyone until it will be sure that it is safe. In the meanwhile in my head I have already some question. Basically the question is if could be possible to share speed among Software and Hardware setting. What I mean is that for Software setting the available speeds are

  1. ~5KHz
  2. ~50KHz
  3. ~100KHz
  4. ~400KHz

while for the Hardware ones they are

  1. 100KHz
  2. 400KHz
  3. 1MHz

but some devices do not stand high speeds and other do it. So what about implementing all the speeds for both settings, either Software than Hardware? Something like this:

Software I2C

  1. ~5KHz
  2. ~50KHz
  3. ~100KHz
  4. ~400KHz
  5. ~1MHz

Hardware I2C

  1. 5KHz
  2. 50KHz
  3. 100KHz
  4. 400KHz
  5. 1MHz

Could be useful to have the ~ 1MHz range into the Software I2C side, as well as it could be just as useful to have 50kHz and 100kHz ranges into the Hardware I2C side. Am I wrong? Of course if the hardware of the Bus Pirate revision 3 allows the addition of all these new implementations and much more important if it is not too hard to do it. Thanks sir!

USBEprom commented 7 years ago

Ok, now it is time for me to testing deeper. Something is weird though. Wanting to test at once even small changes introduced since the last time I have tried to use the new repository in order to build the test firmware. While I am compiling it MPLAB give at me some errors like it is explained here: ERROR 07012017.txt I know nothing but it is like makefile is wrong. Maybe it is #41 For now I will test thoroughly the firmware that I built of which I wrote. The Bus Pirate here is a revision 3. Thanks.

However, by going over. Actually the thing seems does not work. Test firmware has shown that the clock speed for the I2C protocol is correct when into the hardware side where all the speeds are exactly like those shown into the menu. Instead when into the software side the clock speed for the I2C protocol is wrong (too low speed) for the ranges ~5kHz, ~50kHz and ~100kHz, where the value is roughly 700Hz or 1kHz depending as I already wrote, while for the range ~400kHz its value is roughly the half (200kHz/222kHz).

In order to dig further I have checked the old firmware v5.10 for the which I saw that all the ranges but ~400kHz are roughly the half of which is shown into the menu, while ~400kHz is 111kHz like you wrote as max speed with your Bus Pirate revision 4. Very unfortunately all the shots I took with the usual friend of mine have been lost, so nothing for this time. The USB stick where they have been put does not work anymore here on my computer. Sorry! For now that is all.

agatti commented 7 years ago

The compilation issue has been resolved, by the way.

USBEprom commented 7 years ago

@ agatti

Thank you sir for having fix the repository! By using it I built a new test firmware for my Bus Pirate revision 3 with which I have rechecked all what I have missed yesterday. I am still using an Arduino in order to simulate a I2C bus exactly as you are used to do. Here you go the shots that the usual friend of mine has took.

Software: i2c_software

Hardware: i2c_hardware

Seems that hardware side is ok, while for the software one only the ~400kHz range is fine starting by the assumption that working at half speed is the same behaviour as using firmwares that have not the patch #23. Early firmware like v5.10 acts so except the range ~400 kHz is not roughly half of the scheduled value as it is for ~5kHz, ~50kHz and ~100kHz, but in that case it is 111kHz just like you wrote. I know nothing if this is useful or not.

USBEprom commented 7 years ago

@agatti

Based on some informations I have retrieved about the timing, especially for the logic analyzer side, for my Bus Pirate revision 3 I use always firmware optimized by numbered option (generally option "1" due lack of room into the PIC of the Bus Pirate revision 3). Since you wrote that you do not use optimizations (option "s" in MPLAB) for the firmware that you build by yourself for your revision 4, also me I tried so. Unfortunately nothing happened, the timing are still wrong the same as by using firmware optimized with option"1".

USBEprom commented 7 years ago

I am sorry keep annoying. I did upgrade from xc16-v1.26 to the newest xc16-v1.30 and now while compiling I have this message of error:

\xc16-v1.30\bin\bin/elf-ld.exe: Warning: linker script did not specify CRT_STARTMODE file, default: crt_start_mode_normal

By digging the matter I found that it is due a something into the file p24FJ64GA002.gld. Inside p24FJ64GA002.gld it is wrote:

OUTPUT_ARCH("24FJ64GA002") CRT0_STARTUP(crt0_standard.o) CRT1_STARTUP(crt1_standard.o)

if __XC16_VERSION__ > 1027

/*

I do not know how to change it in the right way. What do I do? Thanks!

agatti commented 7 years ago

@USBEprom that's just a warning introduced by the new xc8 compiler and it's harmless. Fixing that might make the firmware stop compiling with older xc8 versions, so please just leave it like this for now.

USBEprom commented 7 years ago

@agatti

Thank you sir! Ok, however for safety I am still using the previous version of the compiler that has not the error. Thanks.

agatti commented 7 years ago

Given that we now have users who are trying the firmware on v3 boards, I guess it's time to retire this ticket. If you have issues related to the community firmware on Bus Pirate v3 boards, please open a new bug if none of the currently open ones match your issue, thank you.