 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Predator_MF
Joined: 26 Mar 2005
Posts: 10
|
| Some minor I2C problems |
 Posted: Sat Jul 30, 2005 5:01 am |
 |
|
I have the following code that makes my life shorter:
| Code: |
void Send_NVM_packet()
{int8 i,chksum,tmp;
chksum = 0;
i2c_start();
i2c_write(0xA0);
i2c_write(rx_buffer.buffer[1]); // Load MSB address
i2c_write(rx_buffer.buffer[2]); // Load LSB address
i2c_start(); // Repeated Start
i2c_write(0xA0);
printf(preamb); // Send Preamble
printf(DEV_ID); // Send Device ID
putc(0x7F); // Send Data Length
for (i=0;i<128;i++)
{ tmp = i2c_read(SEND_ACK);
putc(tmp);
chksum += tmp;
}
putc(chksum);
}
|
I have written a protocol some years ago that I still use. It has cheksums and verifies every packet sent and recieved, so there is no problem there for sure. I use FT232 chip and PIC18F452, serial connection is RS232, 8n1, 460800bps @ 22.118400MHz. I've also tried this code with PIC16F877A, the problem is the same. Memory is 24LC256, power supply is 5V. When I read all the NVM from my PC program, i get first block of 255 bytes OK, and the next 255 bytes are all zeroes (0x00). Every time I get some different blocks. I asume that my protocol works perfectly as I have used it many times before (for reading CF cards and SPI memories). Checksums are combined with the ID word, it's not 0 when all data is 0. This means that the problem is in the code I'm posting...where??? I2C settings are fast I2C, do not use HW, pins are pulled up with resistors 4k7. I tried with slow I2C, nothing different, just slower reading of the NVM. Someone help will be appriciated  |
|
 |
Ttelmah
Guest
|
|
| Posted: Sat Jul 30, 2005 8:31 am |
|
|
I hope it is just a typing error, but there is a glaring fault in the code as posted. It correctly triggers a random 'write', with the address bytes to define the address to be used, then issues a second command, but the R/W bit on the second command needs to be a '1', or it will be doing a repeated write, not a repeated read...
The command after the second i2c_start, needs to be 0xA1, not 0xA0.
Assuming this was not the cause of the problem, I'd be looking at the code calling this, and perhaps add a diagnostic printout to verify that the code is receiving the full 16bits of the address. I'd be terribly suspicious that the problem relates to the fact that a default integer in CCS is 8bit, while most other C's have it as 16bits, and that perhaps at some way in one of the outside routines, this is resulting in the address being truncated to 8 bits.
Best Wishes |
|
|
Predator_MF
Joined: 26 Mar 2005
Posts: 10
|
|
| Posted: Sun Jul 31, 2005 5:54 am |
|
|
| Ttelmah wrote: | | I hope it is just a typing error... |
Yes, Ttelmah, actually it is.I didn't have the code in front of me when I posted it...sorry about that  Let me explain some details...
| Code: | struct
{byte data_length;
byte buffer[70];
}rx_buffer; |
This is the structure that holds the recieving buffer for my protocol. As you see buffer is defined as array of bytes (unsigned 8-bit integers). All the commands in my protocol are called by a switch(CMD)-case routine, where CMD is rx_buffer.buffer[0]. My program sends the following message when reading the EEPROM:
| Code: |
0x00,0xFF, // This two are preabmle bytes
ID,
DAT_LNG, // Data legth
CMD, // Command to be executed
MSB_EE_Address
LSB_EE_Address
Checksum
|
Then checksum is verified and if true the command Send_NVM_packet is executed. Funny thing is that there is no matter if I run the code with lower RS232 speeds or lower I2C speeds. Man, I'm really stucked  |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
