RA0 IICA_SLAVE cannot be configured properly

Hello,

Thanks for reaching out Renesas Engineering Community!

Regarding the IICA peripheral support on the different FSP versions you mentioned.

1.In FSP version 5.2.0 if you go to pin configuration the IICA peripheral is available and you can configure the pins however the stacks with the drivers for IICA  are not available yet and have been added in FSP 5.3.0 version.

2. Now regarding FSP 5.3.0 you are right this is a bug that has already been reported to the FSP developers team:

You cannot enable the IICA peripheral from the Pin Configurator, however you have available the stacks and the driver for both master and slave mode where you can configure the pins on the stack properties.

A workaround that worked for me when testing the IICA module for master was  to add these two lines in the configuration.xml file and of course I have also configured the pins on the stack properties.

And then the peripheral seemed to be enabled and when I tested the IICA peripheral as master and it worked with no issues.

I think the same workaround will work for you and in the case where the RA0 is configured as slave.

3. Now in FSP version 5.4.0 since this bug has already been reported  to the FSP dev team, the idea is to remove completely the settings for the IICA peripheral from the Pins tab and users configure the pins from the stack properties for the IICA module for both slave and master modes.

So the issue has been fixed in FSP 5.4.0 version. And we would suggest to you on this case to use the FSP 5.4.0 version for using the IICA peripheral with RA0E1.

Please find attached two projects for both FSP 5.3.0 and FSP 5.4.0 that the IICA peripheral worked for me with no issues.

In FSP 5.3.0 I did these changes mentioned in the configuration.xml file so that the IICA peripheral will be shown as enabled in the pin configurator also and in FSP 5.4.0 version the pins have only been configured in the r_iica module properties and no more settings are necessary to be done.

hs3001_sensor_RA0_IICA_FSP5.3.0.zip

hs3001_sensor_RA0_IICA_FSP5.4.0.zip

Hope it helps.

Best Regards,

IK

Sorry for bothering you with the matter below:
Now it works, after entering 0x10 in stack properties as slave address when the slave has to respond to an address that that is interpreted as 0x20 on the logic analyzer.
This may be, because address is shifted left by one bit for adding R/W flag.
Nevertheless, I would be interested in an answer to the duty cycle question
Best regards

============================================================

Unfortunately I have to come back here again, because in between my above stated optimism regarding I2C slave function is decreasing now, after several hours of successless efforts to bring up the RA0E1 on an FPB-RA0E1 board as an I2C slave.

FSP is configured as in the properties screenshot below:

After sending the I2C slave address from an RA6 master to the RA0
on an I2C bus with proper hardware design (3.3V, RA6 as master with open drain, pull-ups of 4k7 each on SDA and SCL, cable length 1 inch, rise time around 300ns, fall time around 200ns),
see logic analyzer (LA) screenshot below where the LA's I2C interpreter shows the correct slave adress:

We verified with an oscilloscope, that the described signals shown in the LA screenshot are present directly at the RA0E1 pins 5 and 6 (P213 and P212).

RA0 slave never acknowledges the receiption of the slave address (see screenshot)
and never triggers the interrupt routine iica_slave_txrxi_isr() in the FSP's r_iica_slave.c module (what I would expect acc. to everything stated in the RA0E1 User's Manaual chapter 22),
program execution never halts on a breakpoint set there and therefore, the following functions like r_iica_txrxi_slave() and r_iica_slave_call_callback() are also never called (breakpoints are never reached).

Above described behaviour does not differ between FSP 5.3.0 and 5.4.0.
We need urgent support because this function is essential for our system architecture and time to market of a new product.

What I also don't understand:
What is the duty cycle setting property good for when used as a slave ?
From my understanding, this parameter may be only relevant when used as a master. Should I ignore this setting in the slave stack properties shown above ? We also tried it with setting this parameter to 50% but without success.

Best regards

Hi ,

We are also experiencing similar problem configuring device as IICA slave , @renasas Team , could you please help with an example project for IICA slave . 

Regards,

A N

Hi,

the problem is solved. the reason was a mis-interpretation of the target address, see HarLey 's amended post above

Hi ,

We are designing a new hardware with renesas RA0E1 to replace one of our existing design , the current I2C slave address on existing design was 0x01 and we cannot configure this on renesas as the configuration only accepts address 0x08 and above . 

For communication test , we tried configuring slave address 0x08 on master and then as per above suggestion modified address on renesas as 0x10 (0x08 << 1) . this didnt help us in an way , never observed break point hits at iica0 isr callback on master sending initial request. 

iica slave configuration

Regards,

Anil

If you want to see a "physical" slave address of let's say 0x20 on the I²C bus (to be viewed with logic analyzer), you have to configure half the value (0x10) in the e² studio stack properties, not the other way around as you tried/described.

Hi Harley ,

Thanks for your prompt response. 

is there any reason why i cannot configure the slave address below 0x08 ?  we are looking for backward compatibility with our old design (where master is communicating with slave address 0x01) 

Regards,

Anil

As far as I can see only 0x00 to 0x02 are reserved addresses, 
I don't know if and why Renesas implemented it with that restriction (0x08 in properties, which results in physical address of 0x10), maybe a someone from Renesas can answer that ... ?
I also never received an answer from them to my question above about what the duty cycle setting is good for with an I2C slave ...

As far as I can see only 0x00 to 0x02 are reserved addresses, 
I don't know if and why Renesas implemented it with that restriction (0x08 in properties, which results in physical address of 0x10), maybe a someone from Renesas can answer that ... ?
I also never received an answer from them to my question above about what the duty cycle setting is good for with an I2C slave ...