rtems_binary_semaphore_post from IRQ handler

[Ярослав Лещинский]

Suddenly your email goes to spam...


Yes, I have enlarged stack size and application ran well.

вт, 7 мая 2019 г., 19:22 Joel Sherrill <joel at rtems.org>:

>
>
> On Tue, May 7, 2019, 11:11 AM Ярослав Лещинский <midniwalker at gmail.com>
> wrote:
>
>> problem solved: that was silly mistake related to the task min size.
>>
>
> Stack minimum?
>
>>
>> Thanks for your support, guys.
>>
>> On Mon, 6 May 2019 at 17:16, Ярослав Лещинский <midniwalker at gmail.com>
>> wrote:
>>
>>> Hello again,
>>>
>>> >>Maybe
>>> >>this is related to an interrupt with a too high priority, see also:
>>> >>https://lists.rtems.org/pipermail/users/2019-April/033102.html
>>>
>>> I have played around with priorities but no luck.
>>>
>>>
>>> >>What type of fatal error are you seeing?
>>>
>>> *** FATAL ***
>>> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>>>
>>> R0   = 0x20009040 R8  = 0x00000001
>>> R1   = 0x2000374c R9  = 0x00000005
>>> R2   = 0x20009040 R10 = 0x2000f0d8
>>> R3   = 0x00000000 R11 = 0x00000005
>>> R4   = 0x20009040 R12 = 0x00000000
>>> R5   = 0x00004000 SP  = 0x2000a1b8
>>> R6   = 0x2000ecf8 LR  = 0x0000980b
>>> R7   = 0x00000002 PC  = 0x20003c80
>>> XPSR = 0x60000000 VEC = 0x00000003
>>> RTEMS version: 5.0.0.46b8638288a51cc175067be12a20301b3fb83ec7-modified
>>> RTEMS tools: 7.3.0 20180125 (RTEMS 5, RSB
>>> f07d2b6e9ad70d62eb617a9f5515c5045ee0c119, Newlib
>>> 08eab6396f678cf5e5968acaed0bae9fd129983b)
>>> executing thread ID: 0x08b010002
>>> executing thread name:
>>>
>>> My application is a wlan ap initialization using TI sdk for cc3100.
>>> Using this sdk, I'm creating separate tasks. Actually sequence of my
>>> actions are:
>>>
>>> 1.  pthread_create(&wlan_ap_thread_id, NULL, run_wlan_ap, NULL);
>>> 2. Wait interrupt signal from chip
>>> 3. Spawn a new thread using message queue.
>>> 4. Start some kind of SDK magic: transmission via SPI. As I can see from
>>> output before fatal there are over 8 successful transmission, the last what
>>> I see it's a starting reading 8 bytes from device after that fatal occured.
>>>
>>>
>>> >>I think you can trace the PC pointer to see what makes the FATAL.
>>>
>>> using gdb: info symbol 0x20003c80 I'm getting
>>>
>>> _POSIX_Threads_Objects + 2512 in section .bss
>>>
>>> What am I missing?
>>>
>>> Please suggest.
>>>
>>> BRs, Yaroslav.
>>>
>>>
>>>
>>>
>>>
>>> On Mon, 6 May 2019 at 08:06, Sebastian Huber <
>>> sebastian.huber at embedded-brains.de> wrote:
>>>
>>>> Hello,
>>>>
>>>> using rtems_binary_semaphore_post() in interrupt context is fine. Maybe
>>>> this is related to an interrupt with a too high priority, see also:
>>>>
>>>> https://lists.rtems.org/pipermail/users/2019-April/033102.html
>>>>
>>>> --
>>>> Sebastian Huber, embedded brains GmbH
>>>>
>>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>>>> Phone   : +49 89 189 47 41-16
>>>> Fax     : +49 89 189 47 41-09
>>>> E-Mail  : sebastian.huber at embedded-brains.de
>>>> PGP     : Public key available on request.
>>>>
>>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>>
>>>>
>>>
>>> --
>>> --
>>> Kind regards,
>>> *Yaroslav Leshchinsky*
>>>
>>
>>
>> --
>> --
>> Kind regards,
>> *Yaroslav Leshchinsky*
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20190511/81020caf/attachment-0002.html>