• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 374 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.

TMS320F28335: SYS/BIOS: UART interrupts stop after calling Swi_post

stevenh
Guru 20075 points

Part Number: TMS320F28335
Other Parts Discussed in Thread: SYSBIOS

Hello,

My SysBios Application has the following:

Three HWIs: XINT1 (12kHz), SCIB Tx and SCI Rx.

Device Specific Timer: ti_sysbios_family_c28_Timer0 (250us Period)

Two SWIs and Four Task

Build Environment:

C2000 Compiler v21.12.0

SYS/BIOS 3.31.3.43

XDCtools v3.31.3.43

One of the Swis is posted (Swi_post() ) every 4 calls to Timer0, which means the swi is posted every 1ms. Given this setup, serial communication is not working, however, serial communication works if I comment out the Swi_Post.

Increasing the Swi_post period doesn't solve the issue.  

Why would a Swi_post stop UART communication?

Stephen

  • 0
    Guru 20075 points

    I found a Task_sleep() in the Swi because it was previously a SYS/BIOS task.  Removing it didn't correct the issue.

    Increasing both the HWI/SWI stack size and the Swi_post period (to 33 = 8.25ms) corrects the issue, however, I am still concerned about the issue.  The SCIB Rx HWI is never called if the SWI post period  = 8 (1ms). I have analyzed timing for  ti_sysbios_family_c28_Timer0 and XINT1 HWIs and there should be more than enough processing time for the SCIB Rx HWI to be called.

    Any ideas?

  • 0 in reply to stevenh
    TI__Guru 54765 points

    Were you seeing signs of stack overflow in ROV or in the memory browser? It seems strange that increasing the stack would solve the problem if not.

    Are you seeing errors in the SCI status registers? Can you see the interrupt flag being yet? I'm wondering if you're able to determine if the SCI failure is rooted in the SCI peripheral itself or if it's a matter of the RTOS failing to handle the interrupt?

    Whitney

  • 0 in reply to Whitney Dewey
    Guru 20075 points

    I set the sys/bios library type to non-instrumented.  Should I set it to a different type?  Where in the ROV would I look for a stack overflow?

    It is impossible to see if the SCI interrupt flag is being set.

  • +1 in reply to stevenh
    TI__Guru 54765 points
    stevenh said:
    I set the sys/bios library type to non-instrumented.  Should I set it to a different type?  Where in the ROV would I look for a stack overflow?

    I think that's fine. If I recall correctly most of ROV should still work, but there just won't be log messages to view. Stack overflow is usually visible in the BIOS section in the "Scan for errors..." tab. You can also to the Task module to check on your Task stacks or the Hwi module to check on the system stack.

    stevenh said:
    It is impossible to see if the SCI interrupt flag is being set.

    I'm not sure what you mean. Can you not check the SCI registers (SCICTL2 & SCIRXST or SCIFFTX & SCIFFRX if you're using FIFO) in the CCS Registers view?

    Whitney

  • +1 in reply to Whitney Dewey
    Guru 20075 points

    I have fixed the issue. 

    I made several changes to fix the issue.  I think the change that had the most affect had to do with a bug in the state machine where the state names (enums) did not exactly match the actual state function array.  This caused one of the states to be called, exit and then be called again.  This happened continuously.  Each time the state exited a Record was queued (to be written to eeprom).  This caused the queue to fill up and eeprom records to be continuously written.

    I also did the following:

    1. Reduced the baud rate from 115200 to 57600.

    2. Change I2C from a ISR to a HWI.  I didn't use Hwi_plug() when it was an ISR.

    3. Reduce the call period of a function (in the state machine) that performed slightly intensive floating point operations.

    4. Change the priority of all Tasks.

    Whitney Dewey said:
    I'm not sure what you mean. Can you not check the SCI registers (SCICTL2 & SCIRXST or SCIFFTX & SCIFFRX if you're using FIFO) in the CCS Registers view?

    I only checked the PIE IFR register.  I would think it would stay set if the SCIB interrupt occurred and wasn't serviced.