Sep 06, 2016
02:05 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 06, 2016
02:05 AM
Hello gents,
I am working with the Hexagon XMC4500 Dev kit connected with ACT to the Automation board.
I found an example for the HMI board which interfaces MCU to an I2C IO Expander PCA9502
I2C_EXAMPLE_XMC4500
I though this example eould work without issues on the AUT_ISO board which has the same IO Expander chip. and same I2C interface pins
It does not work.
The MCU never gets and ack from first I2C write. (Which signals by the way get correctly generated)
Does someone know why ?
Which wrong assumption did I make ?
I am working with the Hexagon XMC4500 Dev kit connected with ACT to the Automation board.
I found an example for the HMI board which interfaces MCU to an I2C IO Expander PCA9502
I2C_EXAMPLE_XMC4500
I though this example eould work without issues on the AUT_ISO board which has the same IO Expander chip. and same I2C interface pins
It does not work.
The MCU never gets and ack from first I2C write. (Which signals by the way get correctly generated)
Does someone know why ?
Which wrong assumption did I make ?
4 Replies
Sep 06, 2016
02:22 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 06, 2016
02:22 AM
Hi Jorge,
all boards share exactly the same IO Expander chip (PCA9502), but they need to have different addresses in case two or three satellite cards are connected at once.
So for board that you´re using (AUT_ISO), device slave address is 0x90.
(for the reference: http://http://www.infineon.com/dgdl?folderId=db3a30433580b3710135a47f3eb76c98&fileId=db3a304335f1f4b...)
Best regards,
Deni
all boards share exactly the same IO Expander chip (PCA9502), but they need to have different addresses in case two or three satellite cards are connected at once.
So for board that you´re using (AUT_ISO), device slave address is 0x90.
(for the reference: http://http://www.infineon.com/dgdl?folderId=db3a30433580b3710135a47f3eb76c98&fileId=db3a304335f1f4b...)
Best regards,
Deni
Sep 06, 2016
04:40 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 06, 2016
04:40 AM
Hello Deni,
Thank you for your quick response!
As you suggested, I changed PCA9502 I2C address IO_EXPANDER_ADDRESS from 9Ah to 90h and now the first Init and write phases work.
However, when trying to readback what was just written fails :
/* Receive the data from the IO EXPANDER */
I2C_MASTER_Receive(&I2C_MASTER_0,true,IO_EXPANDER_ADDRESS,&received_data,1,true,true);
while(rx_completion_0 == 0);
rx_completion_0 = 0;
/* Check if the received data is correct*/
Here received_data is always 0 while we just wrote FFh
if(tx_buffer[3] != received_data)
{
while(1);
}
Any idea why ?
Thank you for your quick response!
As you suggested, I changed PCA9502 I2C address IO_EXPANDER_ADDRESS from 9Ah to 90h and now the first Init and write phases work.
However, when trying to readback what was just written fails :
/* Receive the data from the IO EXPANDER */
I2C_MASTER_Receive(&I2C_MASTER_0,true,IO_EXPANDER_ADDRESS,&received_data,1,true,true);
while(rx_completion_0 == 0);
rx_completion_0 = 0;
/* Check if the received data is correct*/
Here received_data is always 0 while we just wrote FFh
if(tx_buffer[3] != received_data)
{
while(1);
}
Any idea why ?
Attachments are accessible only for community members.
Sep 06, 2016
08:18 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 06, 2016
08:18 AM
Hi Jorge,
It´s really strange, while I ran the same example that you used and also an example that I will send you and both of them are working for me. Can you verify that you really transmitted 0xFF?. Debug and set breakpoint at line "I2C_MASTER_Receive(&I2C_MASTER_0,true,IO_EXPANDER_ ADDRESS,&received_data,1,true,true);". Notice that transmission is handled by the interrupt handler (at least if you left default I2C_MASTER APP settings untouched). By the time code execution reaches this line, transmission of 0xFF should already occur.
Verify that value 0xFF is really present in register TBUF inside USIC1_CH0 (if you need assistance, please don´t hesitate to ask).
If everything is right and the value that we transmit is really 0xFF, then try run example that I´ve attached to this post. It´s fairly similar to your current example, but maybe it will be easier to found out where is the error.
Best regards,
Deni
It´s really strange, while I ran the same example that you used and also an example that I will send you and both of them are working for me. Can you verify that you really transmitted 0xFF?. Debug and set breakpoint at line "I2C_MASTER_Receive(&I2C_MASTER_0,true,IO_EXPANDER_ ADDRESS,&received_data,1,true,true);". Notice that transmission is handled by the interrupt handler (at least if you left default I2C_MASTER APP settings untouched). By the time code execution reaches this line, transmission of 0xFF should already occur.
Verify that value 0xFF is really present in register TBUF inside USIC1_CH0 (if you need assistance, please don´t hesitate to ask).
If everything is right and the value that we transmit is really 0xFF, then try run example that I´ve attached to this post. It´s fairly similar to your current example, but maybe it will be easier to found out where is the error.
Best regards,
Deni
Sep 07, 2016
02:46 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 07, 2016
02:46 AM
Thank you Deni,
Your examples work perfectly.
But they use explicitly active wait for end of transmission,
while original example was using end-of-transmit/receive by interrupts.
I could understand the problem with my app which was incorrectly nesting interrupts.
Thank you for your efficient support!
Jorge
Your examples work perfectly.
But they use explicitly active wait for end of transmission,
while original example was using end-of-transmit/receive by interrupts.
I could understand the problem with my app which was incorrectly nesting interrupts.
Thank you for your efficient support!
Jorge