• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 547 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.

TMS570LS3137 N2Het

hans gutenberg
Intellectual 505 points

Hi,

I ' m using Het module and create  a program for serial port communication. My program and serial port work.  ı can see this data in serialmon. if ı cut communicate with this serial moon(disconnect cable) and my HTU is fulling 0xFF. and my buffer  is full and so generate a buffer full interrupt. and program continuous execute this interrupt. Another thing, I use RTI interrupt each 20 ms. But if program generate buffer full interrupt,Rti interrupt is not working. Thank you..

  • 0
    TI__Guru 68920 points

    Hans,

    I think we need a little more information but I gather your question is 'why is my HTU interrupt blocking my RTI interrupt'?

    Is that the right question?

    If so the things you might check are:

     a) what are the relative priorities of the HTU interrupt v.s. RTI interrupt.   (The priority mapping is programmable, so don't know how you ave it configured).   If the HTU is higher priority then that might be part of the reason.

     b) in the HTU interrupt are you exiting the ISR and then re-entering it immediately?  This is hard to tell by stepping through the ISR because usually the debugger will disable interrupts while stepping - and if you don't disable interrupts the hardware runs so fast anyway you'd always think you were popping right back to the ISR.    So to diagnose this you might do something as simple as set a GIO pin high at the beginning of your HTU ISR and LOW at the exit, and then see how much time is between individual ISRs by measuring the pulses on the pin.   Or you could do something like read the PMU performance counter and create a circular buffer of timestamps while running then inspect the timestamps to find out the what the times of the last N HTU interrupts were.

    If you find in (b) that you are jumping right back into the HTU interrupt then it's probably an interrupt request flag in the timer that needs to be cleared... and if you have the HTU interrupt at a higher priority than RTI it could block RTI out.

    Just some ideas. If you post more details we can try to help diagnose further.

  • 0 in reply to Anthony F. Seely
    Intellectual 505 points

    Hi,

    Thank you for quick answer.But I did not understand one thing.I want to explain one example. I have a serial port. It sends data. If serial port of tms570 disconnect the other cable (tms570  -> computer) , now serial port cable is empty but TMS570 is still execute so sent data but I can not see anything because of disconnect ). When I remeove cable tms570 and computer, HTU is fill 0xFF, but again connect this cable, htu works normal. While program sent data, If this serial port is connect anything, this rx pin of serial port is influenced by tx pin. or how is  HTU fill with 0xFF. Where is coming this data(0xFF)

    )

  • 0 in reply to hans gutenberg
    TI__Guru 68920 points

    Hi Hans,

    If I had to guess, I'd say that the HTU value of 0xFF is probably coming from the pin that you are receiving from. For example, if you had a UART and you tied the RX data pin high, it might receive 0xFF's  (if it were skipping the step to sync to the start bit falling edge).

    What kind of serial port are you trying to emulate, and how is it supposed to behave (e.x. is it supposed to wait and sync to a start bit & falling edge on the emulated RX data pin?)