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

Can't receive POSIX timer signal while linking DSPLink

Carl Miller
Intellectual 260 points

I'm developing a DSPLink application for an OMAP-based target.  The DSP core, running DSP/BIOS does all the real work, while the ARM core, running Linux does performance monitoring, and implements a UI.  I have a problem on the ARM Linux side...

My UI makes use of a POSIX timer (timer_create, timer_settime calls) to deliver a signal.  I'm using (SIGRTMIN + 3) as my timer signal.  You'll note that this is not one of the signals standardly caught by DSPLink.  I can compile the UI code two ways: into a test shell that is just the UI, doesn't link with DSPLink, and doesn't do anything but provide a mockup of the UI, or into the full application that links with DSPLink and loads, runs, and monitors the DSP code image.

When I compile the UI into a test shell, I get my timer signal, and the UI works.  When I compile the UI into the full DSPLink application, I do not get my timer signal.  Same UI code.  All the system calls setting up the POSIX timer, setting up the signal handler, etc, all succeed, but mysteriously the signal is just not delivered to my application.  I've even taken an strace of both the UI test shell and the full application.  As far as timers and signals go, they look identical except that the (SIGRTMIN + 3) signal just plain never arrives to the full application.  The strace of the full application shows that nothing but my UI code is referencing that signal for anything.  So I'm stumped as to how the signal just fails to arrive.

I added a debug function to print out: 1) is the signal blocked? 2) is the signal pending? 3) what's the handler registered for the signal? 4) is the timer running or expired? 5) is the flag that my signal handler sets set or cleared?  I hooked the debug function to a key and press the key twice, once before the timer is supposed to have expired, and once after.  Results:

Before:  not blocked, not pending, handler is my UI code signal handler, timer running, flag cleared.

After:  not blocked, not pending, handler is my UI code signal handler, timer expired, flag cleared.

It's like the Linux kernel itself is swallowing my signal, and allowing the timer to expire without any notification.  Again, trace of UI test shell shows (SIGRTMIN + 3) arriving.  Trace of full application does not.  And it only happens when I link in DSPLink.

I'm stumped.  I'd appreciate any thoughts anyone has.

  • 0
    TI__Genius 12025 points

    Carl,

    Maybe the DSP is using the same timer? Check the DSP configuration to see which timer it's using for the DSP/BIOS tick.

    ~Ramsey

  • 0 in reply to Ramsey
    Intellectual 260 points

    Hi, Ramsey.  I really appreciate your giving my question some consideration, but I think you're misunderstanding the issue...

    A POSIX timer is a purely software construct inside the Linux kernel.  I'm sure the Linux kernel is itself making use of a hardware timer for all of its activities, but if there were a conflict bewteen that and the DSP, it would be abundantly evident, as the operation of the entire kernel would be messed up.  I'm sure TI has made sure long ago that Linux and DSP/Bios play nice with each other regarding sharded hardware timers.  And once that's taken care of, all of Linux's software timers fall into place, as the generic parts of the kernel wouldn't use anything other than the configured platform hardware timer as their basis of timekeeping.

    Besides which, my POSIX timer itself works.  It counts down accurately, and expires at the appropriate time.  At any point, I can poll it, and I see the correct amount of time remaining.  My issue is only that I don't get a signal upon expiry.  This would seem to be an problem purely of signal delivery.

  • 0 in reply to Carl Miller
    TI__Genius 12025 points

    Carl,

    Okay, thanks for the explanation. You mention signals, it is really a signal you expect? If so, then maybe DSPLink is hiding the signal. DSPLink registers a signal handler to clean up in case of a crash. Perhaps the problem is there. Have a look at DRV_installCleanupRoutines() in

    dsplink/gpp/src/api/Linux/drv_api.c

    You could try commenting out the code to see if you get your signal.

    ~Ramsey