hang in I2C binary mode - lower speeds

Hacking multi-tool. Get one for $30, including worldwide shipping.

hang in I2C binary mode - lower speeds

Postby acadiandad » Mon Jan 30, 2017 11:50 pm

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 all
            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 all
    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 ?
acadiandad
Newbie
Newbie
 
Posts: 1
Joined: Mon Jan 30, 2017 11:22 pm

Re: hang in I2C binary mode - lower speeds

Postby USBEprom » Tue Jan 31, 2017 2:28 pm

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
USBEprom
Full Member
Full Member
 
Posts: 109
Joined: Wed Mar 14, 2012 4:09 pm

Re: hang in I2C binary mode - lower speeds

Postby Sjaak » Tue Feb 07, 2017 10:52 am

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?
For my projects and failures see my blog: http://SMDprutser.nl/
User avatar
Sjaak
Fellow
Fellow
 
Posts: 3291
Joined: Sun Jan 03, 2010 2:45 pm
Location: Hiero


Return to Bus Pirate Support