Andrew,

Thank you! I’ll try more times to see if it can restart. Where is the testing application you mentioned for restarting thread? Maybe I didn’t use it in the right way.

Regards,

Jun

Ø  However, it seems not possible to restart the same thread with the same struct thread variable, with the function “k_thread_create”.  When the function is called, the system is stuck. Has anyone tried to restart an aborted thread before?

Hi Li,

Yes this should be possible, we do this all the time (recycle thread objects) in our test cases.

Have you had a chance to debug this further? Where does it get stuck for you?

Andrew

Ø I have no idea why the application crashes at this address, is it like a thread racing condition problem or the thread stack overflow happened?

My money would be on stack overflow. You can try to enable the MPU (if supported) or enable CONFIG_STACK_SENTINEL to try to establish if this is the case. Stack overflows tend to cause all kinds of impossible/baffling behavior.

Ø By the way, how can I check which thread crashes with the thread ID “20000c4c”?

The address should resolve to an instance of struct k_thread in the symbol table.

HTH,

Andrew

Ø However, it seems not possible to restart the same thread with the same struct thread variable, with the function “k_thread_create”.  When the function is called, the system is stuck. Has anyone tried to restart an aborted thread before?

Hi Li,

Yes this should be possible, we do this all the time (recycle thread objects) in our test cases.

Have you had a chance to debug this further? Where does it get stuck for you?

Andrew

Another question still related to thread problem: now I can use fn_abort to detect a thread was forcibly aborted due to something wrong. However, it seems not possible to restart the same thread with the same struct thread variable, with the function “k_thread_create”.  When the function is called, the system is stuck. Has anyone tried to restart an aborted thread before?

Thank you!

Regards,

Jun

Thank you, Andrew and Mike!

I think the function fn_abort is good enough to meet my requests. Thank you very much!

Regards,

Jun

Ø  I don’t see much other way unfortunately; I think it would be nice is Zephyr added Fault hooks per thread so you could set a function to be called on a thread faulting.

There is a fn_abort member in struct k_thread which if not NULL, gets called when a thread goes through the k_thread_abort() code path, including when it hits a fatal exception. It's a void function that takes no parameters.

There appear to be no public APIs to set a thread abort function, but it should be fairly straightforward to add them.

HTH

Andrew

Hi everyone,

I got a strange issue on my multi-threaded application. Sometimes, my application crashes due to the error like below:

  Executing thread ID (thread): 0x20000c4c

  Faulting instruction address:  0x8010c16

  Imprecise data bus error

Fatal fault in ISR! Spinning...

I checked the address 0x8010c16 and found the crashed point is below:

/* must be called with interrupts locked */

static inline void _thread_priority_set(struct k_thread *thread, int prio)

{

    if (_is_thread_ready(thread)) {

        _remove_thread_from_ready_q(thread);

8010c04:   f000 fbe2   bl  80113cc <_remove_thread_from_ready_q>

        thread->base.prio = prio;

8010c08:   72a5        strb    r5, [r4, #10]

        _add_thread_to_ready_q(thread);

8010c0a:   4620        mov r0, r4

            'y' : 'n',

            new_prio, mutex->owner->base.prio);

        _thread_priority_set(mutex->owner, new_prio);

    }

}

8010c0c:   e8bd 4038   ldmia.w sp!, {r3, r4, r5, lr}

8010c10:   f000 bbb4   b.w 801137c <_add_thread_to_ready_q>

    } else {

        thread->base.prio = prio;

8010c14:   72a5        strb    r5, [r4, #10]

8010c16:   bd38        pop {r3, r4, r5, pc}

I have no idea why the application crashes at this address, is it like a thread racing condition problem or the thread stack overflow happened?

By the way, how can I check which thread crashes with the thread ID “20000c4c”?

Thank you!

Regards,

Jun Li

nRF52832 UART is connected to NXP front end chip and works correctly through CDC driver.  I can communicate with nRF52 with no problem.

I changed the board file and set correct LED and UART pins.  There is nothing else there to modify 😊

And yes, from BLE point everything is the same.

As other people mentioned radio is not the best, so next step I may try Nitrogen board rev.1.1

> Well, board configuration is different, different pins are used for LEDs, buttons and UART, but from BLE point of view everything should be the same, correct?

Can you check how you configured UART flow control on both boards you have used? Mabey this cause your troubles?

Andrzej

Hi Marti

Of course the providing of substitute of flash_area primitives is intermedium step for adding other modules. I will adapt mynewt FCB (Flash Circular Buffer) to zephyr, I will take mynewt Config module (or something very similar ) as well. What I also potentially want to do providing something like mynewt’s Manufacturer meta region is – this would be useful for inform both bootloader and application about how memory map looks like. I think that zephyr flash_map will simplify support for multi-memories and multi-images mcuboot support as well or event we can support dynamic image slots allocation basing on that (so will be possible to change flash areas boundaries during FWU – we see the case for that).

What I already do is that I took some part of your job from mcuboot as well. I thing after this It will be possible (even necessary) to use zephyr flash_map instead of mcuboot one.

> “Hard Link” – sory for this ambiguity. I mean that I need to define a proper way to describe Flash entity of certain flash_area and assign proper driver to it. It must be a multi applications solution – so basing a few application programed into one SoC will can discovered unambiguously memory layout of the system. I can imagine it would be for example the bootloader, the main application, the falbac application.

Andrzej

Hi Jack,

You are right, a binary executable of Kconfig is still required, alongside with the Device Tree Compiler, so it is not yet possible to build Zephyr without MSYS2 on Windows yet.

We hope to address this issue in the near future.

Thanks,

Carles

Thank you, Andrew and Mike!

I think the function fn_abort is good enough to meet my requests. Thank you very much!

Regards,

Jun

Ø  I don’t see much other way unfortunately; I think it would be nice is Zephyr added Fault hooks per thread so you could set a function to be called on a thread faulting.

There is a fn_abort member in struct k_thread which if not NULL, gets called when a thread goes through the k_thread_abort() code path, including when it hits a fatal exception. It's a void function that takes no parameters.

There appear to be no public APIs to set a thread abort function, but it should be fairly straightforward to add them.

HTH

Andrew

Ø  I don’t see much other way unfortunately; I think it would be nice is Zephyr added Fault hooks per thread so you could set a function to be called on a thread faulting.

There is a fn_abort member in struct k_thread which if not NULL, gets called when a thread goes through the k_thread_abort() code path, including when it hits a fatal exception. It's a void function that takes no parameters.

There appear to be no public APIs to set a thread abort function, but it should be fairly straightforward to add them.

HTH

Andrew

Jun,

I don’t see much other way unfortunately; I think it would be nice is Zephyr added Fault hooks per thread so you could set a function to be called on a thread faulting.

Otherwise, you can always add kernel/include to the include search path for your project so you don’t have to move anything via:

subdir-cc-flags-y += -I$(ZEPHYR_BASE)/kernel/include

Not ideal, but should give you access to these functions.

Mike

Hi Ram,

Thanks for providing this helpful information! However, the two functions seem not to be published API functions and can’t be included without being moved to somewhere. Also, unfortunately, I can’t find a public function in zephyr/include which can do the same thing as these two internal functions.

Regards,

Jun

Hi Jun Li,

There are few inline functions in kernel/include/ksched.h from which you can get the status of a particular thread.

static inline int _is_thread_prevented_from_running(struct k_thread *thread)

static inline int _is_thread_state_set(struct k_thread *thread, u32_t state)

From the above functions you can get the status of your critical thread and based the status you can invoke/restart the thread from background thread.

Thanks,

Ram