• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 306 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.

Problem when using I2C Driver from periodic task

Jens H.
Prodigy 130 points

Hello every one,

I have a problem using the I2C Bios driver on the C6747 in a periodic task.

If I use the my funktion i2cWriteMCP(I2C_SLAVE_ADDR_MCP_000,0xFFFF); out of a normal task, everything works fine.

If I use the same statement in a periodic task generated with the graphical DSP/BIOS config tool I get stuck in the function Void I2c_localEnsureIsReadyforNext(I2c_Object *instHandle) in the I2C driver in a while loop

 while ((((instHandle->deviceInfo.baseAddress)->ICSTR
                    & CSL_I2C_ICSTR_ARDY_MASK) == 0)
                    && (delay != 0))
                {
                    delay--;
                }

until the variable delay is counted down to 0 (that takes around 1 second). This even happens, when I set the periodic task to for example to 2 seconds.

This seams to happen because the STOP bit in the  dataParam->flags is not set anymore and therefore the if statement

 if (FALSE != (dataParam->flags & I2c_STOP))

is false. I found this by comparing the two methods using my function.

If I use i2cWriteMCP(I2C_SLAVE_ADDR_MCP_000,0xFFFF); out of the periodic task, the STOP flag in dataParam->flags is always set correct.

Can anyone tell my what I am doing wrong? I am not yet very familar with all the driver and DSP/BIOS stuff.

Thanks in advance!

Jens

 

  • 0
    TI__Guru*** 125430 points

    What do you mean by "Periodic Task"?  Are you talking about the PRDs?  If so, those are actually SWIs not TSKs.  If the driver is trying to pend anywhere then that would be illegal from a SWI/PRD.  Perhaps that's the reason for your odd behavior.

    If you want a task to run periodically then you can still do that, but rather than putting your code directly in the PRD, you should instead configure the PRD function in the BIOS config GUI to call _SEM_post with an argument of your SEM object.  That way you have a task of whatever priority you choose that does a SEM_pend and then periodically you will have the corresponding SEM_post so that it runs.  That way your task can run periodically, but function calls will be from the context of a TSK rather than SWI.

    Brad

  • 0 in reply to Brad Griffis
    Prodigy 130 points

    Hi Brad,

    and thanks for your help. I did not realise that a PRD is a SWI.

    I did what you suggested and used SEM and it looks good. Thanks.

    Jens

  • 0 in reply to Jens H.
    TI__Guru*** 125430 points

    Jens,

    I'm glad that did the trick!  PRD is the highest priority SWI.  Another one to know is that there is a TSK_idle which is the lowest priority task.  The IDL functions get called in a round-robin from TSK_idle.  You cannot block in an IDL function because there is nothing else for the scheduler to execute beneath it.

    Brad