Date   

Re: MISRA-C and Zephyr

Flavio Ceolin
 

Hi Himanshu,

Hello Flavio,

On Fri, Sep 14, 2018 at 11:19:40PM -0700, Flavio ceolin wrote:
Agree, we have to automate it as much as possible. But we can't just wait
have all tools ready to start fixing the issues. Currently there are almost
8k violations on kernel. Any tool we setup will make a lot of noise.

Some rules we will be able to check with coccinelle, but ideally we need a
qualified tool with Misra c support.
Thanks for using Coccinelle for the memset cleanup!

Coccinelle can handle MISRA-C compliance at some extent and it really
depends on the what you wish to accomplish through a coccinelle script.

Some scripts are easy to write, but certainly we can't claim to write
scripts with 0% false positives. It depends upon the problem set and
how well you design a cocci script.
Agree, we'll never put any compliance claim based on Coccinelle, even
because to this *much likely* we have to use a qualified
tool. Nevertheless, there are rules that we can't even check with
Coccinelle. My idea is using Coccinelle as a best effort with other
tools to enforce as much as possible MISRA-C guidelines.

For instance: We planned to remove the unnecessary casts returned by
memory allocating functions *alloc since we know the conversion
from void* and other type is implicit.

https://github.com/torvalds/linux/blob/master/scripts/coccinelle/api/alloc/alloc_cast.cocci

But while working and testing the script, I found some strange code
where the cast was necessary and removing it would be a regression:

drivers/scsi/fnic/fnic_trace.c

<snip>
static unsigned long fnic_trace_buf_p;
...
fnic_trace_buf_p = (unsigned long)vmalloc((trace_max_pages * PAGE_SIZE));
</snip>

And some other case as well, where the cast was required...

Therefore, we removed those cases by embedding a python script into the
coccinelle script(yes, we can embedd python & Ocaml script if required)

What I'm trying to explain is that some cases are easy to handle while some
are disaster to get desired property.

Also, we classify accuracy of the Coccinelle by defining a property
called "Confidence" at the top of the cocci scripts.

Confindence: High --> very rare chances of false postives.
Moderarte --> some chances of false postivies.

We always try to improve the cocci script as much as possible.

If there is any MISRA-C compliant build system then its obviously great.
But if not, then my proposal would be add `coccicheck` to CI and write
cocci scripts to warn.
Yeah, that is really what I had in mind. Currently I'm using coccinelle
where I can but I'm still reviewing the output manually.


For now we have some ideas that we are going to inherit from the
mainline kernel like:

* ARRAY_SIZE: Lots of instances in Zephyr where it is hard-coded rather
than simply using the ARRAY_SIZE helper macro.

* GENMASK: again we could use the helper macro instead of
BIT(3) | BIT(2) | BIT(1) == GENMASK(3,1)

And this GENMASK defintion is defined in:

drivers/dma/dma_stm32f4x.c:#define GENMASK(h, l) (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h))))

So, we could probably, move the declaration to include/misc/util.h
and use it throroughly on the codebase.

...and few more.

Many of the rules we made for mainline is based on enforcing usage of
available standard APIs and thus avoiding developers to roll-out their
own wrappers. In this way we can enforce new incoming code to adhere to
the Zephyr APIs and prevent any subsequent violations/redundancy.
Good !



https://github.com/zephyrproject-rtos/zephyr/pull/9725

Thanks a lot for you work on coccinelle and Zephyr, I certainly will
ping you with more questions :)

Regards,
Flavio Ceolin


Application specific MBEDTLS configuration

Aurelien Jarno
 

Hi all,

I have specific needs for my application and I would therefore like to
provide my own mbedtls config file or extend an existing one. The
existing MBEDTLS_CFG_FILE seems to only be able to use files in the
zephyr source code (as opposed to the app source code). The recently
added generic TLS configuration allow to specific an additional include
file through the TLS_USER_CONFIG_FILE option, but it seems to suffer
from the same issue.

Does anyone have a trick to provide an application specific mbedtls
config file?

Thanks,
Aurelien

--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net


Re: MISRA-C and Zephyr

reto@...
 

On 09/15/2018 06:07 AM, Kumar Gala wrote:
Not support MISRA directly, but I assume we can implement the MISRA checks either by configuring specific rules of cppcheck or implementing our own. If there’s some MISRA checker out there, even better.
Cppcheck has some MISRAC C 2012 checks for a while now [1].

Also, it is quite simple to add such checks to clang-tidy [2]. I am no
longer working in a safety relevant area, so I did not push this pet
project in the past, but extending it for Zephyrs needs would probably
be a good reason to do so.

[1] http://cppcheck.net/misra.php
[2] https://github.com/rettichschnidi/clang-tidy-misra

Kind regards,
Reto


Re: MISRA-C and Zephyr

Himanshu Jha <himanshujha199640@...>
 

Hello Flavio,

On Fri, Sep 14, 2018 at 11:19:40PM -0700, Flavio ceolin wrote:
Agree, we have to automate it as much as possible. But we can't just wait
have all tools ready to start fixing the issues. Currently there are almost
8k violations on kernel. Any tool we setup will make a lot of noise.

Some rules we will be able to check with coccinelle, but ideally we need a
qualified tool with Misra c support.
Thanks for using Coccinelle for the memset cleanup!

Coccinelle can handle MISRA-C compliance at some extent and it really
depends on the what you wish to accomplish through a coccinelle script.

Some scripts are easy to write, but certainly we can't claim to write
scripts with 0% false positives. It depends upon the problem set and
how well you design a cocci script.

For instance: We planned to remove the unnecessary casts returned by
memory allocating functions *alloc since we know the conversion
from void* and other type is implicit.

https://github.com/torvalds/linux/blob/master/scripts/coccinelle/api/alloc/alloc_cast.cocci

But while working and testing the script, I found some strange code
where the cast was necessary and removing it would be a regression:

drivers/scsi/fnic/fnic_trace.c

<snip>
static unsigned long fnic_trace_buf_p;
...
fnic_trace_buf_p = (unsigned long)vmalloc((trace_max_pages * PAGE_SIZE));
</snip>

And some other case as well, where the cast was required...

Therefore, we removed those cases by embedding a python script into the
coccinelle script(yes, we can embedd python & Ocaml script if required)

What I'm trying to explain is that some cases are easy to handle while some
are disaster to get desired property.

Also, we classify accuracy of the Coccinelle by defining a property
called "Confidence" at the top of the cocci scripts.

Confindence: High --> very rare chances of false postives.
Moderarte --> some chances of false postivies.

We always try to improve the cocci script as much as possible.

If there is any MISRA-C compliant build system then its obviously great.
But if not, then my proposal would be add `coccicheck` to CI and write
cocci scripts to warn.

For now we have some ideas that we are going to inherit from the
mainline kernel like:

* ARRAY_SIZE: Lots of instances in Zephyr where it is hard-coded rather
than simply using the ARRAY_SIZE helper macro.

* GENMASK: again we could use the helper macro instead of
BIT(3) | BIT(2) | BIT(1) == GENMASK(3,1)

And this GENMASK defintion is defined in:

drivers/dma/dma_stm32f4x.c:#define GENMASK(h, l) (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h))))

So, we could probably, move the declaration to include/misc/util.h
and use it throroughly on the codebase.

...and few more.

Many of the rules we made for mainline is based on enforcing usage of
available standard APIs and thus avoiding developers to roll-out their
own wrappers. In this way we can enforce new incoming code to adhere to
the Zephyr APIs and prevent any subsequent violations/redundancy.


https://github.com/zephyrproject-rtos/zephyr/pull/9725


Thanks
--
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology


Re: MISRA-C and Zephyr

Flavio ceolin
 

Agree, we have to automate it as much as possible. But we can't just wait have all tools ready to start fixing the issues. Currently there are almost 8k violations on kernel. Any tool we setup will make a lot of noise. 

Some rules we will be able to check with coccinelle, but ideally we need a qualified tool with Misra c support. 

On Fri, Sep 14, 2018, 21:07 Kumar Gala <kumar.gala@...> wrote:
Not support MISRA directly, but I assume we can implement the MISRA checks either by configuring specific rules of cppcheck or implementing our own.  If there’s some MISRA checker out there, even better.

My point is we need something as part of the GitHub PR workflow that does a bunch of the checking otherwise this isn’t really going to work.  Plus it would be nice to have something we can add our own style rules into to help automate code review.

- k

> On Sep 14, 2018, at 10:54 PM, Nashif, Anas <anas.nashif@...> wrote:
>
> AFAIK none of the services you list below support MISRA, some do not even support C.
> We are looking at https://sonarcloud.io which has an integration with GH.
>
> Anas
>
>
>
> -----Original Message-----
> From: devel@... [mailto:devel@...] On Behalf Of Kumar Gala
> Sent: Friday, September 14, 2018 11:47 PM
> To: Ceolin, Flavio <flavio.ceolin@...>
> Cc: zephyr-devel@...; Nashif, Anas <anas.nashif@...>; Hibberd, Amber M <amber.m.hibberd@...>
> Subject: Re: [Zephyr-devel] MISRA-C and Zephyr
>
>
>> On Sep 14, 2018, at 1:46 PM, Flavio Ceolin <flavio.ceolin@...> wrote:
>>
>> Hi guys,
>>
>> Recently I start working on Zephyr to be compliant with MISRA-C. I'd
>> like to give you a brief overview about MISRA-C and why this is
>> valuable to Zephyr.
>>
>> MISRA-C is code guideline that define a subset of C that aims to make
>> embedded software safer, more secure and especially more portable. It
>> does it defining a set of guidelines that try to fill the gaps between
>> C specification and different implementations, it means things with
>> undefined behavior, unspecified behavior and things that the compiler
>> implementation is free to choose the behavior.
>>
>> That's been said, every MISRA-C guideline is classified as rule or
>> directive. These rules and directives are classified in mandatory,
>> required or advisory. Mandatory means that the code must be compliant
>> with the guideline, required the code also must be compliant but it's
>> possible creating a deviation, advisory are recommendations and don't
>> need a formal deviation if ignored.
>>
>> So, what about Zephyr ? Zephyr currently contains ~8k violations and
>> approximately half are either required or mandatory (~10). I'm filling
>> issues on github
>> (https://github.com/zephyrproject-rtos/zephyr/labels/MISRA-C) that
>> contains (I hope) enough information about the problem and some
>> suggestions to approach them. I ask everybody to take a look on them
>> and give opinions. Some of them required collaboration of diverse
>> code-owners and developers.
>>
>> To finish, why MISRA-C is valuable to Zephyr ?
>>
>> - Following a standard helps with maintainability of the code.
>> - Process standards like ISO26262 and IEC61508 used to develop
>> critical  products require that the code follows a code guideline
>> (ISO26262  explicitly recommends MISRA-C).
>> - Other proprietary RTOs are MISRA-C compliant, if we want to be more
>> with them, is good too.
>> - It'll help us spot problems bugs and avoid them. I've worked this
>> week  in two guidelines that are not that intrusive and I found at
>> least  three real bugs.
>> - We'll have less problems with different compilers, the mandatory
>> violations are regarding using specific gcc builtin functions.
>>
>> If you have any questions regarding MISRA-C lets discuss it :)
>>
>> Regards,
>> Flavio Ceolin
>
> Have you looked at various GitHub integration tools that might help check code for MISRA guidelines so we can automate such reviews in the future.
>
> Tools like:
>
> https://lgtm.com
> https://www.codacy.com
> https://www.codefactor.io/
>
> I think we need some automated way to check new PRs for issues before we invest a large amount of time fixing the code base, otherwise its just going to bitrot back to being non-MISRA compliant.
>
> - k
>
>





Re: MISRA-C and Zephyr

Kumar Gala
 

Not support MISRA directly, but I assume we can implement the MISRA checks either by configuring specific rules of cppcheck or implementing our own. If there’s some MISRA checker out there, even better.

My point is we need something as part of the GitHub PR workflow that does a bunch of the checking otherwise this isn’t really going to work. Plus it would be nice to have something we can add our own style rules into to help automate code review.

- k

On Sep 14, 2018, at 10:54 PM, Nashif, Anas <anas.nashif@intel.com> wrote:

AFAIK none of the services you list below support MISRA, some do not even support C.
We are looking at https://sonarcloud.io which has an integration with GH.

Anas



-----Original Message-----
From: devel@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org] On Behalf Of Kumar Gala
Sent: Friday, September 14, 2018 11:47 PM
To: Ceolin, Flavio <flavio.ceolin@intel.com>
Cc: zephyr-devel@lists.zephyrproject.org; Nashif, Anas <anas.nashif@intel.com>; Hibberd, Amber M <amber.m.hibberd@intel.com>
Subject: Re: [Zephyr-devel] MISRA-C and Zephyr


On Sep 14, 2018, at 1:46 PM, Flavio Ceolin <flavio.ceolin@intel.com> wrote:

Hi guys,

Recently I start working on Zephyr to be compliant with MISRA-C. I'd
like to give you a brief overview about MISRA-C and why this is
valuable to Zephyr.

MISRA-C is code guideline that define a subset of C that aims to make
embedded software safer, more secure and especially more portable. It
does it defining a set of guidelines that try to fill the gaps between
C specification and different implementations, it means things with
undefined behavior, unspecified behavior and things that the compiler
implementation is free to choose the behavior.

That's been said, every MISRA-C guideline is classified as rule or
directive. These rules and directives are classified in mandatory,
required or advisory. Mandatory means that the code must be compliant
with the guideline, required the code also must be compliant but it's
possible creating a deviation, advisory are recommendations and don't
need a formal deviation if ignored.

So, what about Zephyr ? Zephyr currently contains ~8k violations and
approximately half are either required or mandatory (~10). I'm filling
issues on github
(https://github.com/zephyrproject-rtos/zephyr/labels/MISRA-C) that
contains (I hope) enough information about the problem and some
suggestions to approach them. I ask everybody to take a look on them
and give opinions. Some of them required collaboration of diverse
code-owners and developers.

To finish, why MISRA-C is valuable to Zephyr ?

- Following a standard helps with maintainability of the code.
- Process standards like ISO26262 and IEC61508 used to develop
critical products require that the code follows a code guideline
(ISO26262 explicitly recommends MISRA-C).
- Other proprietary RTOs are MISRA-C compliant, if we want to be more
with them, is good too.
- It'll help us spot problems bugs and avoid them. I've worked this
week in two guidelines that are not that intrusive and I found at
least three real bugs.
- We'll have less problems with different compilers, the mandatory
violations are regarding using specific gcc builtin functions.

If you have any questions regarding MISRA-C lets discuss it :)

Regards,
Flavio Ceolin
Have you looked at various GitHub integration tools that might help check code for MISRA guidelines so we can automate such reviews in the future.

Tools like:

https://lgtm.com
https://www.codacy.com
https://www.codefactor.io/

I think we need some automated way to check new PRs for issues before we invest a large amount of time fixing the code base, otherwise its just going to bitrot back to being non-MISRA compliant.

- k


Re: MISRA-C and Zephyr

Nashif, Anas
 

AFAIK none of the services you list below support MISRA, some do not even support C.
We are looking at https://sonarcloud.io which has an integration with GH.

Anas

-----Original Message-----
From: devel@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org] On Behalf Of Kumar Gala
Sent: Friday, September 14, 2018 11:47 PM
To: Ceolin, Flavio <flavio.ceolin@intel.com>
Cc: zephyr-devel@lists.zephyrproject.org; Nashif, Anas <anas.nashif@intel.com>; Hibberd, Amber M <amber.m.hibberd@intel.com>
Subject: Re: [Zephyr-devel] MISRA-C and Zephyr


On Sep 14, 2018, at 1:46 PM, Flavio Ceolin <flavio.ceolin@intel.com> wrote:

Hi guys,

Recently I start working on Zephyr to be compliant with MISRA-C. I'd
like to give you a brief overview about MISRA-C and why this is
valuable to Zephyr.

MISRA-C is code guideline that define a subset of C that aims to make
embedded software safer, more secure and especially more portable. It
does it defining a set of guidelines that try to fill the gaps between
C specification and different implementations, it means things with
undefined behavior, unspecified behavior and things that the compiler
implementation is free to choose the behavior.

That's been said, every MISRA-C guideline is classified as rule or
directive. These rules and directives are classified in mandatory,
required or advisory. Mandatory means that the code must be compliant
with the guideline, required the code also must be compliant but it's
possible creating a deviation, advisory are recommendations and don't
need a formal deviation if ignored.

So, what about Zephyr ? Zephyr currently contains ~8k violations and
approximately half are either required or mandatory (~10). I'm filling
issues on github
(https://github.com/zephyrproject-rtos/zephyr/labels/MISRA-C) that
contains (I hope) enough information about the problem and some
suggestions to approach them. I ask everybody to take a look on them
and give opinions. Some of them required collaboration of diverse
code-owners and developers.

To finish, why MISRA-C is valuable to Zephyr ?

- Following a standard helps with maintainability of the code.
- Process standards like ISO26262 and IEC61508 used to develop
critical products require that the code follows a code guideline
(ISO26262 explicitly recommends MISRA-C).
- Other proprietary RTOs are MISRA-C compliant, if we want to be more
with them, is good too.
- It'll help us spot problems bugs and avoid them. I've worked this
week in two guidelines that are not that intrusive and I found at
least three real bugs.
- We'll have less problems with different compilers, the mandatory
violations are regarding using specific gcc builtin functions.

If you have any questions regarding MISRA-C lets discuss it :)

Regards,
Flavio Ceolin
Have you looked at various GitHub integration tools that might help check code for MISRA guidelines so we can automate such reviews in the future.

Tools like:

https://lgtm.com
https://www.codacy.com
https://www.codefactor.io/

I think we need some automated way to check new PRs for issues before we invest a large amount of time fixing the code base, otherwise its just going to bitrot back to being non-MISRA compliant.

- k


Re: MISRA-C and Zephyr

Kumar Gala
 

On Sep 14, 2018, at 1:46 PM, Flavio Ceolin <flavio.ceolin@intel.com> wrote:

Hi guys,

Recently I start working on Zephyr to be compliant with MISRA-C. I'd
like to give you a brief overview about MISRA-C and why this is valuable
to Zephyr.

MISRA-C is code guideline that define a subset of C that aims to make
embedded software safer, more secure and especially more portable. It
does it defining a set of guidelines that try to fill the gaps between C
specification and different implementations, it means things with
undefined behavior, unspecified behavior and things that the
compiler implementation is free to choose the behavior.

That's been said, every MISRA-C guideline is classified as rule or
directive. These rules and directives are classified in mandatory,
required or advisory. Mandatory means that the code must be compliant
with the guideline, required the code also must be compliant but it's
possible creating a deviation, advisory are recommendations and don't
need a formal deviation if ignored.

So, what about Zephyr ? Zephyr currently contains ~8k violations and
approximately half are either required or mandatory (~10). I'm filling
issues on github
(https://github.com/zephyrproject-rtos/zephyr/labels/MISRA-C) that
contains (I hope) enough information about the problem and some
suggestions to approach them. I ask everybody to take a look on them and
give opinions. Some of them required collaboration of diverse code-owners
and developers.

To finish, why MISRA-C is valuable to Zephyr ?

- Following a standard helps with maintainability of the code.
- Process standards like ISO26262 and IEC61508 used to develop critical
products require that the code follows a code guideline (ISO26262
explicitly recommends MISRA-C).
- Other proprietary RTOs are MISRA-C compliant, if we want to be more
with them, is good too.
- It'll help us spot problems bugs and avoid them. I've worked this week
in two guidelines that are not that intrusive and I found at least
three real bugs.
- We'll have less problems with different compilers, the mandatory
violations are regarding using specific gcc builtin functions.

If you have any questions regarding MISRA-C lets discuss it :)

Regards,
Flavio Ceolin
Have you looked at various GitHub integration tools that might help check code for MISRA guidelines so we can automate such reviews in the future.

Tools like:

https://lgtm.com
https://www.codacy.com
https://www.codefactor.io/

I think we need some automated way to check new PRs for issues before we invest a large amount of time fixing the code base, otherwise its just going to bitrot back to being non-MISRA compliant.

- k


Re: MISRA-C and Zephyr

Abderrezak Mekkaoui <ab.mekka@...>
 

Hi All,

Making Zephyr MISRA-C compliant would be a huge achievement and a major selling point.
It would also greatly help  contributors (who are not yet award of MISRA-C or equivalent standards) to highly increase the quality of their code.
Regards

Abderrezak

On 9/14/2018 2:46 PM, Flavio Ceolin wrote:
Hi guys,

Recently I start working on Zephyr to be compliant with MISRA-C. I'd
like to give you a brief overview about MISRA-C and why this is valuable
to Zephyr.

MISRA-C is code guideline that define a subset of C that aims to make
embedded software safer, more secure and especially more portable. It
does it defining a set of guidelines that try to fill the gaps between C
specification and different implementations, it means things with
undefined behavior, unspecified behavior and things that the
compiler implementation is free to choose the behavior.

That's been said, every MISRA-C guideline is classified as rule or
directive. These rules and directives are classified in mandatory,
required or advisory. Mandatory means that the code must be compliant
with the guideline, required the code also must be compliant but it's
possible creating a deviation, advisory are recommendations and don't
need a formal deviation if ignored.

So, what about Zephyr ? Zephyr currently contains ~8k violations and
approximately half are either required or mandatory (~10). I'm filling
issues on github
(https://github.com/zephyrproject-rtos/zephyr/labels/MISRA-C) that
contains (I hope) enough information about the problem and some
suggestions to approach them. I ask everybody to take a look on them and
give opinions. Some of them required collaboration of diverse code-owners
and developers.

To finish, why MISRA-C is valuable to Zephyr ?

- Following a standard helps with maintainability of the code.
- Process standards like ISO26262 and IEC61508 used to develop critical
products require that the code follows a code guideline (ISO26262
explicitly recommends MISRA-C).
- Other proprietary RTOs are MISRA-C compliant, if we want to be more
with them, is good too.
- It'll help us spot problems bugs and avoid them. I've worked this week
in two guidelines that are not that intrusive and I found at least
three real bugs.
- We'll have less problems with different compilers, the mandatory
violations are regarding using specific gcc builtin functions.

If you have any questions regarding MISRA-C lets discuss it :)

Regards,
Flavio Ceolin


MISRA-C and Zephyr

Flavio Ceolin
 

Hi guys,

Recently I start working on Zephyr to be compliant with MISRA-C. I'd
like to give you a brief overview about MISRA-C and why this is valuable
to Zephyr.

MISRA-C is code guideline that define a subset of C that aims to make
embedded software safer, more secure and especially more portable. It
does it defining a set of guidelines that try to fill the gaps between C
specification and different implementations, it means things with
undefined behavior, unspecified behavior and things that the
compiler implementation is free to choose the behavior.

That's been said, every MISRA-C guideline is classified as rule or
directive. These rules and directives are classified in mandatory,
required or advisory. Mandatory means that the code must be compliant
with the guideline, required the code also must be compliant but it's
possible creating a deviation, advisory are recommendations and don't
need a formal deviation if ignored.

So, what about Zephyr ? Zephyr currently contains ~8k violations and
approximately half are either required or mandatory (~10). I'm filling
issues on github
(https://github.com/zephyrproject-rtos/zephyr/labels/MISRA-C) that
contains (I hope) enough information about the problem and some
suggestions to approach them. I ask everybody to take a look on them and
give opinions. Some of them required collaboration of diverse code-owners
and developers.

To finish, why MISRA-C is valuable to Zephyr ?

- Following a standard helps with maintainability of the code.
- Process standards like ISO26262 and IEC61508 used to develop critical
products require that the code follows a code guideline (ISO26262
explicitly recommends MISRA-C).
- Other proprietary RTOs are MISRA-C compliant, if we want to be more
with them, is good too.
- It'll help us spot problems bugs and avoid them. I've worked this week
in two guidelines that are not that intrusive and I found at least
three real bugs.
- We'll have less problems with different compilers, the mandatory
violations are regarding using specific gcc builtin functions.

If you have any questions regarding MISRA-C lets discuss it :)

Regards,
Flavio Ceolin


Re: [Zephyr-users] nrf52810 basic blinky example not running

Carles Cufi
 

Hi Marcio,

 

Yes, there are several people developing on nRF52810 successfully with Zephyr on custom boards.

I wonder if you could dig a little bit more into it and try to debug it so we have a better idea of what’s going on?

 

Carles

 

From: users@... <users@...> On Behalf Of Marcio Montenegro
Sent: 14 September 2018 14:52
To: zephyr-devel@...; zephyr-users@...
Subject: [Zephyr-users] nrf52810 basic blinky example not running

 

Hi all,

Is anybody developing for nrf52810 ?

There is no Nordic kit for nrf52810 so I am using a custom board.

The BLE module is CDEBYTE E73-2G4M04S1A:

 

Basic I/O of my hardware was tested on a  Keil compiler project and I will test BLE radio later.

zephyr.hex file was flashed using JLinkExe.

 

All suggestions are welcome,

 

 


[Sensor] [API] Reading multiple values from sensors

paul.adam@...
 

Hello,

As I found in documentation and source code, there is an interface to read one (!) value from sensors (sensor_sample_fetch_chan + sensor_channel_get). So my question is

Does zephyr support reading of multiple values at one time?

The use case would be:
  • Configure sensor ( sensor_attr_set) to read with 1 kHz during several seconds/minutes (limited by sensor spec).
  • Start sensor (is there an API "start/stop acquisition"?)
  • Trigger "Data Ready"
  • Read values at once ( e.g function "read" with arguments "struct sensor_value ValueArray[ 10000 ];" and "int Size = sizeof( ValueArray );" )
Best regards
Paul


nrf52810 basic blinky example not running

Marcio Montenegro
 

Hi all,
Is anybody developing for nrf52810 ?
There is no Nordic kit for nrf52810 so I am using a custom board.
The BLE module is CDEBYTE E73-2G4M04S1A:

Basic I/O of my hardware was tested on a  Keil compiler project and I will test BLE radio later.
zephyr.hex file was flashed using JLinkExe.

All suggestions are welcome,



Re: MPU fault while testing Bluetooth Mesh Sample demos

vikrant8051 <vikrant8051@...>
 

Hi Carles,
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

>> Did you run addr2line in 0x20001c5c?


***** MPU FAULT *****                                                                                                            
  Instruction Access Violation                                                                                                   
***** Hardware exception *****                                                                                                   
Current thread ID = 0x20001884                                                                                                   
Faulting instruction address = 0x20001c88                                                                                        
Fatal fault in ISR! Spinning...


1)

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-addr2line -e  /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf 0x20001c88


&


/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-addr2line -e  /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf 0x20001884


Both returns -> :? ...... with zephyr-SDK


2)

I also tried to compile the App using latest gcc-arm-none-eabi-7-2018-q2


2.1)

/opt/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-addr2line -e /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf 0x20001c88


o/p -> isr_tables.c:?


2.2)

/opt/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-addr2line -e /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf 0x20001884


o/p -> /home/vikrant/zephyr/kernel/init.c:80

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

>> Have you tried increasing stack sizes?


Yes.

CONFIG_MAIN_STACK_SIZE=512 ....to 1024
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048 ....to 4096


But still getting MPU Fault in case of Board executing BT Mesh Servers.


On Fri, Sep 14, 2018 at 3:31 PM Cufi, Carles <Carles.Cufi@...> wrote:

Hi there,

 

Did you run addr2line in 0x20001c5c?

Have you tried increasing stack sizes?

 

Carles

 

From: devel@... <devel@...> On Behalf Of vikrant8051
Sent: 14 September 2018 11:48
To: devel@...; users@...
Subject: Re: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos

 

Hi,

 

FYI,

With v1.12.99 I'm mot facing any MPU FAULT issue (while testing for #onoff_level_lighting_vnd_app)

It has last commit -> ba6763a187a347cfc825a2bece78e7d1ef28772d

 

That means something after it has changed the things bcz of that we are getting

MPU FAULT.

 

Thank You !!

 

On Wed, Sep 5, 2018 at 10:50 AM vikrant8051 <vikrant8051@...> wrote:

Hi,

I'm getting following MPU fault while testing with samples for Bluetooth Mesh . This issue has started after syncing with master branch.

 

***** MPU FAULT *****                                                                                                            
  Instruction Access Violation                                                                                                   
***** Hardware exception *****                                                                                                   
Current thread ID = 0x2000188c                                                                                                   
Faulting instruction address = 0x20001c5c                                                                                        
Fatal fault in ISR! Spinning...

 

 

Thank You !!

 

 


Re: MPU fault while testing Bluetooth Mesh Sample demos

Carles Cufi
 

Hi there,

 

Did you run addr2line in 0x20001c5c?

Have you tried increasing stack sizes?

 

Carles

 

From: devel@... <devel@...> On Behalf Of vikrant8051
Sent: 14 September 2018 11:48
To: devel@...; users@...
Subject: Re: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos

 

Hi,

 

FYI,

With v1.12.99 I'm mot facing any MPU FAULT issue (while testing for #onoff_level_lighting_vnd_app)

It has last commit -> ba6763a187a347cfc825a2bece78e7d1ef28772d

 

That means something after it has changed the things bcz of that we are getting

MPU FAULT.

 

Thank You !!

 

On Wed, Sep 5, 2018 at 10:50 AM vikrant8051 <vikrant8051@...> wrote:

Hi,

I'm getting following MPU fault while testing with samples for Bluetooth Mesh . This issue has started after syncing with master branch.

 

***** MPU FAULT *****                                                                                                            
  Instruction Access Violation                                                                                                   
***** Hardware exception *****                                                                                                   
Current thread ID = 0x2000188c                                                                                                   
Faulting instruction address = 0x20001c5c                                                                                        
Fatal fault in ISR! Spinning...

 

 

Thank You !!

 

 


Re: MPU fault while testing Bluetooth Mesh Sample demos

vikrant8051 <vikrant8051@...>
 

Hi,

FYI,
With v1.12.99 I'm mot facing any MPU FAULT issue (while testing for #onoff_level_lighting_vnd_app)
It has last commit -> ba6763a187a347cfc825a2bece78e7d1ef28772d

That means something after it has changed the things bcz of that we are getting
MPU FAULT.

Thank You !!

On Wed, Sep 5, 2018 at 10:50 AM vikrant8051 <vikrant8051@...> wrote:
Hi,
I'm getting following MPU fault while testing with samples for Bluetooth Mesh . This issue has started after syncing with master branch.

***** MPU FAULT *****                                                                                                            
  Instruction Access Violation                                                                                                   
***** Hardware exception *****                                                                                                   
Current thread ID = 0x2000188c                                                                                                   
Faulting instruction address = 0x20001c5c                                                                                        
Fatal fault in ISR! Spinning...


Thank You !!



Moving SOC definitions to ZEPHYR_BASE/soc

Nashif, Anas
 

Hi,

 

We have just merged PR https://github.com/zephyrproject-rtos/zephyr/pull/9776 which moves SOC definitions out of the arch/ directory to the top level to be side by side with boards, architectures.

 

This was done with the intention to support custom boards and SOC definitions outside of the Zephyr tree.

 

If you have any PRs changing SOC code under arch, you might want to rebase.

 

Thanks,

 

Anas

 


How to add GPS / location in Zephyr?

jantore.guggedal@...
 

Hi,
 
I'm working on a project in Zephyr that will use GPS to get the location of a device. 
Until now the GPS data has been fethed using serial drivers directly, but we're looking into the possibility of using the sensor API to interface with the GPS and make it appear like a "normal" sensor in Zephyr. 
And this is where we run into some issues:
 
The sensor_value data type in the sensor API is for numbers with an integer and a fractional part. A typical GPS sensor provides NMEA strings of various types, and for us it would be useful for the application to receive these strings unparsed.
In many cases it would be fine to get parsed longitude, latitude, altitude and other values using respective channels in the sensor API, but the option to receive the raw data string would still be preferable in our case as we intend to forward it unparsed.
A fair number of channels (~20) would have to be added to the API to be able to get the most detailed data from the GPS sensor that is available in the NMEA strings, but that's perhaps not a problem? 
For the most essential GPS information (latitude, longitude, altitude, speed, heading, time), fewer channels are needed.
We could parse the strings in GPS driver, send the strings over a sensor channel, and then in the application put the data back into a string equal to the original one, but it would be good to not need to do this unncessary processing.
 
  • If using the sensor API, can we get strings from a sensor channel by somehow expanding the current sensor_value data type without breaking existing code? Just adding extra fields to the struct is maybe not a preferable solution?
  • Do you think that GPS fits within the sensor API, or should we look in another direction?
 
We appreciate all feedback on how to approach the task of integrating GPS/location into Zephyr. 
 
Best regards
Jan Tore Guggedal
 


Re: I2C cmake errors (v1.13 and v1.12) ? #nrf52832

gurpreet+zephy@...
 

Never mind.. found this fantastic youtube video in the `Enable SPI driver` thread that helped solve the issue: https://youtu.be/vioi4OsmB_U

-Gurpreet 


I2C cmake errors (v1.13 and v1.12) ? #nrf52832

gurpreet+zephy@...
 

Hi All,

I'm trying to build the I2C sample programs or those that use I2C for the nrf52, but keep seeing the following error.
Is there something I need to do to enable using I2C from the chip? I presume I'm missing something straightforward here. 
I tried both the current_sensing and the i2c_fujitsu_fram sample programs. 

~/src/zephyr/samples/drivers/current_sensing/build 15:36:16>cmake -DBOARD=nrf52_pca10040 ..
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.5", minimum required is "3.4") 
-- Selected BOARD nrf52_pca10040
Zephyr version: 1.13.0
Parsing Kconfig tree in /home/gps/src/zephyr/Kconfig
Loading /home/gps/src/zephyr/boards/arm/nrf52_pca10040/nrf52_pca10040_defconfig as base
Merging /home/gps/src/zephyr/samples/drivers/current_sensing/prj.conf
warning: tag 'zephyr-v1.13.0' is really 'v1.13.0' here
-- Generating zephyr/include/generated/generated_dts_board.h
-- Cache files will be written to: /home/gps/.cache/zephyr
-- The C compiler identification is GNU 6.2.0
-- The CXX compiler identification is GNU 6.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/gps/src/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
CMake Error at ../../../CMakeLists.txt:527 (message):
  The Zephyr library 'drivers__i2c' was created without source files.  Empty
  (non-imported) libraries are not supported.  Either make sure that the
  library has the sources it should have, or make sure it is not created when
  it has no source files.

Any help would be appreciated. 

Thanks!
Gurpreet

3081 - 3100 of 8194