• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 1065 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2541: Wrong I2C data when datarate is getting fast

Daniel Fang
Genius 11600 points
Part Number: CC2541

Hi

The right data should be 0x10000110, but actually it's 0x10111111, false data start from the 3rd bit.

a. It's working well when data rate is below 78KHz.

b. 100KHz, it appear above false long 1 data. Sometimes , it start from the 1st bit, sometimes start from one middle bit.

c. 100KHz, it's working well if running CC2541 peripherals I2C example, which has no BLE function.

Is it caused by BLE priority? We set BLE interruption priority higher than I2C. Thanks.

 

  • 0
    TI__Mastermind 23396 points
    Hello Daniel,

    Can you explain more about your project? From what I can tell from your post this is a BLE project + I2C.

    Are you using SimpleLink SDK for I2C?
    How many tasks are you running?
    What are the priorities of these tasks?

    Regadrs,
    AB
  • 0 in reply to AB
    TI__Genius 11600 points

    Hi AB,

    Thanks for your reply. Already find the root cause. Which is caused by customer wrong porting.

    They porting I2C driver from CC2541_43_44_45_Peripherals_Examples directly to Simpleperipheral example. I2C interruption function are running with OSAL task at the same time.

    We need CC2541 running at I2C slave mode + BLE connected beacon mode.

    Which document or example could help us porting I2C slave driver to Simpleperipheral example? Thanks a lot.

  • 0 in reply to Daniel Fang
    TI__Mastermind 39800 points
    Daniel,

    Can you clarify?

    Are you asking how to create a separate task to simple peripheral for the i2c code? As in you already have functioning drivers for i2cslave that just need to be integrated into the simple peripheral code?
  • 0 in reply to Evan W
    TI__Mastermind 39800 points
    Daniel,

    If you are trying to add/make a separate task to simple peripheral for your i2c code, this might be the best document to reference in understanding how to do that with OSAL etc. www.ti.com/.../swru271g.pdf

    (Chapter 3)
  • 0 in reply to Evan W
    TI__Genius 11600 points

    Hi Evan,

    I know this document, we are refering to SerialBLEbridge example to porting I2C initializatin and interruption code.
    http://processors.wiki.ti.com/index.php/SerialBLEbridge_V_1.4.1

    My question is:

    1. What's your point about is it caused by the mix use of OSAL and none OS I2C driver? I tell customer clearly that it absolutely can't put none OS I2C driver running on OSAL project example directly.

    2. Could you provide an I2C slave OSAL example? Otherwise, it will bring us even more questions when the customer new guy is not familiar with OSAL. I am sorry that I can't point out their error at every time when they porting I2C driver. Thanks a lot. 

  • 0 in reply to Daniel Fang
    TI__Mastermind 39800 points
    Daniel,

    The best place to start for your customer is examining how the SensorTag Project works:
    C:\Texas Instruments\BLE-CC254x-1.4.2.2\Projects\ble\SensorTag

    In the SensorTag project, it has a hal driver using i2c running in master mode.

    Since OSAL is essentially controlling the whole device (running ble stack etc), OSAL does need to be aware of the context of the I2C. Therefore if you inspect the SensorTag project, you can get an good idea of how to do this. Start from SensorTag_main.c and see what each function does, how it's tied to one another and hwo it processes events.

    In main.c, there is a function osal_init_system() which then inside of it has a function osalInitTasks(), which in turn calls SensorTag_Init() which initializes lots of sensors and other stuff. Using the TI_BLE_Software_Developers_Guide.pdf in the SDK install directory and this application, the customer will have enough to ramp.

    To handle the interrupts, you should look within the context of the sensortag project as well. There are key's that when pressed, trigger an interrupt which sends an OSAL event message up to the application to be processed. Therefore, the I2C slave driver needs to be written in the same way, such that when a message is coming in, an OSAL event message is sent up to the application and processed. Below is a thread that discusses this some.

    In SensorTag.c you cans ee where these events are processed (SensorTag_ProcessEvent) which calls sensorTag_ProcessOSALMsg() where the key presses are handled.

    e2e.ti.com/.../221621
  • 0 in reply to Evan W
    TI__Genius 11600 points

    Hi Evan,

    Thanks for your comments.

    Could you kindly have a look attached code? We add it to SimpleBLEPeripheral project.

    In order to avoid I2C wrong bit issue, disable all interruption once enter in I2C interruption function. Is there any risk to BLE? Thanks.

    I2C Close Interuption Code.zip

  • 0 in reply to Daniel Fang
    TI__Mastermind 39800 points
    Daniel,

    I would advise against disabling interrupts when performing peripheral driver operations. This could cause you to miss BLE protocol timing events, and if this occurs at the right time, result in undefined behavior.

    For the code you provided, I would move the i2c polling you're doing into the I2C process function and from the ISR just send up some message/event to do the processing in that function.

    The best rule of thumb is to keep your ISRs short and queue up messages for other functions/tasks to process. If this doesn't work, we can discuss other methods potentially. Unfortunately, this is just made difficult due to the fact that the CC2541 and other devices can't block the BLE tasks.
  • 0 in reply to Evan W
    TI__Mastermind 39800 points
    As a reference, please read Section 7.6.2 and Section 7.6.3 of the software developers guide located here:
    C:\Texas Instruments\BLE-CC254x-1.4.2.2\Documents
  • 0 in reply to Evan W
    TI__Genius 11600 points
    Thanks. It can close the thread now.