cancel
Showing results for 
Search instead for 
Did you mean: 

Bluetooth SDK

mdelfiasco
New Contributor II

Hello,

I had to redesign a system based on CYBT213043 with CYBT343026 for a customer in production stage because we were unable to find CYBT213043  chips (a bad issue...).

Now that the boards are ready we encountered a problem sharing I2C and PUART at the same time. After some time spent on it I switched back to the evaluation board CYBT-343026-EVAL to make some test and found something odd.

First of all I had to disable the PUART control flow to resemble my production system and because I need SCL/SDA/P35 for I2C, so I set this in wiced_platform.h:

#define WICED_PUART_CTS 0 // CTS disabled?
#define WICED_PUART_RTS 0 // RTS disabled?

Is this the correct way if flow control is not used?

For the same reason I had to disconnect RTS and CTS from the internal dongle by using PUART switches on the evaluation board (SW5: 5-4 close, 6-3 close, 7-2 open, 8-1 open).

Then I slightly modified the HAL_PUART example to make use of I2C and found that:

1) PUART and I2C work at the same time only when I2C makes use of WICED_I2C_SDA_I2S_DOUT_PCM_OUT_SCL_I2S_DIN_PCM_IN configuration.

The problem is that  I NEED WICED_I2C_SDA_P35_SCL_P37 configuration because of already made pinout choices and this does not work.

2) WICED_I2C_SDA_P35_SCL_P37 configuration for I2C does not work even if PUART test is disabled.

I provide all the tested code which should be clear enough.

To be clear, I need to work with WICED_I2C_SDA_P35_SCL_P37 and I need a working PUART peripheral on pins TXD:P31, RXD:P04, no CTS, no RTS.

What is going wrong? Are there any issues related to I2C and PUART sharing? Please help.

 

BR

1 Solution
BragadeeshV
Moderator
Moderator

Hi @mdelfiasco ,

Can you please ensure you are using external pull up resistors on the pin P37 (SCL) since it doesn't have an onboard external pull up resistor. The I2C pins P35 and SDA (Pad4) has external pull up resistor of 2.2 k on board.

Also to use pin P2/P37/P28 as SCL ensure to remove the Jumper J10 since it connects the GPIO to the on board user LED.

BragadeeshV_0-1628593276542.png

Regards,
Bragadeesh

View solution in original post

0 Likes
2 Replies
BragadeeshV
Moderator
Moderator

Hi @mdelfiasco ,

Can you please ensure you are using external pull up resistors on the pin P37 (SCL) since it doesn't have an onboard external pull up resistor. The I2C pins P35 and SDA (Pad4) has external pull up resistor of 2.2 k on board.

Also to use pin P2/P37/P28 as SCL ensure to remove the Jumper J10 since it connects the GPIO to the on board user LED.

BragadeeshV_0-1628593276542.png

Regards,
Bragadeesh

View solution in original post

0 Likes
mdelfiasco
New Contributor II

Hi BragadeeshV,

You are right. The problem was the missing pullup on P37 on the evaluation board. On my target hardware the problem was different. It was caused by how the application works: it was in a busy loop inside a timer callback to wait for incoming UART data but I found that PUART interrupt will not trigger while the timer is running. This is probably because timer callbacks run as IRQ and nesting is not managed, or timer IRQs have a priority higher than PUART. This will cause me some problems in application logic design but the good news is that both PUART transmitter and receiver seems to have a 256 byte FIFO. Hope I'll find a solution.

Going back to I2C I found that when the pins work as I2C the voltage falls from 3.3V to 2.7V. Is this normal? Where is it documented?

As a last note I also found that if the order of initialization of PUART and I2C is reversed the code example I posted will not work. Can I know why? In my application I2C is used to detect the board version, then PUART is initialized based on board detection result. This way I am forced to always initialize PUART first and this is a constraint I would be happy to remove. UART and I2C are initialized in the stack BTM_ENABLED_EVT callback as my application does. Is it possibile to initialize I2C before PUART?

Thanks.

0 Likes