• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 32 subscribers
  • Views 1358 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.

SCI Interrupts & VIM

James Stanley
Prodigy 160 points
Other Parts Discussed in Thread: HALCOGEN

I'm implemementing a simple, interrupt driven, SCI loopback test on a TMS570LS31x USB Development Stick. The test seems to work well when using the VIM to automatically dispatch the ISR, but I want to use my own dispatch routine so I can add some common ISR processing around the actual ISR handler.

Most of the time this is ok, but I'm finding that occasionally, I get an overrun error and a character is dropped. Identical code has run fine on an RM48, so I'm wondering if there is any difference in the VIM modules of the two processors that I should be aware of? Is there any ISR acknowledgment required when using the ARM vector table rather than the VIM module to dispatch the IRQ?

  • 0
    TI__Intellectual 2310 points

    Stanley

    Thanks for using the forum.

    I can confirm to you that the RM48 and LS31x have identical VIM modules.

    You must be reading the IRQVECREG reister which would clear the flag automatically. There is no other manual clear required.
    Are you doing any other operation on the VIM apart from this?

    Just to debug further please let me know
    - the speed of SCI operation
    - are you spending a lot of cycles in the ISR?
    - Is the speed of CPU and VIM 180MHz and 90MHz respectively?

    We could go on and inspect your ISR to make sure there is nothing missed there.

    Also please confirm that what is working is the "Hardware vector interrupt" mode.

  • 0 in reply to Abhishek Shankar
    Prodigy 160 points

    Thanks for the response.

    I've discovered that, even when using the VIM to dispatch the ISR, eventually (after a few hours) an overrun error occurs.

    The most significant differences between the code I have running on the RM48 and LS31x is the clock speeds. The Quick Start Guide for the LS31x USB Stick Development Kit states that HCLK must be limited to 100MHz, consequently the SCI module has a 50MHz clock. Is there a reason for this limitation (by contrast, the RM48 is running with HCLK = 160MHz, SCI clock = 80MHz)?

    The SCI is running with a baud rate of 38400. There is currently one other ISR running in the application (RTI compare).

  • 0 in reply to James Stanley
    TI__Intellectual 2310 points

    James

    Yeah the USB port would violate the standard's capability if you were to run the part at a higher speed. That is why the limit of 100M is being placed.

    I have one suggestion to confirm that the problem is indeed being caused by the SCI speed relative to the CPU speed. Can you please try to reduce the speed of SCI by a factor approximately (160/100) i.e. to ~38400/1.6 = 24kbps? If this works ok, you might be able to confirm that the speed is the issue.

    If you can, please share the complete code and project and I can give it a shot on my side too.

  • 0 in reply to Abhishek Shankar
    Prodigy 160 points

    I believe I have overcome this problem by maping the RTI Compare 0 interrupt to channel 94, thus leaving the SCI interrupt as the highest priority interrupt in the application. With this configuration, the test has run for over 13 hours without losing any transmissions, so ....

    This exercise did lead me to find several problems with V3.00.01 of HALCoGen:

    1. It is not possible to use HALCoGen to change the CHANMAP registers.
    2. Although the VIM RAM page allows you to specify ISR handlers for all 96 interrupt channels (the phantom ISR and channels 0 - 94), the vector table, s_vim_init, created in sys_startup.c only contains entries for the phantom interrupt and channels 0 - 89 (although sys_vim.h does include externs for all the entries). The setting of the FIRQPR and REQMASKSET registers also only support up to channel 89.
    3. When s_vim_init is copied into the actual VIM RAM, the for loop is limited by the constant 90, meaning that only the address of the phantom interrupt and channels 0 - 88 is actually copied to the processor.
    4. The vimRAM_t structure defines an array of 94 ISR pointers, due to the use of the constant VIM_CHANNELS - the structure should have 96 entries.
  • 0 in reply to James Stanley
    TI__Intellectual 2310 points

    Thanks for figuring out the solution. So it was indeed a throughput related problem. I am glad you found a fix.

    Thanks for pointing out the shorcomings. I am going to send them to our Halcogen s/w owner.

  • 0 in reply to Abhishek Shankar
    TI__Mastermind 22375 points

    James,

    If your question has been answered, could you please mark it has "Verified Answer" so we can close this thread?

    Thanks and Regards,

    Jean-Marc