Skip to main content
Topic: hang in I2C binary mode - lower speeds (Read 2163 times) previous topic - next topic

hang in I2C binary mode - lower speeds

I am scripting BP to talk to MCP4725 DAC using binary mode.  The host is Win7 running python scripts in IDLE.

Bus Pirate v3.5
Firmware v6.2-beta1 r1981  Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)

Running into what seems to be some sort of hang when using bulk-write command in binary I2C mode.

If I have 8 data bytes being sent to the BP and I2C speed is '3' (~400 kHz), the transactions are successful and no issues.

eg.
Code: [Select]
            cmd = [chr(0x02),
                  chr(0x18),
                  chr(HD_DAC),
                  chr(0x0F),chr(0xFF),
                  chr(0x08),chr(0xFF),
                  chr(0x0F),chr(0xFF),
                  chr(0x08),chr(0xFF),
                  chr(0x03)]

If I reduce the bus speed to '2' (~100 kHz), the first time I send the command, everything is OK (DAC responds correctly, inspection of SCL and SDA on scope shows valid transactions, BP returned values are as expected) - - however immediately afterwards, the BP is locked up and only responds '0x01' no matter what is sent to it.  Only a power reset resolves.

If I then reduce the length of the transaction to only have 4 bytes, the command is successful and can be repeated.

eg.
Code: [Select]
    cmd = [chr(0x02),
          chr(0x14),
          chr(HD_DAC),
          chr(0x0F),chr(0xFF),
          chr(0x08),chr(0xFF),
          chr(0x03)]

I confirmed same behavior with a terminal program (Hercules Setup v3.2.8)

I wanted to use the slower I2C frequency as I am trying to create a pulse using the DAC which has a specific width.  By chaining together multiple values in the string, the DAC will move between the levels.  The 400 kHz mode is too fast (the 16 byte limit of the bulk-write limits the pulse width) - or if I send two separate bus transactions, the delays are much longer than I can tolerate.  Really would be perfect if the 100kHz mode worked reliably with the longer string.

Any ideas what is going on or how to approach ?

Re: hang in I2C binary mode - lower speeds

Reply #1
Hi acadiandad.
I know nothing about binary mode with the Bus Pirate.
I know there are some problems with the protocol I2C on the Bus Pirate.
The firmware you are using in pretty old.
If you would like you could try with this which is recent:
 
dangerousprototypes.com/forum/download/file.php?id=12196
 
In the case use the file 12112016_1.hex which is optimized, 12112016_s.hex was compiled more than anything else for testing purpose.
Newest release of the firmware do fix some issues, some of which can be tied with the protocol I2C.
Altought in half speed the firmware 12112016_1.hex does work with the protocol I2C.
However unfortunately till now the protocol I2C on the Bus Pirate is plagued by some problems.
Take a look these:

viewtopic.php?f=4&t=8638

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

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

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

Be seeing you.

U.Sb

Re: hang in I2C binary mode - lower speeds

Reply #2
I think you are causing a bufferoverflow . You are writing too much bytes while the command before isn't finished. Could you retry with a relative long wait in between the bytes sent?