2010-03-03 10:11:45     BF537 TWI ack

Document created by Aaronwu Employee on Aug 20, 2013
Version 1Show Document
  • View in full screen mode

2010-03-03 10:11:45     BF537 TWI ack


Message: 86758   


Hello all,


I have connected a MAX1139 device to the TWI port of the BF537.  I have successfully gotten the devices to speak but seem to have a problem with bf537 sending an ACK.  I have connected a scope the the lines and confirm that the comms are working.


I create a simple c program to communicate with the i2c-0 device.  I have attached the c program. 


When I run the program I get the following output:


First Read: 252


First Total: 0


Second Read: 252


Second Total: 252


If i increase the voltage on the power supply both the second and first read go up to 253, 254, 255.  From the data sheet, the ADC reads the last to bits from the first byte (which is why I and it with 0x3).  This make sense since the byte read is 252 when the voltage is zero and 255 when the voltage is at the ADC's max.  However, I then need to send an ack and get the second byte to get the rest of the data (10bit ADC)  However the second byte is always the same as the first - this tells me that the slave is not receiving the ACK and keeps transmitting the first byte.


Does the TWI driver send acks after receives automatically?  Could not find any information on the doc:




If not how can I manually send an ack once I have finished reading.  On a rabbit processor using the exact same chip we just bit bashed the slave with reads, and an ack and it worked perfectly.  Software is very similar.




Kind regards,











2010-03-03 11:09:38     BF537 TWI ack

Michael Hennerich (GERMANY)

Message: 86762    Blackfin TWI like any other TWI/I2C peripheral or Linux driver ACKS automatically.

But I guess you need to use i2c_smbus_read_word_data() instead of two byte transfers.




2010-03-04 05:51:07     Re: BF537 TWI ack


Message: 86801   


Hey Micheal,


Thanks for the reply.  It is actually a bit stranger output than before.  I have gone back and double checked all the code - I have also tested the ADC on different channels - you can see the config word I send the to ADC after the setup word.  This contains channel information - When it is 0x61 it selects the first channel 0x63 second and so on.


I have changed this value to all 10 channels and apply a voltage on that channel (I get with my previous code the exact same output: 252 on the first byte and 252 on the second with no voltage) and (253-255 on first byte and 253-255 on second byte with a voltage).


This tells me that I am definitely setting up the ADC correctly and definitely reading the first byte correctly.  With that said I tried the following:


reader = i2c_smbus_read_word_data(file,0);


printf("First read: %d\n", (int)(reader)); // here i do not care about anding it with 0x03FF yet just want an output.




I get an output of 252 the whole way in my range 0-3V, once I go over 3V the output becomes crazy 4075, 37859, etc. This tells me there is an overflow error or something similar since I only have a 10bit ADC it can only give a max of 1024.  I tried using i2c_smbus_read_block_data and get a similar output with the first block being 252 and the second block being 0 after this the thrid block is 14 and then something like 177 (even though I am not concerned with these blocks).  I assume I am perhaps using the second argument in the read_word_date call incorrectly (command).


I am not sure what to do with this I have tried changing it to 0x10, 0x01, the slave address. With these values it just gives random numbers as i increase the voltage it jumps up then down then up then to 252 then down etc. And again these values are much more than a10bit number.  If I & the value with 0x03FF I get the result 252 till 3V, which tells me that not using 0 as the command the read changes the upper bits of the first byte.


If i use the slave addr as my command the value changes even though I am applying no voltage to the channel, if I apply more than 3V it does cap it at 1023 which makes sense since I and it with 0x03FF.




Any help will be highly appreciated,