1. devel@lists.zephyrproject.org
   Date   
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
Re: nrf52840_pca10059 startup

Henrik Brix Andersen
 

Hi again,

I just tried a few of the examples from the nRF5_SDK_15 (open_bootloader_usb_mbr_pca10059_debug.hex and ble_connectivity_s140_usb_hci_pca10059.hex).
Same issue. I am starting to think my nRF52840 dongle is faulty :-(

Regards,
Brix
--
Henrik Brix Andersen

On 11 Sep 2018, at 20.26, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi Vinayak,

Sorry - just getting back to this problem now.

I have double-checked that SB2 is intact and that VBUS_nRF (measured at SB2) is at ~5.20V.
I have a hard time measuring if VBUS_nRF is connected to VDDH since the pin is located underneath the chip.

Could this be faulty hardware?

Regards,
Brix
--
Henrik Brix Andersen

On 29 Aug 2018, at 05.00, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

This all sounds very close to what is described in :
http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52840.ps%2Fpower.html&cp=2_0_0_4_2_1&anchor=power_usb_supply

"both VBUS and either VDDH or VDD supplies are required"


and "External supply from VDD is only available when power is supplied to VDDH." Mentioned here: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52840.ps/ref_circuitry.html#concept_aqp_fd1_fq


You may check if solder bridge SB2 is intact, and VDDH is connected to VBUS_nRF.

- Vinayak



From: Henrik Brix Andersen <henrik@brixandersen.dk>
Sent: Tuesday, August 28, 2018 10:57 PM
To: Chettimada, Vinayak Kariappa
Cc: Cufi, Carles; Zephyr Devel List; Di Santo, Emanuele
Subject: Re: [Zephyr-devel] nrf52840_pca10059 startup

Hi,

Neither. I am applying the 3V briefly to the SWDCLK input to generate a low-to-high transition on that pin.
I have just retested. Applying 3V briefly to VDD_nRF has the same effect; the board starts up and the application springs to life.

VBUS_nRF is 5.19V when plugged into USB and VDD_nRF is 0.47V (when the application isn’t running for whatever reason).
After applying ~3V briefly to SWDCLK or VDD_nRF, the application springs to life. VBUS_nRF is the same as before (5.19V) but VDD_nRF is now ~3V (as expected from the initialisation code in boards/arm/nrf52840_pca10059/board.c).

After this, the board continues to function as expected (even after resets, reflashing, etc.) until the next cold-boot (removing VBUS and restoring it).

All help is much appreciated.

Regards,
Brix
--
Henrik Brix Andersen

On 28 Aug 2018, at 22.02, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Where are you applying the 3V? to VDD_nRF or VBUS_nRF? VBUS_nRF has a min, typ. and max of 4.35, 5, and 5.5 Volts. Can you measure the VDD_nRF, when you have the dongle plugged to USB port?

I dont have a dongle presently, reviewing the schematics, I see no reason why the chip should not be running the code in it.


From: Henrik Brix Andersen <henrik@brixandersen.dk>
Sent: Tuesday, August 28, 2018 9:08 PM
To: Chettimada, Vinayak Kariappa
Cc: Cufi, Carles; Zephyr Devel List; Di Santo, Emanuele
Subject: Re: [Zephyr-devel] nrf52840_pca10059 startup

Hi all,

I have found that a single low-to-high transition on the SWDCLK pin of the PCA10059 makes the application spring to life.
No debugger attached, no external circuitry at all. Just an external power source of 3V and a switch for applying a low-to-high transition of the SWDCLK line.

Could this have something to do with the internal DC-DC converter of the NRF52840?

Regards,
Brix
--
Henrik Brix Andersen

On 27 Aug 2018, at 22.20, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi,

I am not using the NRF52832 configuration on the NRF52840 SoC; I merely noted that I have successfully used the same programmer (Atmel-ICE) for interacting with NRF52832 SoCs.

Yes, my application is samples/basic/blinky (and all other samples). I have tried the samples/bluetooth/peripheral sample; same issue.
When I initially flash the sample it starts up and everything works as intended. If I then disconnect USB power and reconnect it, nothing starts up (BLE scanner does not show the peripheral anymore).
A simple no-op SWD connection then does the trick; the application springs to life (without flashing a new binary).

I have tried a few of the USB samples as well; none of them shows up as a device on the USB bus.

Do you know if the original firmware binary (the one present on the device when shipping) for the PCA10059 is available anywhere? It could be interesting to see if that behaves correctly.
Are you able to share your locally built zephyr.bin file for the blinky sample with me?

Best regards,
Brix
--
Henrik Brix Andersen

On 27 Aug 2018, at 22.06, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Something you mention about using NRF52832 configuration, why would you want to use that on nRF52840 SoC?

You mention blinky as the example, is that the application you have trouble with? We tried that on our dongle, and see no issues.

I have tried BLE peripheral sample and hci_usb sample on nRF52840 merely powered from nRF USB interface, and see no issues.

Please confirm, that your application is samples/basic/blinky… also please try the samples/bluetooth/peripheral and let me know if you don’t see BLE advertising.

Regards,
Vinayak

On 27 Aug 2018, at 18:42, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi Vinayak,

Thank you for getting back to me. I just tried reverting commit 26d22b0075cf5a71f13958ec1f2727ac7167eca4, but it does not fix the application behaviour.

Any other ideas are most welcome.

Best regards,
Brix

--
Henrik Brix Andersen

On 27 Aug 2018, at 12.52, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi,

I may have introduced a regression (bisected to) in 26d22b0075cf5a71f13958ec1f2727ac7167eca4

I notice that hci_usb sample fails to enumerate the bluetooth class device.

Will get back when I have something. Meanwhile, revert the above mentioned commit and do let me know if your application functions as expected.

Regards,
Vinayak


On 26 Aug 2018, at 19:18, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi,

I am flashing the board using an Atmel-ICE debugger (using pyOCD 0.11.2) connected to a 10-pin debug connector soldered to the P1 footprint on the bottom of the board.

I am using the same configuration for several NRF52832 boards without issues.

Best regards,
Brix

--
Henrik Brix Andersen

On 26 Aug 2018, at 19.01, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi there,

Can you tell us how you're flashing the board? Another Nordic Devkit, or a separate debug IC?

Also copying Emanuele who's doing most of the work on this board.

Regards,

Carles

On 26/08/2018, 18:07, "devel@lists.zephyrproject.org on behalf of Henrik Brix Andersen" <devel@lists.zephyrproject.org on behalf of henrik@brixandersen.dk> wrote:

Hi,

I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.

When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).

If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
I am not using mcuboot or any other bootloader; just the bare-bone sample application.

What am I missing here?

Best regards,
Brix
--
Henrik Brix Andersen
Re: nrf52840_pca10059 startup

Henrik Brix Andersen
 

Hi Vinayak,

Sorry - just getting back to this problem now.

I have double-checked that SB2 is intact and that VBUS_nRF (measured at SB2) is at ~5.20V.
I have a hard time measuring if VBUS_nRF is connected to VDDH since the pin is located underneath the chip.

Could this be faulty hardware?

Regards,
Brix
--
Henrik Brix Andersen

On 29 Aug 2018, at 05.00, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

This all sounds very close to what is described in :
http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52840.ps%2Fpower.html&cp=2_0_0_4_2_1&anchor=power_usb_supply

"both VBUS and either VDDH or VDD supplies are required"


and "External supply from VDD is only available when power is supplied to VDDH." Mentioned here: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52840.ps/ref_circuitry.html#concept_aqp_fd1_fq


You may check if solder bridge SB2 is intact, and VDDH is connected to VBUS_nRF.

- Vinayak



From: Henrik Brix Andersen <henrik@brixandersen.dk>
Sent: Tuesday, August 28, 2018 10:57 PM
To: Chettimada, Vinayak Kariappa
Cc: Cufi, Carles; Zephyr Devel List; Di Santo, Emanuele
Subject: Re: [Zephyr-devel] nrf52840_pca10059 startup

Hi,

Neither. I am applying the 3V briefly to the SWDCLK input to generate a low-to-high transition on that pin.
I have just retested. Applying 3V briefly to VDD_nRF has the same effect; the board starts up and the application springs to life.

VBUS_nRF is 5.19V when plugged into USB and VDD_nRF is 0.47V (when the application isn’t running for whatever reason).
After applying ~3V briefly to SWDCLK or VDD_nRF, the application springs to life. VBUS_nRF is the same as before (5.19V) but VDD_nRF is now ~3V (as expected from the initialisation code in boards/arm/nrf52840_pca10059/board.c).

After this, the board continues to function as expected (even after resets, reflashing, etc.) until the next cold-boot (removing VBUS and restoring it).

All help is much appreciated.

Regards,
Brix
--
Henrik Brix Andersen

On 28 Aug 2018, at 22.02, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Where are you applying the 3V? to VDD_nRF or VBUS_nRF? VBUS_nRF has a min, typ. and max of 4.35, 5, and 5.5 Volts. Can you measure the VDD_nRF, when you have the dongle plugged to USB port?

I dont have a dongle presently, reviewing the schematics, I see no reason why the chip should not be running the code in it.


From: Henrik Brix Andersen <henrik@brixandersen.dk>
Sent: Tuesday, August 28, 2018 9:08 PM
To: Chettimada, Vinayak Kariappa
Cc: Cufi, Carles; Zephyr Devel List; Di Santo, Emanuele
Subject: Re: [Zephyr-devel] nrf52840_pca10059 startup

Hi all,

I have found that a single low-to-high transition on the SWDCLK pin of the PCA10059 makes the application spring to life.
No debugger attached, no external circuitry at all. Just an external power source of 3V and a switch for applying a low-to-high transition of the SWDCLK line.

Could this have something to do with the internal DC-DC converter of the NRF52840?

Regards,
Brix
--
Henrik Brix Andersen

On 27 Aug 2018, at 22.20, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi,

I am not using the NRF52832 configuration on the NRF52840 SoC; I merely noted that I have successfully used the same programmer (Atmel-ICE) for interacting with NRF52832 SoCs.

Yes, my application is samples/basic/blinky (and all other samples). I have tried the samples/bluetooth/peripheral sample; same issue.
When I initially flash the sample it starts up and everything works as intended. If I then disconnect USB power and reconnect it, nothing starts up (BLE scanner does not show the peripheral anymore).
A simple no-op SWD connection then does the trick; the application springs to life (without flashing a new binary).

I have tried a few of the USB samples as well; none of them shows up as a device on the USB bus.

Do you know if the original firmware binary (the one present on the device when shipping) for the PCA10059 is available anywhere? It could be interesting to see if that behaves correctly.
Are you able to share your locally built zephyr.bin file for the blinky sample with me?

Best regards,
Brix
--
Henrik Brix Andersen

On 27 Aug 2018, at 22.06, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Something you mention about using NRF52832 configuration, why would you want to use that on nRF52840 SoC?

You mention blinky as the example, is that the application you have trouble with? We tried that on our dongle, and see no issues.

I have tried BLE peripheral sample and hci_usb sample on nRF52840 merely powered from nRF USB interface, and see no issues.

Please confirm, that your application is samples/basic/blinky… also please try the samples/bluetooth/peripheral and let me know if you don’t see BLE advertising.

Regards,
Vinayak

On 27 Aug 2018, at 18:42, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi Vinayak,

Thank you for getting back to me. I just tried reverting commit 26d22b0075cf5a71f13958ec1f2727ac7167eca4, but it does not fix the application behaviour.

Any other ideas are most welcome.

Best regards,
Brix

--
Henrik Brix Andersen

On 27 Aug 2018, at 12.52, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi,

I may have introduced a regression (bisected to) in 26d22b0075cf5a71f13958ec1f2727ac7167eca4

I notice that hci_usb sample fails to enumerate the bluetooth class device.

Will get back when I have something. Meanwhile, revert the above mentioned commit and do let me know if your application functions as expected.

Regards,
Vinayak


On 26 Aug 2018, at 19:18, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi,

I am flashing the board using an Atmel-ICE debugger (using pyOCD 0.11.2) connected to a 10-pin debug connector soldered to the P1 footprint on the bottom of the board.

I am using the same configuration for several NRF52832 boards without issues.

Best regards,
Brix

--
Henrik Brix Andersen

On 26 Aug 2018, at 19.01, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi there,

Can you tell us how you're flashing the board? Another Nordic Devkit, or a separate debug IC?

Also copying Emanuele who's doing most of the work on this board.

Regards,

Carles

On 26/08/2018, 18:07, "devel@lists.zephyrproject.org on behalf of Henrik Brix Andersen" <devel@lists.zephyrproject.org on behalf of henrik@brixandersen.dk> wrote:

Hi,

I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.

When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).

If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
I am not using mcuboot or any other bootloader; just the bare-bone sample application.

What am I missing here?

Best regards,
Brix
--
Henrik Brix Andersen
Zephyr 1.13.0 Released

Nashif, Anas
 

Hi,

 

We are pleased to announce the release of Zephyr kernel version 1.13.0.

 

Major enhancements with this release include:

 

·       Extensible and Pluggable Tracing Support

·       Compartmentalized application memory organization

·       Logging System Overhaul

·       Introduce system calls for BSD socket APIs

·       Support for IEEE 802.1AS-2011 generalized Precision Time Protocol (gPTP)

·       Link Layer Discovery Protocol (LLDP) TX support

·       Support for TLS and DTLS using BSD socket API

·       Support for Link Layer Multicast Name Resolution (LLMNR)

·       Introduced reworked ADC API and updated Nordic, NXP, Atmel, and

Synopsys DesignWare drivers

·       Support OS driven Power Management framework

·       Basic support for Arm TrustZone in Armv8-M

 

The detailed release notes can be found here:

 

https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v1.13.0

 

I would like to thank all the contributors to this release. In total 140 contributors participated in the development of 1.13.

 

Starting now, the tree is open for new features targeting 1.14 and we already have a few great features lined up and ready to be merged.

 

Thank you again,

 

Anas Nashif

 

 

 
Fw: Re: New submission from Contact Us

Saurabh Pandey <saurabh_0711@...>
 



----- Forwarded message -----

From: Thea Aldrich <aldrich.thea@...>
To: "saurabh_0711@..." <saurabh_0711@...>
Cc: Brett Preston <bpreston@...>; "thea@..." <thea@...>
Sent: Saturday, 8 September, 2018, 8:36:34 PM IST
Subject: Re: New submission from Contact Us

Hi Saurabh,
Thanks for reaching out to the Zephyr Project. For technical questions, please post to users@... or devel@...

Thank you,
Thea Aldrich 

On Sat, Sep 8, 2018, 9:58 AM Zephyr Project - General Contact Form <webmaster@...> wrote:
Name
  saurabh
Email
  saurabh_0711@...
Comment
  CMake Warning at CMakeLists.txt:4 (find_package):
By not providing
finding below issue with boilerplate. Kindly help
"Find/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmake.cmake" in
CMAKE_MODULE_PATH this project has asked CMake to find a package
configuration file provided by
"/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmake", but CMake did
not find one.

Could not find a package configuration file provided by
"/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmake" with any of the
following names:

/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmakeConfig.cmake
/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmake-config.cmake

Add the installation prefix of
"/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmake" to
CMAKE_PREFIX_PATH or set
"/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmake_DIR" to a
directory containing one of the above files. If
"/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmake" provides a
separate development package or SDK, be sure it has been installed.

Re: Enable SPI driver on nrf52840

Jan Van Winkel
 

Chuck,

The only thing I needed to configure is the spi config struct (freq, spi mode of operation & cs) and it just worked out of the box.
But to be honest the only place where I used the NRF SPI is in the ILI9340 display driver[1] and that was a couple of months ago, maybe you can have a look at the SPI code in the display driver.

Regards,
Jan



On Sat, Sep 8, 2018 at 8:05 PM <cpmcparland@...> wrote:
Jan,

Thanks, missed that typo.  Fixed that, but same result.  For the moment,
I'm not worried about the data or behavior of the SPI device.  Just want to
see a driver transaction complete...data comes next.

Not very familiar with the "easy" part of easyDMA.  Do I need to configure
anything outside of the spim driver (besides the CS device and pin I'm handing to the
spi config structure)?

Regards,
Chuck

Re: Enable SPI driver on nrf52840

cpmcparland@...
 

Jan,

Thanks, missed that typo.  Fixed that, but same result.  For the moment,
I'm not worried about the data or behavior of the SPI device.  Just want to
see a driver transaction complete...data comes next.

Not very familiar with the "easy" part of easyDMA.  Do I need to configure
anything outside of the spim driver (besides the CS device and pin I'm handing to the
spi config structure)?

Regards,
Chuck
2581 - 2600 of 7688