On Tue, May 7, 2019, 11:11 AM Ярослав Лещинский <midniwal...@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, Ярослав Лещинский <midniwal...@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.hu...@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.hu...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/users
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
