Date   

Re: STM32f0 Stop Mode

Erwan Gouriou
 

Hi Rob,

On Fri, 12 Oct 2018 at 22:43, Rob Weber <rob@...> wrote:
On Fri, Oct 12, 2018 at 12:50:51PM -0700, Rob Weber wrote:
> On Thu, Oct 11, 2018 at 10:10:30AM +0200, Erwan Gouriou wrote:
> > Hi Rob,
> >
> > When exiting stop mode PLL is disabled so you're running on HSI(or similar).
> > This explain the change of clock speed after stop mode is exited.
> > So you need to reconfigure and enable the PLL before doing anything else.
>
> Thanks for the tip! I'm having a bit of trouble figuring out how to tap
> into Zephyr's exiting API for reconfiguring the clocks. Our clocks are
> configured in the board-specific defconfig as follows
> (this is from nucleo_f091rc_defconfig):
>
>       # Clock configuration
>       CONFIG_CLOCK_CONTROL=y
>       # SYSCLK selection
>       CONFIG_CLOCK_STM32_SYSCLK_SRC_PLL=y
>       # HSE configuration
>       CONFIG_CLOCK_STM32_HSE_CLOCK=8000000
>       # however, the board does not have an external oscillator, so just use
>       # the 8MHz clock signal coming from integrated STLink
>       CONFIG_CLOCK_STM32_HSE_BYPASS=y
>       # PLL configuration
>       CONFIG_CLOCK_STM32_PLL_SRC_HSE=y
>       # produce 48MHz clock at PLL output
>       CONFIG_CLOCK_STM32_PLL_PREDIV1=1
>       CONFIG_CLOCK_STM32_PLL_MULTIPLIER=6
>       CONFIG_CLOCK_STM32_AHB_PRESCALER=1
>       CONFIG_CLOCK_STM32_APB1_PRESCALER=1
>
> I would ideally like to make use of these variables or the Zephyr
> functions that use these variables when initializing the chip. Which
> functions should I be looking out for in order to make use of these
> variables?

I've been doing a little digging into the Zephyr source code and I
believe I found an example of what I'm looking for. In
drivers/clock_control/stm32_ll_clock.c:


        static int stm32_clock_control_init(struct device *dev)

This function seems to implement PLL and SYSCLK configuration,  but is a
private function meant to be used for driver initialization. Is there
another way I can hook into this behavior? One thought that came to mind
was to get the device binding for the stm32 clock control:

        struct device *clk = device_get_binding(STM32_CLOCK_CONTROL_NAME);

Once I have access to the clock control dev, would I be able to enable
the PLL through the clock control API (I guess the only function that
would makes sense is clock_control_on)?


clock_control_on won't help you for now as it is designed to enabled clock for subsystem (peripheral bus), and not to handle power management operations.
The piece of code you need to (re)start the PLL is within stm32_clock_control_init(). Ideally this code should be extracted from here and factorize so if could be called from another function that could be called at run time when you exit STOP mode.

Zephyr recently introduced a generic arch infrastructure for power state support. Unfortunately it is not yet available on stm32 devices, but using this subsystem would be the ideal and appropriate way to handle the power management states transitions you're currently dealing with.
You could fin more information at the following page :

Cheers
Erwan

Thanks for your help, any guidance is really appreciated!

Cheers,
Rob Weber


Re: STM32f0 Stop Mode

Rob Weber
 

On Fri, Oct 12, 2018 at 12:50:51PM -0700, Rob Weber wrote:
On Thu, Oct 11, 2018 at 10:10:30AM +0200, Erwan Gouriou wrote:
Hi Rob,

When exiting stop mode PLL is disabled so you're running on HSI(or similar).
This explain the change of clock speed after stop mode is exited.
So you need to reconfigure and enable the PLL before doing anything else.
Thanks for the tip! I'm having a bit of trouble figuring out how to tap
into Zephyr's exiting API for reconfiguring the clocks. Our clocks are
configured in the board-specific defconfig as follows
(this is from nucleo_f091rc_defconfig):

# Clock configuration
CONFIG_CLOCK_CONTROL=y
# SYSCLK selection
CONFIG_CLOCK_STM32_SYSCLK_SRC_PLL=y
# HSE configuration
CONFIG_CLOCK_STM32_HSE_CLOCK=8000000
# however, the board does not have an external oscillator, so just use
# the 8MHz clock signal coming from integrated STLink
CONFIG_CLOCK_STM32_HSE_BYPASS=y
# PLL configuration
CONFIG_CLOCK_STM32_PLL_SRC_HSE=y
# produce 48MHz clock at PLL output
CONFIG_CLOCK_STM32_PLL_PREDIV1=1
CONFIG_CLOCK_STM32_PLL_MULTIPLIER=6
CONFIG_CLOCK_STM32_AHB_PRESCALER=1
CONFIG_CLOCK_STM32_APB1_PRESCALER=1

I would ideally like to make use of these variables or the Zephyr
functions that use these variables when initializing the chip. Which
functions should I be looking out for in order to make use of these
variables?
I've been doing a little digging into the Zephyr source code and I
believe I found an example of what I'm looking for. In
drivers/clock_control/stm32_ll_clock.c:


static int stm32_clock_control_init(struct device *dev)

This function seems to implement PLL and SYSCLK configuration, but is a
private function meant to be used for driver initialization. Is there
another way I can hook into this behavior? One thought that came to mind
was to get the device binding for the stm32 clock control:

struct device *clk = device_get_binding(STM32_CLOCK_CONTROL_NAME);

Once I have access to the clock control dev, would I be able to enable
the PLL through the clock control API (I guess the only function that
would makes sense is clock_control_on)?

Thanks for your help, any guidance is really appreciated!

Cheers,
Rob Weber


Re: STM32f0 Stop Mode

Rob Weber
 

On Thu, Oct 11, 2018 at 10:10:30AM +0200, Erwan Gouriou wrote:
Hi Rob,

When exiting stop mode PLL is disabled so you're running on HSI(or similar).
This explain the change of clock speed after stop mode is exited.
So you need to reconfigure and enable the PLL before doing anything else.
Thanks for the tip! I'm having a bit of trouble figuring out how to tap
into Zephyr's exiting API for reconfiguring the clocks. Our clocks are
configured in the board-specific defconfig as follows
(this is from nucleo_f091rc_defconfig):

# Clock configuration
CONFIG_CLOCK_CONTROL=y
# SYSCLK selection
CONFIG_CLOCK_STM32_SYSCLK_SRC_PLL=y
# HSE configuration
CONFIG_CLOCK_STM32_HSE_CLOCK=8000000
# however, the board does not have an external oscillator, so just use
# the 8MHz clock signal coming from integrated STLink
CONFIG_CLOCK_STM32_HSE_BYPASS=y
# PLL configuration
CONFIG_CLOCK_STM32_PLL_SRC_HSE=y
# produce 48MHz clock at PLL output
CONFIG_CLOCK_STM32_PLL_PREDIV1=1
CONFIG_CLOCK_STM32_PLL_MULTIPLIER=6
CONFIG_CLOCK_STM32_AHB_PRESCALER=1
CONFIG_CLOCK_STM32_APB1_PRESCALER=1

I would ideally like to make use of these variables or the Zephyr
functions that use these variables when initializing the chip. Which
functions should I be looking out for in order to make use of these
variables?

Thanks in advance!
Rob


Re: assertion fail in nordic nrf5 i2c driver

Manu R
 

Thanks, I'll check it out.

On Wed, Oct 10, 2018 at 8:39 PM Marco Tozzini <lists@...> wrote:
Hi Manu,
I think I had the same problem and solved using the process showed here.
https://youtu.be/vioi4OsmB_U

Cheers,
Marco


On October 9, 2018 12:03:01 PM PDT, Manu R <manu@...> wrote:
Carles, I am trying to use 1.13 and am having some issues. I can build hello_world, but when i tried to build anything with i2c, I have issues. ( drivers__i2c was created without source files)
Thanks
Manu

build (master) $ ninja

[0/1] Re-running CMake...

CMake Warning at /Users/manurao/temp/zephyr/cmake/app/boilerplate.cmake:167 (message):

  The build directory must be cleaned pristinely when changing boards

Call Stack (most recent call first):

  CMakeLists.txt:3 (include)



-- Selected BOARD nrf52_pca10040

Zephyr version: 1.13.99

Parsing Kconfig tree in /Users/manurao/temp/zephyr/Kconfig

Loading /Users/manurao/temp/zephyr/samples/hello_world/build/zephyr/.config as base

CMake Warning at /Users/manurao/temp/zephyr/cmake/toolchain.cmake:48 (message):

  gccarmemb is deprecated, please use gnuarmemb instead

Call Stack (most recent call first):

  /Users/manurao/temp/zephyr/cmake/app/boilerplate.cmake:269 (include)

  CMakeLists.txt:3 (include)



-- Generating zephyr/include/generated/generated_dts_board.h

-- Cache files will be written to: /Users/manurao/Library/Caches/zephyr

CMake Error at ../../CMakeLists.txt:544 (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.



-- Configuring incomplete, errors occurred!

See also "/Users/manurao/temp/zephyr/samples/hello_world/build/CMakeFiles/CMakeOutput.log".

See also "/Users/manurao/temp/zephyr/samples/hello_world/build/CMakeFiles/CMakeError.log".

FAILED: build.ninja 

/usr/local/Cellar/cmake/3.11.0/bin/cmake -H/Users/manurao/temp/zephyr/samples/hello_world -B/Users/manurao/temp/zephyr/samples/hello_world/build

ninja: error: rebuilding 'build.ninja': subcommand failed

build (master) $ 


On Tue, Oct 9, 2018 at 12:58 AM Cufi, Carles <Carles.Cufi@...> wrote:

Hi Manu,

 

The I2C driver has since been completely rewritten to use nrfx, our common driver codebase.

Would it be possible for you to try with current master (or at least 1.13) to see if you still face the issues you mention?

 

Carles

 

From: users@... <users@...> On Behalf Of Manu R
Sent: 08 October 2018 18:56
To: devel@...; users@...
Subject: [Zephyr-users] assertion fail in nordic nrf5 i2c driver

 

Hi all, 

I am using a lis2dh12 with a nrf52840, and am on occasion seeing an assertion. 

It happens in the i2c_nrf5_read

 

err=0 txd=0 rxd=0 stopped=0 errsrc=0x0

ASSERTION FAIL [data->stopped] @ <snip>/zephyr_new/drivers/i2c/i2c_nrf5.c:142:

 

We are based off of 5890004ea72066fb4b1e8100bb289fb5a00646a5 ( r 1.12)

 

Can someone shed light on whats happening? It looks like I am waiting for the EVENTS_STOPPED to hit in the isr, but seeing the data->stopped is not set, perhaps its not?

Are there any remedies? It looks like this condition should be benign, am I mistaken?

 

Thanks

Manu


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Re: STM32f0 Stop Mode

Erwan Gouriou
 

Hi Rob,

When exiting stop mode PLL is disabled so you're running on HSI(or similar).
This explain the change of clock speed after stop mode is exited.
So you need to reconfigure and enable the PLL before doing anything else.

Hote it helps.

Erwan


On Thu, 11 Oct 2018 at 04:06, Rob Weber <rob@...> wrote:
On Wed, Oct 10, 2018 at 05:07:09PM -0700, Rob Weber wrote:
> The general pattern I'm following for entering/exiting stop mode is as follows:
> * Set the regulator state in STOP mode: LL_PWR_SetPowerMode(LL_PWR_MODE_STOP_LPREGU)
> * set SLEEPDEEP bit of Cortex System Control Register: SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk
> * Wait for events or interrupts: __WFE()
> * Reconfigure clocks upon waking up (not confident I implemented this correctly)
>
> Once the __WFE hint instruction is called, I see a decrease in power
> consumption and no activity from the main thread. If I press the user
> button to generate an interrupt, I see a bunch of garbage characters
> over the serial terminal as if it's trying to print it's usual "button
> pressed" statement. but there seems to be no proper re-initialization
> after sleep mode.
>
> This leads me to believe that I need to reconfigure the system clocks in
> order to resume main thread execution and access the UART interface.
> I've tried to use SystemInit() and SystemCoreClockUpdate() functions
> found in STM32Cube to re-initialize to system clocks, but they do not
> seem to make a difference.

I believe I just confirmed using the LED on the nucleo board that the
clocks are the issue. I added some code to toggle the LED every 100ms in
the main thread. It toggles as expected while the main thread runs and
stops toggling as soon as the chip enters stop mode. Once I press the
user button the LED toggling resumes, but much slower. One on/off cycle
take about 1 second. So this is some pretty solid proof that the main
thread resumes execution but at a much slower clock frequency.

So my outstanding thoughts are how to re-configure the chips clocks
after stop mode? It might not be an STM32-specific answer, either.
Zephyr seems to initialize the chip's clocks before the applicaiton's
main thread begins execution, so I'm wondering if I should be performing
a similar initialization.

I would appreciate it if anyone has some more information on how to
configure/re-configure the system clocks manually. The Clock settings
are configured in the Makefile for my board, so I would ideally like to
rely on those values rather than having to redeclare those values the app
code.

Thanks in advance,
Rob Weber




Re: assertion fail in nordic nrf5 i2c driver

Marco Tozzini
 

Hi Manu,
I think I had the same problem and solved using the process showed here.
https://youtu.be/vioi4OsmB_U

Cheers,
Marco


On October 9, 2018 12:03:01 PM PDT, Manu R <manu@...> wrote:
Carles, I am trying to use 1.13 and am having some issues. I can build hello_world, but when i tried to build anything with i2c, I have issues. ( drivers__i2c was created without source files)
Thanks
Manu

build (master) $ ninja

[0/1] Re-running CMake...

CMake Warning at /Users/manurao/temp/zephyr/cmake/app/boilerplate.cmake:167 (message):

  The build directory must be cleaned pristinely when changing boards

Call Stack (most recent call first):

  CMakeLists.txt:3 (include)



-- Selected BOARD nrf52_pca10040

Zephyr version: 1.13.99

Parsing Kconfig tree in /Users/manurao/temp/zephyr/Kconfig

Loading /Users/manurao/temp/zephyr/samples/hello_world/build/zephyr/.config as base

CMake Warning at /Users/manurao/temp/zephyr/cmake/toolchain.cmake:48 (message):

  gccarmemb is deprecated, please use gnuarmemb instead

Call Stack (most recent call first):

  /Users/manurao/temp/zephyr/cmake/app/boilerplate.cmake:269 (include)

  CMakeLists.txt:3 (include)



-- Generating zephyr/include/generated/generated_dts_board.h

-- Cache files will be written to: /Users/manurao/Library/Caches/zephyr

CMake Error at ../../CMakeLists.txt:544 (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.



-- Configuring incomplete, errors occurred!

See also "/Users/manurao/temp/zephyr/samples/hello_world/build/CMakeFiles/CMakeOutput.log".

See also "/Users/manurao/temp/zephyr/samples/hello_world/build/CMakeFiles/CMakeError.log".

FAILED: build.ninja 

/usr/local/Cellar/cmake/3.11.0/bin/cmake -H/Users/manurao/temp/zephyr/samples/hello_world -B/Users/manurao/temp/zephyr/samples/hello_world/build

ninja: error: rebuilding 'build.ninja': subcommand failed

build (master) $ 


On Tue, Oct 9, 2018 at 12:58 AM Cufi, Carles <Carles.Cufi@...> wrote:

Hi Manu,

 

The I2C driver has since been completely rewritten to use nrfx, our common driver codebase.

Would it be possible for you to try with current master (or at least 1.13) to see if you still face the issues you mention?

 

Carles

 

From: users@... <users@...> On Behalf Of Manu R
Sent: 08 October 2018 18:56
To: devel@...; users@...
Subject: [Zephyr-users] assertion fail in nordic nrf5 i2c driver

 

Hi all, 

I am using a lis2dh12 with a nrf52840, and am on occasion seeing an assertion. 

It happens in the i2c_nrf5_read

 

err=0 txd=0 rxd=0 stopped=0 errsrc=0x0

ASSERTION FAIL [data->stopped] @ <snip>/zephyr_new/drivers/i2c/i2c_nrf5.c:142:

 

We are based off of 5890004ea72066fb4b1e8100bb289fb5a00646a5 ( r 1.12)

 

Can someone shed light on whats happening? It looks like I am waiting for the EVENTS_STOPPED to hit in the isr, but seeing the data->stopped is not set, perhaps its not?

Are there any remedies? It looks like this condition should be benign, am I mistaken?

 

Thanks

Manu


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Re: STM32f0 Stop Mode

Rob Weber
 

On Wed, Oct 10, 2018 at 05:07:09PM -0700, Rob Weber wrote:
The general pattern I'm following for entering/exiting stop mode is as follows:
* Set the regulator state in STOP mode: LL_PWR_SetPowerMode(LL_PWR_MODE_STOP_LPREGU)
* set SLEEPDEEP bit of Cortex System Control Register: SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk
* Wait for events or interrupts: __WFE()
* Reconfigure clocks upon waking up (not confident I implemented this correctly)

Once the __WFE hint instruction is called, I see a decrease in power
consumption and no activity from the main thread. If I press the user
button to generate an interrupt, I see a bunch of garbage characters
over the serial terminal as if it's trying to print it's usual "button
pressed" statement. but there seems to be no proper re-initialization
after sleep mode.

This leads me to believe that I need to reconfigure the system clocks in
order to resume main thread execution and access the UART interface.
I've tried to use SystemInit() and SystemCoreClockUpdate() functions
found in STM32Cube to re-initialize to system clocks, but they do not
seem to make a difference.
I believe I just confirmed using the LED on the nucleo board that the
clocks are the issue. I added some code to toggle the LED every 100ms in
the main thread. It toggles as expected while the main thread runs and
stops toggling as soon as the chip enters stop mode. Once I press the
user button the LED toggling resumes, but much slower. One on/off cycle
take about 1 second. So this is some pretty solid proof that the main
thread resumes execution but at a much slower clock frequency.

So my outstanding thoughts are how to re-configure the chips clocks
after stop mode? It might not be an STM32-specific answer, either.
Zephyr seems to initialize the chip's clocks before the applicaiton's
main thread begins execution, so I'm wondering if I should be performing
a similar initialization.

I would appreciate it if anyone has some more information on how to
configure/re-configure the system clocks manually. The Clock settings
are configured in the Makefile for my board, so I would ideally like to
rely on those values rather than having to redeclare those values the app
code.

Thanks in advance,
Rob Weber


STM32f0 Stop Mode

Rob Weber
 

Hi All,

I'm working with an STM32f091xC on a new design and I'm currently trying
to enable stop mode to conserve power without fully entering standby
mode. I seem to be entering stop mode properly, but I'm having quite a
bit of trouble exiting stop mode.

I created a sample application that targets the nucleo_f091rc. It's
based on the basic button interrupt found in samples/basic/button.
I have attached the source code for the example for your review.

The general pattern I'm following for entering/exiting stop mode is as follows:
* Set the regulator state in STOP mode: LL_PWR_SetPowerMode(LL_PWR_MODE_STOP_LPREGU)
* set SLEEPDEEP bit of Cortex System Control Register: SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk
* Wait for events or interrupts: __WFE()
* Reconfigure clocks upon waking up (not confident I implemented this correctly)

Once the __WFE hint instruction is called, I see a decrease in power
consumption and no activity from the main thread. If I press the user
button to generate an interrupt, I see a bunch of garbage characters
over the serial terminal as if it's trying to print it's usual "button
pressed" statement. but there seems to be no proper re-initialization
after sleep mode.

This leads me to believe that I need to reconfigure the system clocks in
order to resume main thread execution and access the UART interface.
I've tried to use SystemInit() and SystemCoreClockUpdate() functions
found in STM32Cube to re-initialize to system clocks, but they do not
seem to make a difference.

Does anyone have experience enabling the STM32 stop mode and have any
pointers on how to properly exit this power mode? Does my approach
sound correct so far? Any information is greatly appreciated.

Thanks in advance for your help. Please let me know if you have any
thoughts or questions.

Cheers,
Rob Weber


Re: Sending and receiving mcumgr commands via BLE

Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
 

Great that it works for you now.

 

Andrzej

 

From: Flavio Arieta [mailto:flavioarieta@...]
Sent: Wednesday, October 10, 2018 1:41 PM
To: Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
Subject: Re: [Zephyr-users] Sending and receiving mcumgr commands via BLE

 

Hi Andrzej, thanks for the reply.

 

That could be the cause. I tried everything over again in a new branch to avoid previous issues and it worked.

 

Sorry for my mistake and thanks for the help.

 

 

Flávio Arieta Netto.


Re: [Zephyr-devel] [Zephyr-users] assertion fail in nordic nrf5 i2c driver

Giuliano Franchetto
 

Hi Manu,

Please try with the following configs:

CONFIG_I2C=y
CONFIG_I2C_0_NRF_TWI=y
CONFIG_I2C_0=y
CONFIG_I2C_NRFX=y
CONFIG_I2C_0_NRF_TWI=y
CONFIG_NRFX_TWI=y

Some of these configurations may not be mandatory, but it should work.

Best regards
Giuliano FRANCHETTO
_______________________________________________________
Giuliano FRANCHETTO
CTO
https://intellinium.io

Office : +33 9 82 59 33 01
Mobile : +33 6 73 14 95 12
Email : giuliano.franchetto@intellinium.com

Société INTELLINIUM
Technopôle Arbois-Méditerranée,
Av. Louis Philibert, Bât. Laennec Hall A,
13857 Aix en Provence Cedex 3 (France)
________________________________________________________

-----Message d'origine-----
De : users@lists.zephyrproject.org <users@lists.zephyrproject.org> De la part de Himanshu Jha
Envoyé : mercredi 10 octobre 2018 07:01
À : Manu R <manu@culvertengineering.com>
Cc : Cufi, Carles <Carles.Cufi@nordicsemi.no>; devel@lists.zephyrproject.org; users@lists.zephyrproject.org; Głąbek, Andrzej <Andrzej.Glabek@nordicsemi.no>; Mieruński, Mieszko <Mieszko.Mierunski@nordicsemi.no>
Objet : Re: [Zephyr-devel] [Zephyr-users] assertion fail in nordic nrf5 i2c driver

Hi Manu,

On Tue, Oct 09, 2018 at 12:03:01PM -0700, Manu R wrote:
Carles, I am trying to use 1.13 and am having some issues. I can build
hello_world, but when i tried to build anything with i2c, I have
issues. ( drivers__i2c was created without source files)
Try this:

diff --git a/samples/drivers/i2c_fujitsu_fram/prj.conf b/samples/drivers/i2c_fujitsu_fram/prj.conf
index f9659582c..484e813e7 100644
--- a/samples/drivers/i2c_fujitsu_fram/prj.conf
+++ b/samples/drivers/i2c_fujitsu_fram/prj.conf
@@ -1,4 +1,4 @@
CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y

-CONFIG_I2C=y
+#CONFIG_I2C=y


After this you can select whatever CONFIG you want to select in the `ninja menuconfig`.

Also, just to test that your board and environment, I would first suggest trying sample programs:
https://docs.zephyrproject.org/latest/boards/arm/nrf52840_pca10056/doc/nrf52840_pca10056.html#testing-the-leds-and-buttons-in-the-nrf52840-pdk

Flash these samples and test to see everything is fine.

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


Re: [Zephyr-devel] [Zephyr-users] assertion fail in nordic nrf5 i2c driver

Himanshu Jha <himanshujha199640@...>
 

Hi Manu,

On Tue, Oct 09, 2018 at 12:03:01PM -0700, Manu R wrote:
Carles, I am trying to use 1.13 and am having some issues. I can build
hello_world, but when i tried to build anything with i2c, I have issues. (
drivers__i2c was created without source files)
Try this:

diff --git a/samples/drivers/i2c_fujitsu_fram/prj.conf b/samples/drivers/i2c_fujitsu_fram/prj.conf
index f9659582c..484e813e7 100644
--- a/samples/drivers/i2c_fujitsu_fram/prj.conf
+++ b/samples/drivers/i2c_fujitsu_fram/prj.conf
@@ -1,4 +1,4 @@
CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y

-CONFIG_I2C=y
+#CONFIG_I2C=y


After this you can select whatever CONFIG you want to select
in the `ninja menuconfig`.

Also, just to test that your board and environment, I would first
suggest trying sample programs:
https://docs.zephyrproject.org/latest/boards/arm/nrf52840_pca10056/doc/nrf52840_pca10056.html#testing-the-leds-and-buttons-in-the-nrf52840-pdk

Flash these samples and test to see everything is fine.

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


Re: assertion fail in nordic nrf5 i2c driver

Manu R
 

Carles, I am trying to use 1.13 and am having some issues. I can build hello_world, but when i tried to build anything with i2c, I have issues. ( drivers__i2c was created without source files)
Thanks
Manu

build (master) $ ninja

[0/1] Re-running CMake...

CMake Warning at /Users/manurao/temp/zephyr/cmake/app/boilerplate.cmake:167 (message):

  The build directory must be cleaned pristinely when changing boards

Call Stack (most recent call first):

  CMakeLists.txt:3 (include)



-- Selected BOARD nrf52_pca10040

Zephyr version: 1.13.99

Parsing Kconfig tree in /Users/manurao/temp/zephyr/Kconfig

Loading /Users/manurao/temp/zephyr/samples/hello_world/build/zephyr/.config as base

CMake Warning at /Users/manurao/temp/zephyr/cmake/toolchain.cmake:48 (message):

  gccarmemb is deprecated, please use gnuarmemb instead

Call Stack (most recent call first):

  /Users/manurao/temp/zephyr/cmake/app/boilerplate.cmake:269 (include)

  CMakeLists.txt:3 (include)



-- Generating zephyr/include/generated/generated_dts_board.h

-- Cache files will be written to: /Users/manurao/Library/Caches/zephyr

CMake Error at ../../CMakeLists.txt:544 (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.



-- Configuring incomplete, errors occurred!

See also "/Users/manurao/temp/zephyr/samples/hello_world/build/CMakeFiles/CMakeOutput.log".

See also "/Users/manurao/temp/zephyr/samples/hello_world/build/CMakeFiles/CMakeError.log".

FAILED: build.ninja 

/usr/local/Cellar/cmake/3.11.0/bin/cmake -H/Users/manurao/temp/zephyr/samples/hello_world -B/Users/manurao/temp/zephyr/samples/hello_world/build

ninja: error: rebuilding 'build.ninja': subcommand failed

build (master) $ 


On Tue, Oct 9, 2018 at 12:58 AM Cufi, Carles <Carles.Cufi@...> wrote:

Hi Manu,

 

The I2C driver has since been completely rewritten to use nrfx, our common driver codebase.

Would it be possible for you to try with current master (or at least 1.13) to see if you still face the issues you mention?

 

Carles

 

From: users@... <users@...> On Behalf Of Manu R
Sent: 08 October 2018 18:56
To: devel@...; users@...
Subject: [Zephyr-users] assertion fail in nordic nrf5 i2c driver

 

Hi all, 

I am using a lis2dh12 with a nrf52840, and am on occasion seeing an assertion. 

It happens in the i2c_nrf5_read

 

err=0 txd=0 rxd=0 stopped=0 errsrc=0x0

ASSERTION FAIL [data->stopped] @ <snip>/zephyr_new/drivers/i2c/i2c_nrf5.c:142:

 

We are based off of 5890004ea72066fb4b1e8100bb289fb5a00646a5 ( r 1.12)

 

Can someone shed light on whats happening? It looks like I am waiting for the EVENTS_STOPPED to hit in the isr, but seeing the data->stopped is not set, perhaps its not?

Are there any remedies? It looks like this condition should be benign, am I mistaken?

 

Thanks

Manu


Re: Sending and receiving mcumgr commands via BLE

Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
 

From: Cufi, Carles
Sent: Tuesday, October 09, 2018 11:30 AM
To: Flavio Arieta <flavioarieta@...>; zephyr-users@...; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
Subject: RE: [Zephyr-users] Sending and receiving mcumgr commands via BLE

 

+Andrzej

 

Carles

 

From: users@... <users@...> On Behalf Of Flavio Arieta
Sent: 05 October 2018 19:57
To: zephyr-users@...
Subject: [Zephyr-users] Sending and receiving mcumgr commands via BLE

 

Hi,

 

I'm trying to send an image to my board (nrf52_pca10040) using mcumgr via BLE (Zephyr v1.13.0) and encountered some problems while doing so.

 

Example followed: "samples/subsys/mgmt/mcumgr/smp_svr". The only thing that I changed was disabling CONFIG_MCUMGR_CMD_FS_MGMT and CONFIG_FILE_SYSTEM_NFFS since I am not going to use nffs fs.

 

I started doing some tests with easier commands:

Command:

sudo mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image list

Reply:

Images:

 slot=0

    version: 1.2.0

    bootable: true

    flags: active confirmed

    hash: 4a9fab74e71499df7dfe71c605852a5e63d794920a705e264d980f7374873166

Split status: N/A (0)

and:

Command: 

sudo mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' reset

Result:

Board resets normally


Then I tried to both test the current image and upload a new image:

sudo mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image test 4a9fab74e71499df7dfe71c605852a5e63d794920a705e264d980f7374873166 -t 100

sudo mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' -t 90 image upload dfu-zephyr.bin

 

 

They do connect via BLE every time, but unfortunately these last 2 commands end up hanging (always 0% on the image upload).

On the upload command it even erases the flash, but don't go as further as to receive any part of the new image.

 

 

Logs from mcumgr:

 

Am I missing something? Because it seems that the communication from both are right, but some reply messages seem to never arrive to my notebook using mcumgr-cli.

 

 

Thanks,

Flávio Arieta Netto.


Re: assertion fail in nordic nrf5 i2c driver

Manu R
 

Carles, appreciate the response. 
That was definitely one of my experiments to try. 
However, we have had a relatively stable base with r1.12 and I am not sure we can change to 1.13 without some regression testing. 

I will certainly try 1.13 and update you. 

(A different issue I see in the driver is related to the power consumption being high(~1ma) for ~1.2s after i2c transactions are done. Any idea what that might be?)
Thanks a lot, I appreciate the help. 
M

On Tue, Oct 9, 2018 at 12:58 AM Cufi, Carles <Carles.Cufi@...> wrote:

Hi Manu,

 

The I2C driver has since been completely rewritten to use nrfx, our common driver codebase.

Would it be possible for you to try with current master (or at least 1.13) to see if you still face the issues you mention?

 

Carles

 

From: users@... <users@...> On Behalf Of Manu R
Sent: 08 October 2018 18:56
To: devel@...; users@...
Subject: [Zephyr-users] assertion fail in nordic nrf5 i2c driver

 

Hi all, 

I am using a lis2dh12 with a nrf52840, and am on occasion seeing an assertion. 

It happens in the i2c_nrf5_read

 

err=0 txd=0 rxd=0 stopped=0 errsrc=0x0

ASSERTION FAIL [data->stopped] @ <snip>/zephyr_new/drivers/i2c/i2c_nrf5.c:142:

 

We are based off of 5890004ea72066fb4b1e8100bb289fb5a00646a5 ( r 1.12)

 

Can someone shed light on whats happening? It looks like I am waiting for the EVENTS_STOPPED to hit in the isr, but seeing the data->stopped is not set, perhaps its not?

Are there any remedies? It looks like this condition should be benign, am I mistaken?

 

Thanks

Manu


Re: Sending and receiving mcumgr commands via BLE

Carles Cufi
 

+Andrzej

 

Carles

 

From: users@... <users@...> On Behalf Of Flavio Arieta
Sent: 05 October 2018 19:57
To: zephyr-users@...
Subject: [Zephyr-users] Sending and receiving mcumgr commands via BLE

 

Hi,

 

I'm trying to send an image to my board (nrf52_pca10040) using mcumgr via BLE (Zephyr v1.13.0) and encountered some problems while doing so.

 

Example followed: "samples/subsys/mgmt/mcumgr/smp_svr". The only thing that I changed was disabling CONFIG_MCUMGR_CMD_FS_MGMT and CONFIG_FILE_SYSTEM_NFFS since I am not going to use nffs fs.

 

I started doing some tests with easier commands:

Command:

sudo mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image list

Reply:

Images:

 slot=0

    version: 1.2.0

    bootable: true

    flags: active confirmed

    hash: 4a9fab74e71499df7dfe71c605852a5e63d794920a705e264d980f7374873166

Split status: N/A (0)

and:

Command: 

sudo mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' reset

Result:

Board resets normally


Then I tried to both test the current image and upload a new image:

sudo mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image test 4a9fab74e71499df7dfe71c605852a5e63d794920a705e264d980f7374873166 -t 100

sudo mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' -t 90 image upload dfu-zephyr.bin

 

 

They do connect via BLE every time, but unfortunately these last 2 commands end up hanging (always 0% on the image upload).

On the upload command it even erases the flash, but don't go as further as to receive any part of the new image.

 

 

Logs from mcumgr:

 

Am I missing something? Because it seems that the communication from both are right, but some reply messages seem to never arrive to my notebook using mcumgr-cli.

 

 

Thanks,

Flávio Arieta Netto.


Re: assertion fail in nordic nrf5 i2c driver

Carles Cufi
 

Hi Manu,

 

The I2C driver has since been completely rewritten to use nrfx, our common driver codebase.

Would it be possible for you to try with current master (or at least 1.13) to see if you still face the issues you mention?

 

Carles

 

From: users@... <users@...> On Behalf Of Manu R
Sent: 08 October 2018 18:56
To: devel@...; users@...
Subject: [Zephyr-users] assertion fail in nordic nrf5 i2c driver

 

Hi all, 

I am using a lis2dh12 with a nrf52840, and am on occasion seeing an assertion. 

It happens in the i2c_nrf5_read

 

err=0 txd=0 rxd=0 stopped=0 errsrc=0x0

ASSERTION FAIL [data->stopped] @ <snip>/zephyr_new/drivers/i2c/i2c_nrf5.c:142:

 

We are based off of 5890004ea72066fb4b1e8100bb289fb5a00646a5 ( r 1.12)

 

Can someone shed light on whats happening? It looks like I am waiting for the EVENTS_STOPPED to hit in the isr, but seeing the data->stopped is not set, perhaps its not?

Are there any remedies? It looks like this condition should be benign, am I mistaken?

 

Thanks

Manu


Strange power consumption _after_ I2C transactions on nrf52840

Manu R
 

Hi All,

We have a custom board with a nrf52840 and multiple I2C devices( accel, pressure, etc).

We noticed that anytime we do an I2C transaction ( reads in particular), the current draw is abnormally high ( ~1 mA) for almost 1.2 seconds after the transaction ! After that, it drops to our system normal ( ~55uA).

In the i2c_nrf5_transfer function, the TWI is disabled around line 249. When I add a k_sleep() before this instruction, the current stays high for that much longer. when I do it after this, it doesnt change the 1.2second pulse.
...
twi->ENABLE = TWI_ENABLE_ENABLE_Disabled;

From this, I surmise that there is some delayed mechanism after the disable IN THE TWI PERIPHERAL I hypothesize that its not my i2c device since the same thing happens with other devices on my bus as well.

Can anyone from nordic please shed some light on this? 
Much obliged!
Manu Rao


assertion fail in nordic nrf5 i2c driver

Manu R
 

Hi all, 
I am using a lis2dh12 with a nrf52840, and am on occasion seeing an assertion. 
It happens in the i2c_nrf5_read

err=0 txd=0 rxd=0 stopped=0 errsrc=0x0
ASSERTION FAIL [data->stopped] @ <snip>/zephyr_new/drivers/i2c/i2c_nrf5.c:142:

We are based off of 5890004ea72066fb4b1e8100bb289fb5a00646a5 ( r 1.12)

Can someone shed light on whats happening? It looks like I am waiting for the EVENTS_STOPPED to hit in the isr, but seeing the data->stopped is not set, perhaps its not?
Are there any remedies? It looks like this condition should be benign, am I mistaken?

Thanks
Manu


Sending and receiving mcumgr commands via BLE

Flavio Arieta <flavioarieta@...>
 

Hi,

I'm trying to send an image to my board (nrf52_pca10040) using mcumgr via BLE (Zephyr v1.13.0) and encountered some problems while doing so.

Example followed: "samples/subsys/mgmt/mcumgr/smp_svr". The only thing that I changed was disabling CONFIG_MCUMGR_CMD_FS_MGMT and CONFIG_FILE_SYSTEM_NFFS since I am not going to use nffs fs.

I started doing some tests with easier commands:
Command:
sudo mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image list
Reply:
Images:
 slot=0
    version: 1.2.0
    bootable: true
    flags: active confirmed
    hash: 4a9fab74e71499df7dfe71c605852a5e63d794920a705e264d980f7374873166
Split status: N/A (0)
and:
Command: 
sudo mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' reset
Result:
Board resets normally

Then I tried to both test the current image and upload a new image:
sudo mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image test 4a9fab74e71499df7dfe71c605852a5e63d794920a705e264d980f7374873166 -t 100
sudo mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' -t 90 image upload dfu-zephyr.bin


They do connect via BLE every time, but unfortunately these last 2 commands end up hanging (always 0% on the image upload).
On the upload command it even erases the flash, but don't go as further as to receive any part of the new image.


Logs from mcumgr:

Am I missing something? Because it seems that the communication from both are right, but some reply messages seem to never arrive to my notebook using mcumgr-cli.


Thanks,
Flávio Arieta Netto.


Re: WSL builds now functional

Saurabh Pandey
 


Good to know that we can work on WSL

On Thursday, 4 October, 2018, 2:01:30 PM IST, Cufi, Carles <carles.cufi@...> wrote:


Hi all,

You might know that if you use Windows 10, you can benefit from WSL (Windows Subsystem for Linux) to build Zephyr. This is of course no longer necessary, since we now fully support native Windows command prompts, but it can be useful if you want to run sanitycheck (not yet ported to Windows) or other Linux-only tools.

Until now there was a bug [1] in WSL that prevented Zephyr for building on WSL. This has now been fixed in Windows 10 release 1809, so I took the opportunity to build tests/bluetooth/shell for nrf52_pca10040 on my (very slow) Windows laptop and compare times:

Linux VM: 21s
Native Windows Command Prompt: 24s
WSL: 26s

As always you are free to pick your platform (macOS works fine too) to build Zephyr.

Carles



1721 - 1740 of 2846