This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1312R: I2C and UART interaction

Part Number: CC1312R

Hi!

We are observing some interaction between the UART and I2C on the CC1312. When we are starting a UART reception the callback triggers immediately and reports that it is one character in the reception buffer. This character seems to be bitwise all ones at the start, because the received character is always 0xF0, or 0xF8, 0xFE or something similar. It is not a character we actually sent on the physical line.

This behavor is not observed if I do not initialize the I2C. The I2C only needs to be initialized (not actually used) for the problem to occur. However, if I trigger a transmission on UART TX just before I start a reception the problem goes away even if I2C is initialized.

If I2C is not initialized, the UART works just fine and we can both send and receive without problems.

We are not using CCS and our code is not based on any of the examples. It is based on Contiki-NG. Compiler is GCC. We're using a pretty old Core SDK, I believe it is v4.30.

Are there any known issues that you know of that could cause this?

  • Digging a little further, I observe that the problem goes away if I insert a delay ( an empty for loop with a few tens of iterations ) after PRCMLoadSet(); in function Power_setDependency(uint_fast16_t resourceId) in the file PowerCC26X2.c in Drivers. Inserting a delay before PRCMLoadSet(); does not fix the problem. Can it indicate that there is something internally that is not stabilized when I try to use the UART? Could it be any flags in a register or something I can check?

  • Hi Frode

    This is not a problem we have heard of before. If we are going to look into this, this must be something that you can recreate using our dirvers (power driver, uart driver and I2C driver). Since you are playing around with the driverLib functions you mention, I suspect that you are not using our drivers?

    BR

    Siri

  • Hi Siri,

    Thank you for your answer.

    I'm not using the driverlib here directly in my own code, but I'm modifying and rebuilding the drivers to pinpoint and "fix" the problem. I was modifying inside the file PowerCC26X2.c (located in source/ti/drivers/power/PowerCC26X2.c)  , which is part of the drivers.

    Specifically, I did this change (inserted the line commented as "Fixes..."):

            /* is resource a peripheral?... */
            if (resourceDB[resourceId].flags & PowerCC26XX_PERIPH) {
                PRCMPeripheralRunEnable(id);
                PRCMPeripheralSleepEnable(id);
                PRCMPeripheralDeepSleepEnable(id);
                PRCMLoadSet();
    for(volatile int i=0;i<100;i++); // Fixes the problem
                while (!PRCMLoadGet()) {
                    ;
                }
            }
    
    

    I think that to recreate the problem would have us make another test project, so it will probably not be done for some time unfortunately. However, I'm still curious about these questions I raised above:

    Can it indicate that there is something internally that is not stabilized when I try to use the UART? Could it be any flags in a register or something I can check?
  • Unfortunately I cannot tell. When using our drivers, they should take care of checking all flags etc. to ensure proper operation, so we do not have any additional things that is recommended to check

    As I said, we would need to have a way to recreate the problem, and when we do, I can ask for R&D resources to look into it to try to understand why it is happening, and why your "fix" fixes the issue.

    I guess it should be fairly easy to make a "demo" that illustrate this, as there are both Uart and I2C examples in the SDK that can be used as a starting point.

    BR

    Siri