Date   

I2C driver for nrf52840 not being compiled

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hello everyone !

I'm trying to interface an I2C device with nrf52840 controller.

When I look into ../zephyr/drivers/i2c directory, there is no Kconfig file corresponding to i2c_nrf5.c 

Again in Kconfig, this driver isn't included, consequently I'm not being able to compile ../zephyr/samples/drivers/i2c_fujitsu_fram  demo for nrf52840.

what needs to be done to fix this issue?  

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


Re: How to detect a thread is aborted and restart it?

Boie, Andrew P
 

Ø  It's just done in a lot of places, including the ztest framework. (tests/ztest/src/ztest.c).

Ø  It should be safe to call k_thread_create() on a thread object to re-use it if that thread has terminated via the k_thread_abort() code path.

 

By the way -- one important point to make.

For threads that are running in privileged mode (all threads unless you have enabled CONFIG_USERSPACE and have created a thread with K_USER), if a thread crashes it's not guaranteed that the damage was limited to that thread only. For example, if the thread crashed while it was making kernel API calls that were in a critical section, global kernel data structures may be in an inconsistent state. Even if the thread was running in User mode when it faults, if it crashes at a bad time there may be application-specific data structures that could be corrupted, although the core kernel should be in a good state. CONFIG_USERSPACE is currently an experimental feature that is under heavy development.

 

Zephyr doesn't have the concept of completely independent *processes* like Linux (this is being worked on to have multiple logical "applications" but won't be ready for a while). So relying on a crashed thread to just be restarted and everything's back to normal may not be completely correct in all cases. You may want to consider hard-resetting the entire system instead.

 

Andrew


Re: How to detect a thread is aborted and restart it?

Boie, Andrew P
 

Ø 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.

 

It's just done in a lot of places, including the ztest framework. (tests/ztest/src/ztest.c).

It should be safe to call k_thread_create() on a thread object to re-use it if that thread has terminated via the k_thread_abort() code path.

 

Andrew


Re: How to detect a thread is aborted and restart it?

Li, Jun R
 

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

 

 

From: "Boie, Andrew P" <andrew.p.boie@...>
Date: Wednesday, December 13, 2017 at 11:01
To: "Li, Jun R" <jun.r.li@...>, Michael Rosen <michael.r.rosen@...>, "Pallala, Ramakrishna" <ramakrishna.pallala@...>, "zephyr-devel@..." <zephyr-devel@...>
Subject: RE: [Zephyr-devel] How to detect a thread is aborted and restart it?

 

Ø  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


Re: multithread problem in zephyr application

Boie, Andrew P
 

Ø 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

 


Re: How to detect a thread is aborted and restart it?

Boie, Andrew P
 

Ø 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


Re: How to detect a thread is aborted and restart it?

Li, Jun R
 

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

 

 

From: <zephyr-devel-bounces@...> on behalf of "Li, Jun R" <jun.r.li@...>
Date: Monday, December 11, 2017 at 15:37
To: "Boie, Andrew P" <andrew.p.boie@...>, Michael Rosen <michael.r.rosen@...>, "Pallala, Ramakrishna" <ramakrishna.pallala@...>, "zephyr-devel@..." <zephyr-devel@...>
Subject: Re: [Zephyr-devel] How to detect a thread is aborted and restart it?

 

Thank you, Andrew and Mike!

 

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

 

Regards,

Jun

 

 

From: "Boie, Andrew P" <andrew.p.boie@...>
Date: Monday, December 11, 2017 at 15:34
To: Michael Rosen <michael.r.rosen@...>, "Li, Jun R" <jun.r.li@...>, "Pallala, Ramakrishna" <ramakrishna.pallala@...>, "zephyr-devel@..." <zephyr-devel@...>
Subject: RE: [Zephyr-devel] How to detect a thread is aborted and restart it?

 

Ø  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


multithread problem in zephyr application

Li, Jun R
 

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

 


Re: Zephyr issue tracking system moved to Github

Paul Sokolovsky
 

Hello,

[]

* There are too many networking labels, one "area: Networking" is
enough.
This RFC from Jukka never got a response, but it seems that everyone
implicitly agreed and followed it, for example:

"area: Networking Clients" has 0 labeled issues
"area: Net Protocols" had 2 issues (closed) over all this time

I seem to be able to edit labels, so unless someone responds to
stop me, I'm going to remove labels above, and leave just "area:
Networking" (183 total issues so far).
Makes sense, +1 from me. Also consistent with Bluetooth, which is a
single label.
Thanks for acking. As a follow-up, I went and deleted the "area: Net
Protocols" label.

However, when checking stats above, I looked at only pull request
numbers, but labels are also used by issues. And
"area: Networking Clients" is currently assigned to 26+30 issues, while
there're 126+319 "area: Networking". In other words, there're quite
many "networking" issues (which after all may mean that we need further
separation) and more than 10% of them are tagged as "area: Networking
Clients".

So, I guess I'll leave deciding on this issue to Jukka when he's back
from vacation.



--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: BLE Nitrogen

Zarkhin, Gene <Gene_Zarkhin@...>
 

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

 

Gene Zarkhin

gene_zarkhin@...

(508) 766-9030 – office

(617) 943-2331 – cell

 

From: Puzdrowski, Andrzej [mailto:Andrzej.Puzdrowski@...]
Sent: Tuesday, December 12, 2017 10:01 AM
To: Zarkhin, Gene <Gene_Zarkhin@...>
Cc: zephyr-devel@...; Zarkhin, Gene <Gene_Zarkhin@...>
Subject: RE: [Zephyr-devel] BLE Nitrogen

 

> 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

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Marti Bolivar
Sent: Tuesday, December 12, 2017 6:42 AM
To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Cc: zephyr-devel@...; Zarkhin, Gene <Gene_Zarkhin@...>
Subject: Re: [Zephyr-devel] BLE Nitrogen

 

Hi,

 

On Mon, Dec 11, 2017 at 12:14 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

 

Nitrogen boards are actively used in the Zephyr community, unless there is some obvious physical issues in your boards (like antennae matching network) Bluetooth functionality should be pretty straight forward. You can even try central_hr one of your board and peripheral_hr on the other and they should connect to each other on power-up. Let me know if your two boards are able to connect so using these Zephyr application.

 

FWIW, my personal experience with 1.0 Nitrogen boards has been... suboptimal. 1.1 is indeed better and usable for things like IPSP at shorter ranges, but still falls short of other boards I've tried. Gene, if you can get them replaced with 1.1s, I'd start there.

 

For comparison, see BLE Nano 2 for another small form-factor Zephyr compatible nRF52 board, which claims BLE 4.2 certification: https://github.com/redbear/nRF5x/blob/master/nRF52832/docs/Specifications.md#ble-module-mb-n2

 

Marti


Re: BLE Nitrogen

Puzdrowski, Andrzej
 

> 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

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Marti Bolivar
Sent: Tuesday, December 12, 2017 6:42 AM
To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Cc: zephyr-devel@...; Zarkhin, Gene <Gene_Zarkhin@...>
Subject: Re: [Zephyr-devel] BLE Nitrogen

 

Hi,

 

On Mon, Dec 11, 2017 at 12:14 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

 

Nitrogen boards are actively used in the Zephyr community, unless there is some obvious physical issues in your boards (like antennae matching network) Bluetooth functionality should be pretty straight forward. You can even try central_hr one of your board and peripheral_hr on the other and they should connect to each other on power-up. Let me know if your two boards are able to connect so using these Zephyr application.

 

FWIW, my personal experience with 1.0 Nitrogen boards has been... suboptimal. 1.1 is indeed better and usable for things like IPSP at shorter ranges, but still falls short of other boards I've tried. Gene, if you can get them replaced with 1.1s, I'd start there.

 

For comparison, see BLE Nano 2 for another small form-factor Zephyr compatible nRF52 board, which claims BLE 4.2 certification: https://github.com/redbear/nRF5x/blob/master/nRF52832/docs/Specifications.md#ble-module-mb-n2

 

Marti


Re: unique ID for flash devices

Puzdrowski, 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

From: Marti Bolivar [mailto:marti@...]
Sent: Friday, December 08, 2017 9:29 PM
To: Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] unique ID for flash devices

 

Hi Andrzej,

 

On Thu, Dec 7, 2017 at 7:50 AM, Puzdrowski, Andrzej <Andrzej.Puzdrowski@...> wrote:

I’m planning to implement abstraction over flash devices driver similar to this what Mynewt has in flash_mam module.

This is using description of different flash areas. Some of this flash areas could be the embedded flash, some else could be an external.

 

https://github.com/apache/mynewt-core/blob/master/sys/flash_map/include/flash_map/flash_map.h

 

I'm a bit confused about what you will implement based on this description. Zephyr already has equivalents to several functions in this API.

 

 

One of features is to provide identification of flash devices for each flash_area. It is important to have “a hard link” in manner which would support

correctlly Identification for a few application existing in one SoC (like case of having common flash memories description for Bootloader and Application)

 

 

In particular I don't understand which feature you're referring to here. What do you mean by "hard link"? I assume you're not referring to a hard link in the sense of a file system.

 

So fare in zphyr API each device is identified by its (configrable) name.

One idea is to introduce fixed Id numbers for each driver and a LUT for making possible to find the link between this ID and the device NAME.

This ID will be used by flash_area descriptions.

 

 

It seems like what you want to add is something like the "fa_device_id" field in struct flash_area. That is, an ID number for the flash device that contains a given area. Can you say a bit more about why you need an ID number, and can't just use a pointer to the struct device corresponding to the flash?

 

Are you trying to support this API for something outside of mcuboot? The mcuboot Zephyr port already has a shim which maps the defines from DT into fields in struct flash_areas in boot/zephyr/flash_map.c.

 

Maybe someone has got better idea or even my idea is totally wrong – please comment then.

 

 

What's this for? Maybe that will help understand.

 

Thanks,

Marti

 

Andrzej Puzdrowski

 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 


Re: what's the status of cmake build system

Sebastian Boe
 

It is possible to subscribe to this issue to stay in-the-loop.

https://github.com/zephyrproject-rtos/zephyr/issues/4687
________________________________________
From: zephyr-devel-bounces@lists.zephyrproject.org <zephyr-devel-bounces@lists.zephyrproject.org> on behalf of jack ma <assangema@gmail.com>
Sent: Tuesday, 12 December 2017 10:43:22 AM
To: Cufi, Carles
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] what's the status of cmake build system

Hi Carles,
Thanks, I am looking forward to it.

2017-12-12 15:55 GMT+08:00 Cufi, Carles <Carles.Cufi@nordicsemi.no<mailto:Carles.Cufi@nordicsemi.no>>:
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

From: zephyr-devel-bounces@lists.zephyrproject.org<mailto:zephyr-devel-bounces@lists.zephyrproject.org> [mailto:zephyr-devel-bounces@lists.zephyrproject.org<mailto:zephyr-devel-bounces@lists.zephyrproject.org>] On Behalf Of jack ma
Sent: 12 December 2017 05:27
To: zephyr-devel@lists.zephyrproject.org<mailto:zephyr-devel@lists.zephyrproject.org>
Subject: [Zephyr-devel] what's the status of cmake build system

Hi,
it looks like Kconfig and Linux environments still need to compile zephyr, is that right?
Is it possible to build zephyr without msys2(or linux subsystem) on Windows now?

Thanks.


Re: what's the status of cmake build system

jack ma
 

Hi Carles,
Thanks, I am looking forward to it.

2017-12-12 15:55 GMT+08:00 Cufi, Carles <Carles.Cufi@...>:

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

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of jack ma
Sent: 12 December 2017 05:27
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] what's the status of cmake build system

 

Hi,

it looks like Kconfig and Linux environments still need to compile zephyr, is that right?

Is it possible to build zephyr without msys2(or linux subsystem) on Windows now?

 

Thanks.



Re: [Zephyr-users] I2C and adc support for nRF5

Steve Brown
 

Hi Ashish,


On Tue, 2017-12-12 at 10:09 +0530, ashish.shukla@corvi.com wrote:
Hi Felipe,

Code builds successfully after making a minor change in main.c file

#define I2C_DEV CONFIG_GPIO_NRF5_P0_DEV_NAME

however, I'm working with nrf52840_pca10056 IC, running the command

$ cmake -DBOARD=nrf52_pca10056 ..

results in an error, I'm attaching snapshot in the attachment.

What needs to be done to remove this error ?




--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development
www.corvi.com
The board name is nrf52840_pca10056

That works on my boards.

Steve


Re: what's the status of cmake build system

Carles Cufi
 

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

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of jack ma
Sent: 12 December 2017 05:27
To: zephyr-devel@...
Subject: [Zephyr-devel] what's the status of cmake build system

 

Hi,

it looks like Kconfig and Linux environments still need to compile zephyr, is that right?

Is it possible to build zephyr without msys2(or linux subsystem) on Windows now?

 

Thanks.


Re: BLE Nitrogen

Marti Bolivar
 

Hi,

On Mon, Dec 11, 2017 at 12:14 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

Nitrogen boards are actively used in the Zephyr community, unless there is some obvious physical issues in your boards (like antennae matching network) Bluetooth functionality should be pretty straight forward. You can even try central_hr one of your board and peripheral_hr on the other and they should connect to each other on power-up. Let me know if your two boards are able to connect so using these Zephyr application.

FWIW, my personal experience with 1.0 Nitrogen boards has been... suboptimal. 1.1 is indeed better and usable for things like IPSP at shorter ranges, but still falls short of other boards I've tried. Gene, if you can get them replaced with 1.1s, I'd start there.

For comparison, see BLE Nano 2 for another small form-factor Zephyr compatible nRF52 board, which claims BLE 4.2 certification: https://github.com/redbear/nRF5x/blob/master/nRF52832/docs/Specifications.md#ble-module-mb-n2

Marti


Re: [Zephyr-users] I2C and adc support for nRF5

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hi Felipe,

Code builds successfully after making a minor change in main.c file

#define I2C_DEV CONFIG_GPIO_NRF5_P0_DEV_NAME

however, I'm working with nrf52840_pca10056 IC, running the command

$ cmake -DBOARD=nrf52_pca10056 ..

results in an error, I'm attaching snapshot in the attachment.

What needs to be done to remove this error ?




--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


On Mon, Dec 11, 2017 at 5:38 PM, Felipe Neves <ryukokki.felipe@...> wrote:
Hello ashish!

The current version of Zephyr support I2C driver for nRF5, you also can find some examples in samples/ directory, the samples/drivers/i2c_fujistsu_fram  is a simple example which use both I2C write and
read functions.

To test it just setup zephyr environment then cd to this sample directory, then:

$ mkdir build
$ cd build
$ cmake -DBOARD=nrf52_pca10040 ..
$ make

You'll find the built image on build/zephyr directory.

Also you can use this sample as reference to develop your own project based on I2C bus.


About the ADC, the nrf5 currently does not support driver to it, but you can of course use it by:

- providing a driver using the zephyr infrastructure;
- use ADC controller as part of your application.

Please let me know if this information was useful to you.

Best

Felipe


2017-12-11 2:43 GMT-02:00 ashish.shukla@... <ashish.shukla@...>:
Hello everyone !!!

There is I2C support for nRF5 micro controllers, is there any sample code available to interface an I2C device with nRF5.

Also, is there adc support for nRF5 series controllers?    

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


_______________________________________________
Zephyr-users mailing list
Zephyr-users@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users




--
Felipe S. Neves 
Embedded software & systems engineer
Skype: fneves1989
+55 11 96610 – 0855 


what's the status of cmake build system

jack ma
 

Hi,
it looks like Kconfig and Linux environments still need to compile zephyr, is that right?
Is it possible to build zephyr without msys2(or linux subsystem) on Windows now?

Thanks.


Re: How to detect a thread is aborted and restart it?

Li, Jun R
 

Thank you, Andrew and Mike!

 

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

 

Regards,

Jun

 

 

From: "Boie, Andrew P" <andrew.p.boie@...>
Date: Monday, December 11, 2017 at 15:34
To: Michael Rosen <michael.r.rosen@...>, "Li, Jun R" <jun.r.li@...>, "Pallala, Ramakrishna" <ramakrishna.pallala@...>, "zephyr-devel@..." <zephyr-devel@...>
Subject: RE: [Zephyr-devel] How to detect a thread is aborted and restart it?

 

Ø  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

4181 - 4200 of 8041