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

Added significant delay for HWI in SYS/BIOS Project vs. Non SYS/BIOS Project

Mike Volzer
Intellectual 990 points
Other Parts Discussed in Thread: SYSBIOS, CONTROLSUITE

Hello,

To start, I am using the following tools:

SYS/BIOS: 6.33.1.25

XDCtools: 3.23.0.32

CodeGen Tools: 6.0.2

Board: Piccolo 28069 ControlCARD

Code Composer v5.1.1.00031

I am using the ECAP peripheral to trigger an interrupt on rising and falling edges of an external source that is oscillating at ~250Hz. In the ISR I am toggling a GPIO pin to check the timing between when the stimulus comes in and the ISR is serviced. When the application is run without using SYS/BIOS the delay between the stimulus and the GPIO toggle is ~424ns worst case. When the application is run with SYS/BIOS the delay fluctuates between ~500ns and ~16us worst case. The application isn't doing anything else, no other interrupts or tasks. This seems rather long considering 16us is ~1300 cycles on this part.

I tried bypassing the HWI dispatcher by adding the following lines to the cfg file:

Hwi.zeroLatencyIERMask = 8;
Hwi.nonDispatchedInterrupts["ecapHWI"] = new Hwi.NonDispatchedInterrupt();
Hwi.nonDispatchedInterrupts["ecapHWI"].intNum = 56;
Hwi.nonDispatchedInterrupts["ecapHWI"].fxn = "&ECAP1_Int_Handler";

I also did the equivalent at runtime using Hwi_plug function and plugging the ISR directly into the PIE vector table. However, this yielded the same results. The ISR code is also being run out of RAM. I'm wondering if maybe there is something else that I am missing or something that I need to add to the cfg file?

For reference I've attached two pictures, one of the non-SYS/BIOS application and one of the SYS/BIOS application.

In the following scope traces the yellow signal is the stimulus causing the interrupt through the ECAP module. The green signal is the GPIO that is being toggled in the ISR. The scope capture is set with infinite persistence and the code was run for a few minutes in order to catch multiple instances of worst case delay.

Non-SYS/BIOS, notice the delta of 424ns

SYS/BIOS, notice the delta of 16.184us

Thanks for your help,

Mike

  • 0
    TI__Mastermind 32475 points

    Mike,

    Are you building the "release" version of  "debug" version of the SYSBIOS program?

    And you are confident that no other interrupt is coming in because BIOS enables a Timer by default.

    Judah

  • 0 in reply to judahvang
    Intellectual 990 points

    judahvang said:

    Mike,

    Are you building the "release" version of  "debug" version of the SYSBIOS program?

    And you are confident that no other interrupt is coming in because BIOS enables a Timer by default.

    Judah

    I am using the release version of SYSBIOS.

    I am not sure that the timer interrupt is not coming in. Is it possible to disable the timer interrupt or make my ecap interrupt a higher priority than the timer?

    I was under the impression that bypassing the HWI dispatcher would allow my ecap interrupt to preempt any other interrupts. Is this true?

    Update:

    I've unchecked the "Enable Clock Manager" button in the cfg file and this cut the delays down to ~ 1.2us max. This is much better, however, in my application I need the clock functionality that allows BIOS calls to timeout. Is there some way to keep my delays small and somewhat consistent and still allow the timeouts to be used?

    It is my understanding that the timer HWI is simply posting a SWI. Why is it that my HWI would be pushed off for so long if the timer HWI ISR is only posting a SWI?

    Thanks,

    Mike

  • 0 in reply to Mike Volzer
    TI__Mastermind 20805 points

    Hi Mike --

    It looks like there might be a bug in the Hwi dispatcher when using the zero-latency mode.  We're looking into it and can hopefully fix in the 6.33.05 release scheduled for end of this week.

    -Karl-

  • 0 in reply to Mike Volzer
    TI__Mastermind 30830 points

    Mike,

    You mentioned that the ISR code is in RAM.

    Where is the SYS/BIOS code executing from?

    And what memory are you using for the ISR and task stacks?

    The SYS/BIOS interrupt dispatcher pushes registers onto whichever stack the processor is using when a dispatched interrupt occurs, then switches to the shared ISR stack if it isn't already on it.

    If the dispatcher's code and/or stack are in slow memory that might explain the excessive jitter you are seeing.

    Can you share your applications .map file?

    Alan

  • 0 in reply to Alan DeMars
    Intellectual 990 points

    Karl,

    Thank you for the update.

    Alan,

    The SYSBIOS code should be executing out of flash. ECAP ISR code is being run out of L03SARAM. Task stack sections is in L46SARAM (only task is the idle task). System stack is in M01SARAM. So I suppose I should try moving the dispatcher code into RAM. I'll look into this.

    I've attached my map file to this post.

    7127.my_app_test_map.txt

  • 0 in reply to Mike Volzer
    TI__Mastermind 20805 points

    Mike --

    I think you need to initialize the FLASH for the Concerto board.   I think the default is 15 wait states and it can be tuned down to 3.

    There's and ADC example that uses SYS/BIOS + ControlSuite which includes some FLASH init code that might be useful.

    http://processors.wiki.ti.com/index.php/SYS/BIOS_and_controlSUITE_ADC_Example

    -Karl-

  • 0 in reply to Karl Wechsler
    Intellectual 990 points

    Karl,

    I added the code to change the flash wait states for my Piccolo part.

    I am also now running sysbios out of RAM rather than flash.

    The HWI latency now fluctuates anywhere from 400ns to 1.6us. What would cause this variation?

  • 0 in reply to Mike Volzer
    TI__Mastermind 30830 points

    Mike,

    So nothing is left in FLASH?

    Can you share your latest map file?

    Alan

  • 0 in reply to Alan DeMars
    Intellectual 990 points

    Alan,

    I followed the suggestion from this link: SYSBIOS FAQs

    I've attached the newest map file.

    8015.test_map_ram.txt

  • 0 in reply to Mike Volzer
    TI__Mastermind 30830 points

    Mike,

    You're almost there.

    Can you also arrange for ".text" to run from L07SARAM?

    This should pick up your main.c code, the codegen tools RTS library, as well as the xdc RTS library code.

    If that isn't enough, you may have to also copy the ".econst" section into L07SARAM also.

    Depending on your application some of these constants may be accessed quite frequently.

    For even better performance, if you aren't doing this already, try disabling Asserts and Logs by adding the following to your confiif file:

    BIOS.logsEnabled = false;
    BIOS.assertsEnabled = false

    Alan

  • 0 in reply to Alan DeMars
    Intellectual 990 points

    Just as a follow-up to this, it is not entirely necessary to move all of the SYS/BIOS code into RAM for execution.

    With help from the TI SYS/BIOS team I've found that moving the HWI dispatcher code and the isr code into RAM for execution is enough to reduce the latency times. The dispatcher can be linked into RAM by using the following line in your linker command file.

    .hwi: { *.*(.text:*ti_sysbios*_Hwi_*) } > RAM_SECTION, PAGE = 0

    Further investigation on moving the code around in different sections of RAM didn't yield significant changes in results.

    It is also important to note that setting the flash wait states in this part makes a huge difference when running code out of flash memory.