Hi,
I have been trying to implement an I2C slave on a CC2541 device which has the Peripheral + Observer profiles implemented on it. I am testing the I2C functionality while the device is just observing constantly without establishing any connections to any other device around it. As a matter of fact, there is no other BLE devices around the device.
One thing I discovered is that the following function seems to block the I2C interrupt detection for some reason.
VOID GAPObserverRole_StartDiscovery(DEFAULT_DISCOVERY_MODE, DEFAULT_DISCOVERY_ACTIVE_SCAN, DEFAULT_DISCOVERY_WHITE_LIST);
The above function calls the following function, which is within the BLE stack library and I do not have access to it.
GAP_DeviceDiscoveryRequest( );
When I comment out the call to GAPObserverRole_StartDiscovery(), the I2C interrupts fire and work exactly as I want them. Each I2C request coming from an external master is detected and responded to by the CC2541 slave device as needed.
After observing the above, I decided to call the GAPObserverRole_StartDiscovery() function less frequently. That way the device could scan for a few hundred miliseconds and then wait for a few hundred miliseconds doing nothing. In this idle period, the I2C interrupts would be detected and serviced.
The above had limited success. When the device is started up, the I2C interrupts do get detected and serviced as required for about 20 seconds. Then the I2C interrupts get blocked again. The interrupts are never detected after that.
Does anybody know why the above may be happening? Is there any "hidden" I2C or global interrupt disabling within the stack that I should be aware of? Any feedback from users who have seen a similar problem will be greatly appreciated.
I am guessing that other stack functions must be kicking in after the first 20 seconds that cause this blocking. I will try to hunt these down while I wait for a response to this post. I will give my updates if I come across anything interesting during my tests.
Regards...