BusPirate I2C Bulktransfer, Transmit stop

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

BusPirate I2C Bulktransfer, Transmit stop

Postby Kolar » Sun Dec 25, 2016 4:37 pm

Hi Folks,

I have to programm an IC with integrated I2C Bootloader. I have got a binary file which contains this information.
Now i've planned to use the BusPirate I2C Bitbanging Mode to send this file on the I2C Bus. Therefore I use HTerm and the
I2C Bitbanging mode of the BusPirate. I stuffed the required configuration commands for the BusPirate into the binary file. I have created some kind of wrapper in C++ that adds the required header and the necesarry bits for I2C Bulk transfer to the binary file.

Example:
Initial File:
00 01 02 03 04 05 06 07 08 09 10 0A 0B 0C 0D 0E ...

"wrapped File":
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 --enable BBIO Mode
02 63 4C --I2C Mode, 400kbits, Enable Power&Pullup
17 00 01 02 03 04 05 06 07 17 08 09 10 0A 0B 0C 0D 0E ... -- 17 = bulk transfer 8 byte packages

Now I can send the file via HTerm. The BusPirate respons by configuring I2C mode and it starts transmitting (Verified with oscilloscope). I recieve NACKS/ACKS for the first 160-220 chars then the BusPirate is reset into BBIO Mode. It seems to be a timing problem. I cannot manage to transmmit the full file to my IC.


Can anyone help me?

Regards
Kolar




Bus Pirate v3B, Firmware v5.10 <r559>
Attachments
Response.JPG
response
Kolar
Newbie
Newbie
 
Posts: 4
Joined: Sun Dec 25, 2016 4:01 pm

Re: BusPirate I2C Bulktransfer, Transmit stop

Postby Kolar » Sun Dec 25, 2016 4:40 pm

Unfortunately i cannot upload .bin files to this forum.
By adding an url from an external filehoster my post will be blocked due to suspiction of spam.
Kolar
Newbie
Newbie
 
Posts: 4
Joined: Sun Dec 25, 2016 4:01 pm

Re: BusPirate I2C Bulktransfer, Transmit stop

Postby USBEprom » Mon Dec 26, 2016 6:54 am

Hi Kolar.
The Bus Pirate has a limited amount of characters for the command line.
Normally it is up 128 characters and however based on how much is set while compiling a customized firmware.
If your Bus Pirate is a revision 3 you can try with this:

dangerousprototypes.com/forum/download/file.php?id=12196

For sending instructions you have to respect the limit of 256 characters for the command line, so you must split them in slices up 256 characters.
Otherwise you must build your own customized firmware that allow for much more characters into the command line.
Instead to use HTerm which I do not know, I suggest you to use Buspirate-console (http://akb77.com/g/net/buspirate-console/) benefiting yourself of its scripting capabilities.
Also the Buccaneer's Den GUI can do the job.

Be seeing you.

U.Sb
USBEprom
Jr. Member
Jr. Member
 
Posts: 87
Joined: Wed Mar 14, 2012 4:09 pm

Re: BusPirate I2C Bulktransfer, Transmit stop

Postby Kolar » Tue Dec 27, 2016 3:50 pm

Hi USBEprom,

thanks for your reply,
the problem does not occure using RealTerm and the same file but something is going wrong anyways.

Is there any documentation about the 256 character limitation?
What kind of firmware is this that you have postet in this link?
I there also some sort of documentation?

My next step would have been to reset the BusPirate after every 256 chars to avoid this issue.

Kind regards,

Kolar
Kolar
Newbie
Newbie
 
Posts: 4
Joined: Sun Dec 25, 2016 4:01 pm

Re: BusPirate I2C Bulktransfer, Transmit stop

Postby USBEprom » Wed Dec 28, 2016 5:59 am

Hi Kolar.

Kolar wrote:the problem does not occure using RealTerm and the same file but something is going wrong anyways.


There may be a competition of faults.
Have you tried Buspirate-console or Buccaneer's Den GUI that I wrote?
However it is weird because for the limit of characters into the command line does not matter the terminal or GUI used, being it is a firmware feature.

Kolar wrote:Is there any documentation about the 256 character limitation?


Yes, it is.
It is scattered in various documents, the most important of which is the source of the firmware where is the configuration setting for build it.
Also into the documentatione of Buccaneer's Den GUI it is mentioned.
The limit depend on how much have been setted while compiling.
Generally it is up 256 characters for firmwares previous v7.0, then starting by that it is up 128 characters unless of customized versions.

Kolar wrote:What kind of firmware is this that you have postet in this link?
I there also some sort of documentation?


It is a firmware that I built myself for the Bus Pirate revision 3 where all the features are active, BASIC too, and where command line allow up 256 characters.
Into the link I wrote there are all the specifications and it is explained how it has been obtained.

Kolar wrote:My next step would have been to reset the BusPirate after every 256 chars to avoid this issue.


I am babo as hell and I know nothing.
Perhaps you do not need to reset but rather use slices up the limit of the command line (256 characters with the firmware that I linked) by adding some delay among the slices sent while the process.
That is very easy to do by using Buspirate-console.

Be seeing you.

U.Sb
USBEprom
Jr. Member
Jr. Member
 
Posts: 87
Joined: Wed Mar 14, 2012 4:09 pm

Re: BusPirate I2C Bulktransfer, Transmit stop

Postby Kolar » Fri Dec 30, 2016 3:47 pm

Thanks again for your answer,

I have updated the BusPirate with the Firmware you linked in the first post.
There are two things that I do not understand fully.

1) when i connect to the BusPirate via Terminal and go into I2C Mode i can run a scan for all devices that reply with ACK, which is a neat feature. [m 4 x (1)]. Changing the I2C frequency does not seem to change anything for this scan. If i change the frequency to 100kHz i still find devices that are only build for 400kHz and so on.

2) When I send a random command and take a look at it on my external oscilloscope, I see that the real frequency is only haf the frequency I have configured. E.g. I set I2C to 400kHz and see a clock frequency with a period of only 5us (200kHz).

Maybe this is my problem

Regards
Kolar
Kolar
Newbie
Newbie
 
Posts: 4
Joined: Sun Dec 25, 2016 4:01 pm

Re: BusPirate I2C Bulktransfer, Transmit stop

Postby USBEprom » Sat Dec 31, 2016 6:42 am

Hi Kolar.

Kolar wrote:I have updated the BusPirate with the Firmware you linked in the first post.


Just to be safe, what exactly is the firmware you are using?
You must use 12112016_1.hex which is optimized, not 12112016_s.hex which is not optimized.
Otherwise in some situations you might have timing issues.
So use 12112016_1.hex, not 12112016_s.hex!
I built 12112016_s.hex only for testing, it is better do not use it but rather 12112016_1 in its place.

Kolar wrote:1) when i connect to the BusPirate via Terminal and go into I2C Mode i can run a scan for all devices that reply with ACK, which is a neat feature. [m 4 x (1)]. Changing the I2C frequency does not seem to change anything for this scan. If i change the frequency to 100kHz i still find devices that are only build for 400kHz and so on.


I guess that is the expected behaviour.
I am not aware that the command is selective based on the I2C bus speed.
I2C devices which support high speed can they work also at low speed.
The problem might be for those of them which work at low speed when they are used at high speed.
However the perception of speed is evident only when scanning on a I2C bus where there are many devices.
If the devices on the I2C bus are few, then it is hard to notice differences.

Kolar wrote:2) When I send a random command and take a look at it on my external oscilloscope, I see that the real frequency is only haf the frequency I have configured. E.g. I set I2C to 400kHz and see a clock frequency with a period of only 5us (200kHz).


I do not know if this is normal or not, in that regard there are investigations in progress.
What I know is that is the normal behavior saw until today.

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

Kolar wrote:Maybe this is my problem


If it is a problem, it is not yours alone but of all.
I repeat that about it there are investigations in progress and that is the behavior until now accepted.
It is so also with the previous releases of the firmware.
It always has been, so.
Happy new year!

Be seeing you.

U.Sb
USBEprom
Jr. Member
Jr. Member
 
Posts: 87
Joined: Wed Mar 14, 2012 4:09 pm


Return to Bus Pirate Support