• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 100 subscribers
  • Views 3333 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.

I2C and UART

Jody Tanaka
Prodigy 185 points
Other Parts Discussed in Thread: CC2650

Hi guys,

Could you please somebody can help me?

I have two issues here when I tried to use the TI-RTOS lib to I2C and UART.

When I initialize I2C my project hang at line 858 of I2CCC26XX.c:

Semaphore_pend(Semaphore_handle(&(object->transferComplete)), BIOS_WAIT_FOREVER);

I had the similar error when I try to read something at UART, it´s hanging waiting the semaphore release.

I don´t know if I need to initialize other thing before these features.

My impression is that interruption to read or wait the transaction of i2c is not happening, but I don´t know what I can do.

When I use the TI-RTOS lib to SPI I also cannot used, I´m using to SPI the driver lib directly, so probably I´m not using the TI-RTOS lib correctly.

Best Regards,

Jody.

  • 0
    TI__Mastermind 30830 points
    Jody,

    Are I2C_transfer() and UART_write() being called from within a Task thread? These APIs can not be called from main().

    Also, which version of TI-RTOS are you using and on which device platform?

    Alan
  • 0 in reply to Alan DeMars
    Prodigy 185 points

    Hi Alan,

    These API´s are not being called from main(), they are called by different task that I created.

    My TI-RTOS version is: tirtos_simplelink_2_14_02_22.

    As I inform, for SPI I had the same problem and in my project I´m using directly with driverlib, but I would like to use the TI-RTOS libs, but it is not working properly for me.

    Regards,
    Jody.

  • 0 in reply to Jody Tanaka
    TI__Mastermind 30830 points
    All these symptoms are consistent with interrupts being globally disabled, preventing the interrupt handlers that post the semaphores from going off.

    Are you using the CCS debugger? If so, when you halt the program, can you tell if interrupts are globally enabled (ie what is the value of the BASEPRI register as shown in the "CTRL_FAULT_BASE_PRI" breakout in the Core Registers view ? It should be '00000000' when interrupts are enabled. It will be 00100000 when interrupts are disabled. Also, the 'PRIMASK' field should always be '00000000'.

    Alan
  • 0 in reply to Alan DeMars
    Prodigy 185 points

    Hi Alan,

    Thank you very much for your suggestion, I will try to check, I´m using IAR, is not CCS, but I think it is possible to check these registers.

    I will check and I will let you know.

    I´m working on this project in my free time (out of job), so I´m sorry if I reply a little bit later.

    Regards,

    Jody.

  • 0 in reply to Jody Tanaka
    Prodigy 185 points
    Hi Alan,

    I tested here and I saw some registers at IAR: BASEPRI, BASEPRI_MAX, PRIMASK and FALTMASK, all of them are with 0 value. I forgot, but I´m using CC2650, so I don´t know if the register names are different. I didn´t see the register CTRL_FAULT_BASE_PRI, maybe will be FALTMASK?

    Regards,
    Jody.
  • 0 in reply to Jody Tanaka
    TI__Mastermind 30830 points
    "CTRL_FAULT_BASE_PRI" is a CCS-ism. It's a shorthand representation of the four 8-bit registers (Control, FaultMask, BasePri, Primask).

    So, it appears that global interrupts are enabled so that isn't want is preventing the interrupts from going off.

    I am concerned that when you say "in my project I´m using directly with driverlib", that may mean the TI-RTOS version of your application has some remnants of the driverlib-only version

    Specifically, I'm concerned that the interrupt vector table is NOT being provided by TI-RTOS. Also, does your application use any driverlib calls to enable or disable specific interrupts (ie the SPI I2C, UART interrupts)? TI-RTOS expects to manage the vector table as well as all the interrupts in the vector table using its own APIs.

    Are you able to share you IAR project? That might help me locate/recreate the problem.

    Alan
  • 0 in reply to Alan DeMars
    Prodigy 185 points
    Hi Alan,

    For share my project, could you please share your e-mail or skype to we can talk about it?

    Thanks,
    Jody.
  • 0 in reply to Jody Tanaka
    TI__Mastermind 30830 points

    After a review of the Board.c file, it appears that the project had been migrated from an older TI-RTOS version to the 2.14.02 release without adding the new .intPriority field assignments in the I2C, and SPI HWAttrs.

    The result of this missing field assignment was that the I2C Hwi object was constructed using priority 0, which is interpreted as the application wanting to use the zero-latency interrupt mechanism, which bypasses the interrupt dispatcher when an interrupt is taken.

    Subsequently, when an I2C interrupt occurred, the necessary task scheduling safeguards were not taken to properly handle the I2C interrupt handler's Semaphore_post() call. This resulted in the thread of execution immediately switching to the blocked task code without properly returning the M3 core from handler mode to thread mode. This left the CPU running task code in handler mode at the highest interrupt priority, thus effectively disabling all other lower priority interrupts from being serviced.

    Simply adding this assignment:

         .intPriority = (~0);

    to the i2cCC26xxHWAttrs struct initializer in the project's Board.c  file cleared the problem up.

    Precautions have been taken in newer (2.15, 2,16) TI-RTOS driver code to avoid this problem by changing the structure typedef name of those HWAttrs that have changed from previous releases. This results in a compile-time error if the user hasn't migrated their board.c file properly.

    Alan

  • 0 in reply to Alan DeMars
    Intellectual 270 points

    Hi Alan,

    I am trying to access my I2C peripheral using my cc2650 custom board. I am stuck at the same exception and status of BASEPRI register shows that the global interrupts are disabled. How am I supposed to enable the global interrupts?

  • 0 in reply to ABHINAV KUMAR
    TI__Intellectual 2275 points
    Hi Abhinav,

    Are you still having your interrupt issue? If you open up a new thread, we will gladly be able to assist you.

    Thanks,
    Gilbert
  • 0 in reply to Gilbert Rodriguez III
    Intellectual 270 points
    Hi Gilbert,

    I have crossed that particular problem.Thanks for responding.