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. 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. 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 ?