RTOS/CC2640R2F: Problem using UART and I2C simultaneously

Hi M-W,

Thanks for helping me look into this. Here's how I'm using the device drivers (only the app task is using the I2C driver currently; obviously in this example I do not need to open and close the I2C repeatedly, but there are circumstances where I will need to do that):

main app task:

bool I2CCommand(uint8_t address, const void *txbuf, uint8_t txlen, void *rxbuf, uint8_t rxlen)

{

    I2C_Params i2c_params;

    I2C_Params_init(&i2c_params);

    i2c_params.bitRate = I2C_400kHz;

    I2C_Handle i2c = I2C_open(Board_I2C, i2c_params);

    if (i2c == NULL)

    {

        System_printf("I2CCommand: Error Initializing I2C\n");

        return FALSE;

    }

    System_printf("OPEN MSTAT=%x\n",HWREG(I2C0_BASE + I2C_O_MSTAT));

    I2C_Transaction i2c_transaction;

    i2c_transaction.slaveAddress = address;

    i2c_transaction.writeBuf = (void *)txbuf;

    i2c_transaction.writeCount = txlen;

    i2c_transaction.readBuf = rxbuf;

    i2c_transaction.readCount = rxlen;

    bool rval = I2C_transfer(i2c, &i2c_transaction);

    System_printf("CLOSE MSTAT=%x\n",HWREG(I2C0_BASE + I2C_O_MSTAT));

    I2C_close(i2c);

    return rval;

}

int16_t GetMeasurement(void)

{

    uint8_t tx_buffer[2];

    int8_t real;

    // wake device

    tx_buffer[0] = 0x01; // register 0x01

    tx_buffer[1] = 0x00;

    bool i2c_stat = I2CCommand(&board_i2c_pins, I2CADDR, tx_buffer, 2, NULL, 0);

    DELAY_MS(150);

    // read value

    tx_buffer[0] = 0x00; // register 0x00

    i2c_stat &= I2CCommand(&board_i2c_pins, I2CADDR, tx_buffer, 1, &rval, 1);

    // shutdown device

    tx_buffer[0] = 0x01; // register 0x01

    tx_buffer[1] = 0x01;

    i2c_stat &= I2CCommand(&board_i2c_pins, I2CADDR, tx_buffer, 2, NULL, 0);

    return rval;

}

secondary interface task:

UART_Params uparams;

UART_Handle uhandle = NULL;

UART_Params_init(&uparams);

uparams.writeDataMode = UART_DATA_BINARY;

uparams.readDataMode  = UART_DATA_BINARY;

uparams.baudRate = 115200;

uparams.readTimeout = TICKS_PER_MS(200); // in ticks

uhandle = UART_open(Board_UART0, uparams);

.

.

.

// UART_read gets call many times because of the timeout; the data read in buf is used

// to determine when to stop reading. The multiple breaks also allow switching to the

// app task, so the I2C transactions will occur randomly during the UART_reads.

int len = UART_read(uhandle, buf, resize);

UARTCC26XX_Object *object = uhandle->object;

System_printf("rdst=%02x, len=%d", object->status, len);

.

.

.

UART_close(uhandle);

Please let me know if I can provide any other information.

dave

Hi Dave,

There should be no hidden HW interactions between the UART and I2C as far as I know. When you have MSTAT = 0x60, what is the status of the MCTRL register?

Hi M-W,

OK, thanks for the update. I did want to provide some additional information anyway. For the I2C, .sdaPin = IOID_13 and .sclPin = IOID14. The UART is using HW flow control, with .txPin = IOID_16, .rxPin = IOID_15, .ctsPin = IOID_17, and .rtsPin = IOID_18.

How do I check the "status" of the MCTRL register? It is write-only, correct? (If I try to read it after reading MSTAT, I just get the same value as MSTAT).

BTW, here is an example of the problem occurring during those 3 I2C transfers above:

[UART in blocking read, first attempt to access I2C device]

OPEN MSTAT=20

I2C_transfer return: 1

CLOSE MSTAT=20

OPEN MSTAT=60

I2C_transfer return: 0

CLOSE MSTAT=60

OPEN MSTAT=60

I2C_transfer return: 0

CLOSE MSTAT=60

dave

Hi M-W,

Sorry, that is just a typo; I am passing the a pointer to the parameter structure.

Currently the main app task is priority == 2 and the interface task with the UART is priority == 1.

In your test, are you performing a single blocking read that never completes and/or have you verified that multiple I2C open-transfer-close sets are occurring while that read is active? Just want to confirm that the conditions are the same. Something like this:

task P=1: blocking UART_read()

[idle function*, task switch to task P=2]

task P=2: I2C-open-transfer-close-1, I2C-open-transfer-close-2, I2C-open-transfer-close-3

[idle function, task switch to task P=1]

task P=1: UART_read completes with data or timeout or still blocks

[idle function, task switch to task P=2] etc.

I have not had time, but probably should add my own test to the v1.30.00.25 simple peripheral example this was derived from (but heavily modified since). As described earlier, I could actually reproduce this from within a single task by just opening the UART with the main task and performing the I2C transactions (obviously the other task was unable to function because it could not open the UART). Same symptoms--first transaction succeeds, others fail with stuck bus busy bit--but in that case, I was able to fix the problem by adding 3ms delay between I2C_close and I2C_open calls.

dave

Hi M-W,

OK, I will try to recreating it in a Simple Peripheral example.

dave

Hi M-W,

OK, the reason why the modified version of the SP example (with added periodic I2C transfers in simple_peripheral.c and new simple task that opens the UART and does repeated blocking reads with 3 second timeout) worked was because I (and perhaps you) was using the default  I2C and UART pins for the CC2640R2F LaunchPad board, i.e.:

SDA = IOID_5

SCL = IOID_4

UART_TX = IOID_3

UART_RX = IOID_2

I found this still worked with my regular SW compiled to run on that platform. However, we are using a custom development board that in practice uses a different set of pins, specifically:

SDA = IOID_13

SCL = IOID_14

UART_TX = IOID_3

UART_RX = IOID_4

That set fails in the way I described even for the modified SP example on the LaunchPad. (On the LP board, this combination works because pin 4 is still pulled high for I2C use, and pins 13 & 14 are tied to the left and right buttons, which are open by default. External pull-ups are required, but the cheap little luma sensor board I have for testing has them built onto it.)

Can you please try this combination of pins with your setup and let me know how it goes? I can send you my modified SP example source code, if that would help.

dave

Hi M-W,

OK, here it is. Sorry for the size. To make sure, I have included everything without doing a clean first, including the BLE Stack library, so that you would have everything I have. This code also includes a bit-bang debug logging UART tied to System_printf via app_ble.cfg. It is outputting at 921600 BAUD to pin DIO29 (which I jumpered to the debugger side of TXD). This makes it easier to follow what is happening (and I verified that it had no effect on the outcome by disabling it completely). I also indicate the I2C transfer status with the green and red LEDs (green on initially, and stays on unless there is a I2C transfer failure, in which case it switches to red on). The secondary task loops performing 3 second timeout blocking reads. I hijacked the 5 second periodic SimpleBLEPeripheral_performPeriodicTask function (which is now enabled immediately during init) to perform an I2C measurement.

 For HW, I used a CC2640R2F LaunchPad with nothing connected to it except jumpered debug UART and one of these: www.amazon.com/.../B06XHKTL58 connected to it with SCL on DIO14 and SDA on DIO13. Nothing is connected to the designated UART pins DIO4 and DIO3. This is just for testing purposes. I observed the problem on our custom board with different I2C devices, so I would not expect whatever you might have to matter.

There is a #if 1/0 in the secondary task in main.c to easily switch between having the UART open or closed. For completeness, I also included uart_open.hex and uart_close.hex in the FlashROM_StackLibrary directory.

Thanks for trying this. Please let me know if there is anything else I can provide or if you have any questions.

dave

simple_peripheral_cc2640r2lp_uart_i2c_issue.zip

OK, here it is exported with that checked. BTW, all I did was copied a local version of CC2640R2_LAUNCHXL.c into the Startup directory. The only mods to it are changing the 2 sets of pins per the earlier discussion.

dave

simple_peripheral_cc2640r2lp_uart_i2c_issue_2.zip

Hi M-W,

Any updates? Did you get a chance to try this test yet?

Thanks!

dave

Fixed!

Thanks, M-W!

dave