Hello all
I have a project based on RA4M1 that uses I2C with several devices (RTC, GPIO expander) without any problem. The program uses FSP 5.1.0. A few days ago, I had to make some major changes in some functionalities so I thought to make the most and update the FSP too. That was my first step, to update FSP from 5.1.0 to 5.4.0. But unfortunately, in the first tests after the updating I see the I2C is not working properly: the first write to I2C the program tries to do it gets error FSP_ERR_IN_USE. I have gone back to the version that uses the 5.1.0 (using the same hardware) and the error does not appear, everything runs smoothly.
Any suggestion or idea to know what's going on?
NOTE: to be able to compile after the updating I had to set value "Enable" to parameter "DTC on Transmission and Reception" in "r_iic_master" in all I2C stacks I had in the project. In the previous version of this project (the one using FSP 5.1.0) I was using DTC too in the same way but don't remember if there was a parameter called "DTC on Transmission and Reception"that I had to set or not.
Thanks a lot.
Jose.
More info on the issue: it works fine in case of FSP 5.3.0 and 5.2.0, but as I said it fails in 5.4.0
All I2CGPIOExpander, I2CRTC4GModule, I2CGPIOExpander4GModule modules use IIC channel 0. Is this as it should be ?
Yes, it's right. Maybe the code it's a bit confussing: that target device (hardware) has different configurations and this code runs on all of them. The program (in runtime) is able to differentiate the hardware configuration and use an I2C component or other.
Ok, then you need to make sure that a channel 0 transfer is not already ongoing before you issue a new one.
You can confirm this by checking that the I2C_MASTER_EVENT_TX_COMPLETE and I2C_MASTER_EVENT_RX_COMPLETE events are received by the callback function.
I was using event RM_COMMS_EVENT_OPERATION_COMPLETE in the callback (I thought it comprehended I2C_MASTER_EVENT_TX_COMPLETE and I2C_MASTER_EVENT_RX_COMPLETE, didn't it?).
Anyway, the problem is that the first write operation on the I2C channel fails (FSP_ERR_IN_USE) and no I2C callback is issued after that write operation (or the subquent ones).
Yes, RM_COMMS_EVENT_OPERATION_COMPLETE should work too. Do you make sure that this event is returned before initiating a new IIC transfer ?
Yes, I have ensured there is not any event pending.
As I said, in the very first operation in the I2C channel, after the open operation the problems appears (I added a delay from the open to the write too, with not avail). There is not any previous write operation or read operation pending and in case I'm wrong and that hypothetic previous operation was pending the completion event never appears.
Hello
It seems the issue was fixed by chance yesterday while doing some more tests to find out what was going on. I explain the procedure we followed:
- In the project there are 5 elements that use I2C:
I2CCMeasuresChip ---> Channel 0 I2CRTC ---> Channel 0 I2CGPIOExpander ---> Channel 0 I2CRTC4GModule ---> Channel 1 I2CGPIOExpander4GModule ---> Channel 1
- The problem appears the first time we try to write by means of I2CGPIOExpander - As the problem seemed to be related with the use of the I2C channel 0, we changed provisionally in the project the channel of the other two stack elements (I2CCMeasuresChip and I2CRTC) that use channel 0. We force them to use channel 1: this is achieved by assigning them stack element I2CBusForChannel1 (it is an stack element of type I2C Shared Bus with channel 1) that already use elements I2CRTC4GModule and I2CGPIOExpander4GModule. We generated the project content again and recompiled the whole code.
- So after these changes we had the following:
I2CCMeasuresChip ---> Channel 1 I2CRTC ---> Channel 1 I2CGPIOExpander ---> Channel 0 I2CRTC4GModule ---> Channel 1 I2CGPIOExpander4GModule ---> Channel 1
- The problem did not appear with those settings: the first write operation (and all the subsequent ones) by means of I2CGPIOExpander did not give any error in any case.
- After some extended tests of writing and reading operations with I2CGPIOExpander to ensure its right running, we restored the initial settings (we regenerated the project and recompiled it all again). The settings at this point were the following (the initial ones):
- The problem still did not appear. We performed quite a few tests and everything run smoothly. So at that moment we had this project using FSP 5.4.0 without any issue. Problem fixed!
The difference I see in both cases is only the re-assignation of stack I2C elements that could reset or update some internal properties that are not modified if we only change the FSP. Could it be?
I summarize the procedure in both cases:
Problem case: ============ 1) Project using FSP 5.3.0 runs OK 2) Project updated to use FSP 5.4.0 3) Regenaration of project content (button "Generate Project Content") and recompilation (with "Clean" option) 4) First use and susequent ones of I2C element I2CGPIOExpander fails
Not problem case: ================= 1) Project using FSP 5.3.0 runs OK 2) Project updated to use FSP 5.4.0 3) Regenaration of project content (button "Generate Project Content") and recompilation (with "Clean" option) 4) Reassignation of some I2C stack elements (changed to use other I2C Shared Bus provisionally, regeneration and recompilation) 5) Restoration of I2C stack elements, regeneration and recompilation 4) First use and susequent ones of I2C element I2CGPIOExpander does not fail any more
Do you have any explanation for this? Thank you and sorry for this long message.
From what you mention it is possible that is caused by the clean option. When you update the FSP version you should generate project content and then build, clean build is not normally necessary.
Less possible is that FSP update caused a miss-configuration.