Date   

Re: MPU fault while testing Bluetooth Mesh Sample demos

vikrant8051 <vikrant8051@...>
 

Hi Vinayak,

No. The issue has solved now.

Regards,
vikrant


On Thu, Sep 27, 2018 at 1:14 PM Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
Are you still receiving MPU Fault? I have solved someone's similar problem., and had a question if you are using GATT API and by any chance the control flows through bt_att_req_send function?

-Vinayak



-----Original Message-----
From: <devel@...> on behalf of Jiří Kubias <jiri.kubias@...>
Date: Tuesday, 18 September 2018 at 8:07 AM
To: vikrant8051 <vikrant8051@...>
Cc: Carles Cufi <Carles.Cufi@...>, "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos

    Hi,
    last night I have discovered that I have messed up variables and I have tried to assign value to constant variable -> that is the reason why I have received the MPU fault.


    Best regards,
    Jiri


    po 17. 9. 2018 v 16:29 odesílatel Jiří Kubias <jiri.kubias@...> napsal:


    Hi,
    In my case the MPU falut was stable. But in your case it looks like some race condition issue.


    Try to reorganise the initialisation or add some delays.


    Regards Jiri




    Dne po 17. 9. 2018 15:39 uživatel Vikrant More <vikrant8051@...> napsal:


    Hi Jiri,
    After replying to your email, I once again started testing thoroughly.
    And yes, once again I got MPU fault.


    Regards,
    Vikrant



    On Mon, Sep 17, 2018 at 6:30 PM vikrant8051 <vikrant8051@...> wrote:


    HI Jiri,
    After latest sync with master, I've not faced MPU FAULT issue
    while testing. But it could be there. With v1.13, it could be suddenly
    pops-up without any reason (as a app developer)



    Thanks for linking your issue with this mailing list. Hope Zephyr

    core developers will resolve it.



    Regards,
    vikrant







    On Mon, Sep 17, 2018 at 12:37 PM Jiří Kubias <jiri.kubias@...> wrote:


    Hi,
    have you found a solution? Few days ago I have reported similar problem with MPU fault but with Atmel (Microchip) SAME70 chip. It is cased by binding DMA.

        dev_cfg->dev_dma = device_get_binding(CONFIG_SPI_SAM_DMA_NAME);
    if (!dev_cfg->dev_dma) {
    SYS_LOG_ERR("%s device not found", CONFIG_SPI_SAM_DMA_NAME);
    return -ENODEV;
    }





    and the console output  is

    ***** MPU FAULT *****
     Data Access Violation
     MMFAR Address: 0x412198
    ***** Hardware exception *****
    Current thread ID = 0x204024b4
    Faulting instruction address = 0x40e376
    Fatal fault in essential thread! Spinning...





    So far I didnt solved the issue, but I didnt had a much time to debug it.


    Best regards,
    Jiri






    2018-09-14 12:33 GMT+02:00 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@... <mailto:devel@...> <devel@...>
    On Behalf Of vikrant8051
    Sent: 14 September 2018 11:48
    To:
    devel@... <mailto:devel@...>;
    users@... <mailto: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 !!



























    --
    ===================================================
    Ing. Jiri Kubias

    e-mail: jiri.kubias@...
    mobile: 775 593 956
    ===================================================


















    --
    ===================================================
    Ing. Jiri Kubias

    e-mail: jiri.kubias@...
    mobile: 775 593 956
    ===================================================


Re: MPU fault while testing Bluetooth Mesh Sample demos

Jiří Kubias <jiri.kubias@...>
 

Hi,
no. Each time I received MPU fault it was my mistake. I have made two mistakes: Write into const value (this is really not working) and i called k_free from ISR (I didnt realize that DMA callback is called from DMA ISR). After this I have no more MPU fault. 

Im not using BLE.

Regards, 
Jiri 

čt 27. 9. 2018 v 9:44 odesílatel Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> napsal:

Are you still receiving MPU Fault? I have solved someone's similar problem., and had a question if you are using GATT API and by any chance the control flows through bt_att_req_send function?

-Vinayak



-----Original Message-----
From: <devel@...> on behalf of Jiří Kubias <jiri.kubias@...>
Date: Tuesday, 18 September 2018 at 8:07 AM
To: vikrant8051 <vikrant8051@...>
Cc: Carles Cufi <Carles.Cufi@...>, "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos

    Hi,
    last night I have discovered that I have messed up variables and I have tried to assign value to constant variable -> that is the reason why I have received the MPU fault.


    Best regards,
    Jiri


    po 17. 9. 2018 v 16:29 odesílatel Jiří Kubias <jiri.kubias@...> napsal:


    Hi,
    In my case the MPU falut was stable. But in your case it looks like some race condition issue.


    Try to reorganise the initialisation or add some delays.


    Regards Jiri




    Dne po 17. 9. 2018 15:39 uživatel Vikrant More <vikrant8051@...> napsal:


    Hi Jiri,
    After replying to your email, I once again started testing thoroughly.
    And yes, once again I got MPU fault.


    Regards,
    Vikrant



    On Mon, Sep 17, 2018 at 6:30 PM vikrant8051 <vikrant8051@...> wrote:


    HI Jiri,
    After latest sync with master, I've not faced MPU FAULT issue
    while testing. But it could be there. With v1.13, it could be suddenly
    pops-up without any reason (as a app developer)



    Thanks for linking your issue with this mailing list. Hope Zephyr

    core developers will resolve it.



    Regards,
    vikrant







    On Mon, Sep 17, 2018 at 12:37 PM Jiří Kubias <jiri.kubias@...> wrote:


    Hi,
    have you found a solution? Few days ago I have reported similar problem with MPU fault but with Atmel (Microchip) SAME70 chip. It is cased by binding DMA.

        dev_cfg->dev_dma = device_get_binding(CONFIG_SPI_SAM_DMA_NAME);
    if (!dev_cfg->dev_dma) {
    SYS_LOG_ERR("%s device not found", CONFIG_SPI_SAM_DMA_NAME);
    return -ENODEV;
    }





    and the console output  is

    ***** MPU FAULT *****
     Data Access Violation
     MMFAR Address: 0x412198
    ***** Hardware exception *****
    Current thread ID = 0x204024b4
    Faulting instruction address = 0x40e376
    Fatal fault in essential thread! Spinning...





    So far I didnt solved the issue, but I didnt had a much time to debug it.


    Best regards,
    Jiri






    2018-09-14 12:33 GMT+02:00 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@... <mailto:devel@...> <devel@...>
    On Behalf Of vikrant8051
    Sent: 14 September 2018 11:48
    To:
    devel@... <mailto:devel@...>;
    users@... <mailto: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 !!



























    --
    ===================================================
    Ing. Jiri Kubias

    e-mail: jiri.kubias@...
    mobile: 775 593 956
    ===================================================


















    --
    ===================================================
    Ing. Jiri Kubias

    e-mail: jiri.kubias@...
    mobile: 775 593 956
    ===================================================



--
===================================================
Ing. Jiri Kubias
 
e-mail: jiri.kubias@...
mobile: 775 593 956
===================================================


Re: MPU fault while testing Bluetooth Mesh Sample demos

Chettimada, Vinayak Kariappa
 

Are you still receiving MPU Fault? I have solved someone's similar problem., and had a question if you are using GATT API and by any chance the control flows through bt_att_req_send function?

-Vinayak

-----Original Message-----
From: <devel@lists.zephyrproject.org> on behalf of Jiří Kubias <jiri.kubias@gmail.com>
Date: Tuesday, 18 September 2018 at 8:07 AM
To: vikrant8051 <vikrant8051@gmail.com>
Cc: Carles Cufi <Carles.Cufi@nordicsemi.no>, "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>, "users@lists.zephyrproject.org" <users@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos

Hi,
last night I have discovered that I have messed up variables and I have tried to assign value to constant variable -> that is the reason why I have received the MPU fault.


Best regards,
Jiri


po 17. 9. 2018 v 16:29 odesílatel Jiří Kubias <jiri.kubias@gmail.com> napsal:


Hi,
In my case the MPU falut was stable. But in your case it looks like some race condition issue.


Try to reorganise the initialisation or add some delays.


Regards Jiri




Dne po 17. 9. 2018 15:39 uživatel Vikrant More <vikrant8051@gmail.com> napsal:


Hi Jiri,
After replying to your email, I once again started testing thoroughly.
And yes, once again I got MPU fault.


Regards,
Vikrant



On Mon, Sep 17, 2018 at 6:30 PM vikrant8051 <vikrant8051@gmail.com> wrote:


HI Jiri,
After latest sync with master, I've not faced MPU FAULT issue
while testing. But it could be there. With v1.13, it could be suddenly
pops-up without any reason (as a app developer)



Thanks for linking your issue with this mailing list. Hope Zephyr

core developers will resolve it.



Regards,
vikrant







On Mon, Sep 17, 2018 at 12:37 PM Jiří Kubias <jiri.kubias@gmail.com> wrote:


Hi,
have you found a solution? Few days ago I have reported similar problem with MPU fault but with Atmel (Microchip) SAME70 chip. It is cased by binding DMA.

dev_cfg->dev_dma = device_get_binding(CONFIG_SPI_SAM_DMA_NAME);
if (!dev_cfg->dev_dma) {
SYS_LOG_ERR("%s device not found", CONFIG_SPI_SAM_DMA_NAME);
return -ENODEV;
}





and the console output is

***** MPU FAULT *****
Data Access Violation
MMFAR Address: 0x412198
***** Hardware exception *****
Current thread ID = 0x204024b4
Faulting instruction address = 0x40e376
Fatal fault in essential thread! Spinning...





So far I didnt solved the issue, but I didnt had a much time to debug it.


Best regards,
Jiri






2018-09-14 12:33 GMT+02:00 vikrant8051 <vikrant8051@gmail.com>:

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@nordicsemi.no> wrote:


Hi there,

Did you run addr2line in 0x20001c5c?
Have you tried increasing stack sizes?

Carles

From:
devel@lists.zephyrproject.org <mailto:devel@lists.zephyrproject.org> <devel@lists.zephyrproject.org>
On Behalf Of vikrant8051
Sent: 14 September 2018 11:48
To:
devel@lists.zephyrproject.org <mailto:devel@lists.zephyrproject.org>;
users@lists.zephyrproject.org <mailto:users@lists.zephyrproject.org>
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@gmail.com> 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 !!



























--
===================================================
Ing. Jiri Kubias

e-mail: jiri.kubias@gmail.com
mobile: 775 593 956
===================================================


















--
===================================================
Ing. Jiri Kubias

e-mail: jiri.kubias@gmail.com
mobile: 775 593 956
===================================================


Re: BLE stack using PPI channels #ble #nrf52832

robert.konc@...
 

Hi Charles

We need 6 PPI channels to drive BLDC motor.
For now I'm modify radio_nrf5_ppi.h. So I could work.
File si also attached.
In begginig of file is  #define CONFIG_BT_NRF52X_RADIO_EVENT_TIMER which enable to use predefine PPI's.
 


Python Conference and devsprint in India

Sathishkumar Duraisamy <bewithsathish@...>
 

Hi All,


I new to zephyr. Last few weeks I have been experiment with zephyr and also the west.


I have some proposal, there is python conference going to take place in India on Oct 6,7 with devsprint on Oct 8, 9. Here is the link for devsprint https://in.pycon.org/cfp/devsprint-2018/proposals/. Shall we use devsprint to bring some contribution to west?



Thanks and Regards,
Sathishkumar D


Re: BLE stack using PPI channels #ble #nrf52832

Chettimada, Vinayak Kariappa
 

Hi,

Only 5 of the pre-programmed PPI can be reused in Zephyr's BLE implementation. But the task to refactor the controller is not simple (i.e. not doable in a day or two).

In upstream Zephyr, PPI's 16,17, 18 and 19 are free for nRF52832. And additionally, 14 and 15 are free if PA/LNA is not enabled.

Regards,
Vinayak

-----Original Message-----
From: "Chettimada, Vinayak Kariappa" <vinayak.kariappa.chettimada@nordicsemi.no>
Date: Wednesday, 26 September 2018 at 1:02 PM
To: Carles Cufi <Carles.Cufi@nordicsemi.no>, "Bøe, Sebastian" <Sebastian.Boe@nordicsemi.no>, "robert.konc@controlmatik.eu" <robert.konc@controlmatik.eu>, "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>
Cc: Andrzej Głąbek <Andrzej.Glabek@nordicsemi.no>
Subject: Re: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832

Hi,

The pre-programmed PPI are very specific to Nordic's in-house stack implementation needs. Some of them coincidentally can be re-used in Zephyr implementation.
I will try to send a PR by EOD, if its doing in few minutes. Else, assume that it’s a bit more work.

Regards,
Vinayak

-----Original Message-----
From: Carles Cufi <Carles.Cufi@nordicsemi.no>
Date: Wednesday, 26 September 2018 at 12:53 PM
To: "Bøe, Sebastian" <Sebastian.Boe@nordicsemi.no>, "robert.konc@controlmatik.eu" <robert.konc@controlmatik.eu>, "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>
Cc: Andrzej Głąbek <Andrzej.Glabek@nordicsemi.no>, "Chettimada, Vinayak Kariappa" <vinayak.kariappa.chettimada@nordicsemi.no>
Subject: RE: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832

Hi Sebastian, Robert,

Sebastian, thanks for pointing out the existing issue.
Robert, would you please comment on that issue stating the needs of your application so we can evaluate how best to fix this and we can also include you in upcoming Pull Request reviews so you can make sure we've addressed it in a way compatible with your requirements?

Andrzej, Vinayak: We should revisit this as soon as possible. Is DTS an option here? I assume not since this is an nRF-specific hardware resource.

Carles

> -----Original Message-----
> From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
> Behalf Of Sebastian Boe
> Sent: 26 September 2018 12:36
> To: robert.konc@controlmatik.eu; devel@lists.zephyrproject.org
> Subject: Re: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832
>
> Good question, there exists an issue that can be used for this
> discussion:
>
> https://github.com/zephyrproject-rtos/zephyr/issues/7092
>
> ________________________________________
> From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on
> behalf of robert.konc@controlmatik.eu <robert.konc@controlmatik.eu>
> Sent: Wednesday, September 26, 2018 12:33:18 PM
> To: devel@lists.zephyrproject.org
> Subject: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832
>
> In my application I was try to use 6 PPI channels. And I discovered that
> almost all channels is used by BLE stack.
> NRF52 chip have dedicated PPI [20:31] channels for radio. Why this
> challens was not used by BLE stack.
> Is three any posibilities to change this?
>
> Thanks in advance!
>
> Br,
> Robert
>
>
>


Re: BLE stack using PPI channels #ble #nrf52832

Chettimada, Vinayak Kariappa
 

Hi,

The pre-programmed PPI are very specific to Nordic's in-house stack implementation needs. Some of them coincidentally can be re-used in Zephyr implementation.
I will try to send a PR by EOD, if its doing in few minutes. Else, assume that it’s a bit more work.

Regards,
Vinayak

-----Original Message-----
From: Carles Cufi <Carles.Cufi@nordicsemi.no>
Date: Wednesday, 26 September 2018 at 12:53 PM
To: "Bøe, Sebastian" <Sebastian.Boe@nordicsemi.no>, "robert.konc@controlmatik.eu" <robert.konc@controlmatik.eu>, "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>
Cc: Andrzej Głąbek <Andrzej.Glabek@nordicsemi.no>, "Chettimada, Vinayak Kariappa" <vinayak.kariappa.chettimada@nordicsemi.no>
Subject: RE: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832

Hi Sebastian, Robert,

Sebastian, thanks for pointing out the existing issue.
Robert, would you please comment on that issue stating the needs of your application so we can evaluate how best to fix this and we can also include you in upcoming Pull Request reviews so you can make sure we've addressed it in a way compatible with your requirements?

Andrzej, Vinayak: We should revisit this as soon as possible. Is DTS an option here? I assume not since this is an nRF-specific hardware resource.

Carles

> -----Original Message-----
> From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
> Behalf Of Sebastian Boe
> Sent: 26 September 2018 12:36
> To: robert.konc@controlmatik.eu; devel@lists.zephyrproject.org
> Subject: Re: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832
>
> Good question, there exists an issue that can be used for this
> discussion:
>
> https://github.com/zephyrproject-rtos/zephyr/issues/7092
>
> ________________________________________
> From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on
> behalf of robert.konc@controlmatik.eu <robert.konc@controlmatik.eu>
> Sent: Wednesday, September 26, 2018 12:33:18 PM
> To: devel@lists.zephyrproject.org
> Subject: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832
>
> In my application I was try to use 6 PPI channels. And I discovered that
> almost all channels is used by BLE stack.
> NRF52 chip have dedicated PPI [20:31] channels for radio. Why this
> challens was not used by BLE stack.
> Is three any posibilities to change this?
>
> Thanks in advance!
>
> Br,
> Robert
>
>
>


Re: BLE stack using PPI channels #ble #nrf52832

Carles Cufi
 

Hi Sebastian, Robert,

Sebastian, thanks for pointing out the existing issue.
Robert, would you please comment on that issue stating the needs of your application so we can evaluate how best to fix this and we can also include you in upcoming Pull Request reviews so you can make sure we've addressed it in a way compatible with your requirements?

Andrzej, Vinayak: We should revisit this as soon as possible. Is DTS an option here? I assume not since this is an nRF-specific hardware resource.

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Sebastian Boe
Sent: 26 September 2018 12:36
To: robert.konc@controlmatik.eu; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832

Good question, there exists an issue that can be used for this
discussion:

https://github.com/zephyrproject-rtos/zephyr/issues/7092

________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on
behalf of robert.konc@controlmatik.eu <robert.konc@controlmatik.eu>
Sent: Wednesday, September 26, 2018 12:33:18 PM
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832

In my application I was try to use 6 PPI channels. And I discovered that
almost all channels is used by BLE stack.
NRF52 chip have dedicated PPI [20:31] channels for radio. Why this
challens was not used by BLE stack.
Is three any posibilities to change this?

Thanks in advance!

Br,
Robert



Re: BLE stack using PPI channels #ble #nrf52832

Sebastian Boe
 

Good question, there exists an issue that can be used for this discussion:

https://github.com/zephyrproject-rtos/zephyr/issues/7092

________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of robert.konc@controlmatik.eu <robert.konc@controlmatik.eu>
Sent: Wednesday, September 26, 2018 12:33:18 PM
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832

In my application I was try to use 6 PPI channels. And I discovered that almost all channels is used by BLE stack.
NRF52 chip have dedicated PPI [20:31] channels for radio. Why this challens was not used by BLE stack.
Is three any posibilities to change this?

Thanks in advance!

Br,
Robert


BLE stack using PPI channels #ble #nrf52832

robert.konc@...
 

In my application I was try to use 6 PPI channels. And I discovered that almost all channels is used by BLE stack.
NRF52 chip have dedicated PPI [20:31] channels for radio. Why this challens was not used by BLE stack.
Is three any posibilities to change this?

Thanks in advance!

Br,
Robert


Re: Bluetooth: about using of NVS & setting Layer in single App

vikrant8051 <vikrant8051@...>
 

Hi Jehudi,

Many thanks for these details which are not available under https://docs.zephyrproject.org/latest/


On Tue 25 Sep, 2018, 1:42 PM Laczen JMS, <laczenjms@...> wrote:
Hi Vikrant,

The dts changes you propose might work, but there are some
disadvantages with it: if you are overlapping the scratch area with
NVS you will loose the data in NVS persistent storage after FOTA.

I guess this is related to your problem on using persistent storage
with btmesh. According to me the best way to use persistent storage in
combination with "btsettings" is to use "btsettings" to store and
retrieve your persistent variables. I don't have the time at the
moment to write a complete example but I can give you some guidelines:

Suppose we need to store a variable named: VID, and its value is
VID_VALUE. The values will be stored under "bt/ps". We will need to
define routines to apply the data at startup from flash: this is a set
routine. Other routines that we could define are export (to save the
data) and commit (to apply the data). For simplicity I will only
describe the case where there is only a set routine and storage will
be done directly.

Registering the routines is done by: BT_SETTINGS_DEFINE(ps, ps_set,
NULL, NULL): this will define a routine ps_set that will be called if
a variable is found under "bt/ps" (e.g. "bt/ps/VID"). The routine
ps_set itself is something like:

static int ps_set(int argc, char **argv, char *val) {
  if (argc!=1) {
    return -EINVAL;
  }
  if (strcmp(argv[0],"VID")==0) {
   len = sizeof(VID_VALUE);
   err = settings_bytes_from_str(val, VID_VALUE, &len);
  }
}

This routine will be called at startup and when VID is found under
"bt/ps" its value will be used to update VID_VALUE.

To store the variable you have to call two routines :
  str = settings_str_from_bytes(&VID_VALUE, sizeof(VID_VALUE), buf,
sizeof(buf));
  settings_save_one("bt/ps/VID", str);

The used buffer is a char array that can be defined as: char
buf[BT_SETTINGS_SIZE(sizeof(VID_VALUE))];
Op ma 24 sep. 2018 om 10:36 schreef Vikrant More <vikrant8051@...>:
>
> Hi,
>
> I've modified nrf52840_pca10056.dts as follow ......
>
> &flash0 {
>     /*
>      * For more information, see:
>      * http://docs.zephyrproject.org/latest/devices/dts/flash_partitions.html
>      */
>     partitions {
>         compatible = "fixed-partitions";
>         #address-cells = <1>;
>         #size-cells = <1>;
>
>         boot_partition: partition@0 {
>             label = "mcuboot";
>             reg = <0x000000000 0x0000C000>;
>         };
>         slot0_partition: partition@c000 {
>             label = "image-0";
>             reg = <0x0000C000 0x000069000>;
>         };
>         slot1_partition: partition@75000 {
>             label = "image-1";
>             reg = <0x00075000 0x000069000>;
>         };
>         scratch_partition: partition@de000 {
>             label = "image-scratch";
>             reg = <0x000de000 0x0001B000>;
>         };
>         nvs_partition: partition@f9000 {
>             label = "storage";
>             reg = <0x000f9000 0x00003000>;
>         };
>
> #if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
>         storage_partition: partition@fc000 {
>             label = "storage";
>             reg = <0x000fc000 0x00004000>;
>         };
> #endif
>     };
> };
>
> That means some part of scratch partition will get utilize ( 12 KB) for #NVS storage.
> After this I've to set #define NVS_STORAGE_OFFSET 0xF9000
>
> Is it correct strategy to save App level data on SoC flash without disturbing
> #settings_layer data as well feature of #FOTA ?
>
> Thank You !!
>
>


Re: Microbit Accelometer

Carles Cufi
 

Hi William,

 

Would you mind sending a GitHub Pull Request instead?

 

https://docs.zephyrproject.org/latest/contribute/contribute_guidelines.html

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of William Fish
Sent: 25 September 2018 12:40
To: devel@...
Subject: [Zephyr-devel] Microbit Accelometer

 

Hi All,

I’m attempting to get the accelometer on the microbit working in Zephyr. I have roughly created a driver based on others yet I could use some help double checking and implementing.

 

Attached are files:

 

Billy...

 

Virus-free. www.avg.com


Re: NRF52 : use of NFFS file system

Puzdrowski, Andrzej
 

  • I found a solution in increasing CONFIG_NFFS_FILESYSTEM_MAX_AREAS to 128

64 is exactly what you need as you use 64 flash pages of nRF52. You can try to use nffs build in statistic to garb some info

On RMA resurces consumed.

 

From: Laurence Pasteau [mailto:laurence.pasteau@...]
Sent: Tuesday, September 25, 2018 4:53 PM
To: Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; zephyr-devel@...; zephyr-users@...
Cc: Andrzej Kaczmarek <andrzej.kaczmarek@...>; Cufi, Carles <Carles.Cufi@...>
Subject: RE: NRF52 : use of NFFS file system

 

Hi Andrzej,

 

I found a solution in increasing CONFIG_NFFS_FILESYSTEM_MAX_AREAS to 128. But then I had a problem of space left in RAM so I decrease CONFIG_FS_NFFS_NUM_INODES to 48, which is enough for me. The solution seems ok for the first tests I make. I need to implement more tests but I can't do it right now.

I tried before that to set CONFIG_FS_NFFS_NUM_BLOCKS  to 2048 but it was not successful.

 

Thanks for your advice,

Regards

Laurence

 


De : Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
Envoyé : mardi 25 septembre 2018 16:37
À : Laurence Pasteau; zephyr-devel@...; zephyr-users@...
Cc : Andrzej Kaczmarek; Cufi, Carles
Objet : RE: NRF52 : use of NFFS file system

 

I think it was possible that you encounter lack of BLOCK representation in RAM (this is what -12 -ENOMEM stand for). Try to increase CONFIG_FS_NFFS_NUM_BLOCKS until success.

Looks like GC was unable to optimize object in flash.

Can you try my advice and let now the reslt?

 

BR

Andrzej

 

From: Laurence Pasteau [mailto:laurence.pasteau@...]
Sent: Friday, September 21, 2018 11:05 AM
To: zephyr-devel@...; zephyr-users@...
Cc: Andrzej Kaczmarek <andrzej.kaczmarek@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Cufi, Carles <Carles.Cufi@...>
Subject: NRF52 : use of NFFS file system

 

Hi all,

 

Thanks having resolved my first issue on NFFS file system.

I work on a nrf52_pca10040 board. My purpose is still to use the file system NFFS to fill the nrf52 flash.

 

My flash config booked half of the flash for the file system :

 

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@40000 {
            label = "storage";
            reg = <0x00040000 0x00040000>;
        };
#endif

 

My test writes in loop 24 bytes in one or more files, as much as possible. (main_test.c attached)

I find a configuration that writes successfully all flash in one single file :

 

CONFIG_SOC_FLASH_NRF=y
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_FILES=10
#CONFIG_FS_NFFS_NUM_INODES=64
CONFIG_HEAP_MEM_POOL_SIZE=1024
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=64
#CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE=4096
CONFIG_FS_FLASH_STORAGE_PARTITION=y
CONFIG_SOC_FLASH_NRF_RADIO_SYNC=y

 

Result test :

test_files : 1 nb files
file write error (-28)
FILE :  test1.bin size 235968
FILE :  test2.bin size 0
FILE :  test3.bin size 0
FILE :  test4.bin size 0
FILE :  test5.bin size 0

Error -28 indicates that the flash is full.That's great.

 

But when I write in 5 differents files, I can not write all the flash and I have another error :

 

Result test :

test_files : 5 nb files
file write error (-12)

FILE :  test1.bin size 20448
FILE :  test2.bin size 20448
FILE :  test3.bin size 20448
FILE :  test4.bin size 20424
FILE :  test5.bin size 20424
write4 error

 

Attached is the little test used to have this result. It is a quick test with both success and error tests.

 

All tests with more than one file fails and I don't understand why. I don't know if my NFFS configuration is not good or if it is an issue in NFFS file ssytem.

 

If someone can help me it will be very helpful.

Thanks in advance,

Regards,

Laurence

 

 

 

 

---

Laurence Pasteau

laurence.pasteau@...

1 Avenue du Professeur Jean Rouxel, ZAC de la Fleuriaye, 44470 Carquefou

www.stimio.fr

 

 

 


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : vendredi 31 août 2018 18:50
À : Laurence Pasteau; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Thanks Laurence, I’ve assigned it and we will deal with it as soon as we can.

 

Regards,

 

Carles

 

From: Laurence Pasteau <laurence.pasteau@...>
Sent: 31 August 2018 18:08
To: Cufi, Carles <Carles.Cufi@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Andrzej Kaczmarek <andrzej.kaczmarek@...>
Subject: RE: NRF52 : use of NFFS file system

 

 

Here is the link :

https://github.com/zephyrproject-rtos/zephyr/issues/9749

 

Regards,

Laurence

 

 


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : vendredi 31 août 2018 16:48
À : Laurence Pasteau; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Hi Laurence,

 

Yes please, if you could open a GitHub issue and then send us the link here we will be able to track it better.

 

Regards,

 

Carles

 

From: Laurence Pasteau <laurence.pasteau@...>
Sent: 31 August 2018 16:17
To: Cufi, Carles <Carles.Cufi@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Andrzej Kaczmarek <andrzej.kaczmarek@...>
Subject: RE: NRF52 : use of NFFS file system

 

Sorry, I meant 0x30000 and 0x40000...

 


De : Laurence Pasteau
Envoyé : vendredi 31 août 2018 15:28
À : Cufi, Carles; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Thanks Carles,

 

the test lasts one or two minutes but can be shorten if necessary. My purpose is to have half of the flash (0x4000 bytes) in the file system. I have now a configuration with a flash system of 0x3000 bytes that has less problem but it still happens.

Files that are badly written are not recoverable, new weird files are not cleanable (with fs_unlink() function) so the system is not usable in my project for the moment.

 

If it is better, I can add an issue in github but I still don't know if I made a mistake in NFFS configuration or in the test, or if it is an issue in the file system.

 

Thanks in advance for any solution / idea / conclusions.

Laurence


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : mardi 28 août 2018 14:36
À : Laurence Pasteau; users@...; devel@...; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Hi Laurence,

 

I am copying a couple of people that might be able to help with NFFS config.

 

Carles

 

From: users@... <users@...> On Behalf Of Laurence Pasteau
Sent: 27 August 2018 10:06
To: users@...; devel@...
Subject: [Zephyr-users] NRF52 : use of NFFS file system

 

Hi everybody,

 

I worked on a board including a NRF52 and use the file system with NFFS but I never succeed in using it correctly.

 

I have a lot of errors depending on the configuration parameters that I set.

I reduce my problem to a little test that only writes in a loop 12 bytes in a single file. It fails very quickly.

Sometimes the operation seems good when checking the return value. However the file became a file of size null and a new file with another name appears with the previous file. Then some loops later, there is an error in a return value of the write function.

 

I tried to modify NFFS configuration.

In the two cases when  the CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE is higher and when the global size of the file system is higher ; the test is good during a longer time before failing.

If I write 24 instead of 12 bytes or if I write in two files instead of one, the issue comes sooner.

 

I think something in my configuration (or in my software) is wrong. If someone can help me it would be very helpful.

 

Attached is the little test and the conf file. To reduce the time before failing, I change the file system size to 0x2000.

 

 

Here is my configuration (I don't use MCU_BOOT) :

 

In the dts file :

    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x00000000 0xc000>;
        };
        slot0_partition: partition@c000 {
            label = "image-0";
            reg = <0x0000C000 0x32000>;
        };
        slot1_partition: partition@3e000 {
            label = "image-1";
            reg = <0x0003E000 0x32000>;
        };
        scratch_partition: partition@70000 {
            label = "image-scratch";
            reg = <0x00070000 0xa000>;
        };

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@7a000 {
            label = "storage";
            reg = <0x0007a000 0x00002000>;
        };
#endif
    };

 

In the conf file :

CONFIG_SOC_FLASH_NRF=y
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_INODES=64
CONFIG_HEAP_MEM_POOL_SIZE=4096
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12
CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE=128
CONFIG_FS_FLASH_STORAGE_PARTITION=y
CONFIG_SOC_FLASH_NRF_RADIO_SYNC=y

 

 

In the CMakeLists.txt :

set(BOARD nrf52_pca10040)

target_include_directories(app PRIVATE $ENV{ZEPHYR_BASE}/ext/fs/nffs/include)
target_link_libraries(app NFFS)

 

 

Thanks in advance for any help.

 

Regards,

Laurence

 

 

 

 


Re: NRF52 : use of NFFS file system

Laurence Pasteau
 

Hi Andrzej,


I found a solution in increasing CONFIG_NFFS_FILESYSTEM_MAX_AREAS to 128. But then I had a problem of space left in RAM so I decrease CONFIG_FS_NFFS_NUM_INODES to 48, which is enough for me. The solution seems ok for the first tests I make. I need to implement more tests but I can't do it right now.

I tried before that to set CONFIG_FS_NFFS_NUM_BLOCKS  to 2048 but it was not successful.


Thanks for your advice,
Regards
Laurence


De : Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
Envoyé : mardi 25 septembre 2018 16:37
À : Laurence Pasteau; zephyr-devel@...; zephyr-users@...
Cc : Andrzej Kaczmarek; Cufi, Carles
Objet : RE: NRF52 : use of NFFS file system
 

I think it was possible that you encounter lack of BLOCK representation in RAM (this is what -12 -ENOMEM stand for). Try to increase CONFIG_FS_NFFS_NUM_BLOCKS until success.

Looks like GC was unable to optimize object in flash.

Can you try my advice and let now the reslt?

 

BR

Andrzej

 

From: Laurence Pasteau [mailto:laurence.pasteau@...]
Sent: Friday, September 21, 2018 11:05 AM
To: zephyr-devel@...; zephyr-users@...
Cc: Andrzej Kaczmarek <andrzej.kaczmarek@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Cufi, Carles <Carles.Cufi@...>
Subject: NRF52 : use of NFFS file system

 

Hi all,

 

Thanks having resolved my first issue on NFFS file system.

I work on a nrf52_pca10040 board. My purpose is still to use the file system NFFS to fill the nrf52 flash.

 

My flash config booked half of the flash for the file system :

 

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@40000 {
            label = "storage";
            reg = <0x00040000 0x00040000>;
        };
#endif

 

My test writes in loop 24 bytes in one or more files, as much as possible. (main_test.c attached)

I find a configuration that writes successfully all flash in one single file :

 

CONFIG_SOC_FLASH_NRF=y
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_FILES=10
#CONFIG_FS_NFFS_NUM_INODES=64
CONFIG_HEAP_MEM_POOL_SIZE=1024
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=64
#CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE=4096
CONFIG_FS_FLASH_STORAGE_PARTITION=y
CONFIG_SOC_FLASH_NRF_RADIO_SYNC=y

 

Result test :

test_files : 1 nb files
file write error (-28)
FILE :  test1.bin size 235968
FILE :  test2.bin size 0
FILE :  test3.bin size 0
FILE :  test4.bin size 0
FILE :  test5.bin size 0

Error -28 indicates that the flash is full.That's great.

 

But when I write in 5 differents files, I can not write all the flash and I have another error :

 

Result test :

test_files : 5 nb files
file write error (-12)

FILE :  test1.bin size 20448
FILE :  test2.bin size 20448
FILE :  test3.bin size 20448
FILE :  test4.bin size 20424
FILE :  test5.bin size 20424
write4 error

 

Attached is the little test used to have this result. It is a quick test with both success and error tests.

 

All tests with more than one file fails and I don't understand why. I don't know if my NFFS configuration is not good or if it is an issue in NFFS file ssytem.

 

If someone can help me it will be very helpful.

Thanks in advance,

Regards,

Laurence

 

 

 

 

---

Laurence Pasteau

laurence.pasteau@...

1 Avenue du Professeur Jean Rouxel, ZAC de la Fleuriaye, 44470 Carquefou

www.stimio.fr

 

 

 


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : vendredi 31 août 2018 18:50
À : Laurence Pasteau; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Thanks Laurence, I’ve assigned it and we will deal with it as soon as we can.

 

Regards,

 

Carles

 

From: Laurence Pasteau <laurence.pasteau@...>
Sent: 31 August 2018 18:08
To: Cufi, Carles <Carles.Cufi@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Andrzej Kaczmarek <andrzej.kaczmarek@...>
Subject: RE: NRF52 : use of NFFS file system

 

 

Here is the link :

https://github.com/zephyrproject-rtos/zephyr/issues/9749

 

Regards,

Laurence

 

 


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : vendredi 31 août 2018 16:48
À : Laurence Pasteau; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Hi Laurence,

 

Yes please, if you could open a GitHub issue and then send us the link here we will be able to track it better.

 

Regards,

 

Carles

 

From: Laurence Pasteau <laurence.pasteau@...>
Sent: 31 August 2018 16:17
To: Cufi, Carles <Carles.Cufi@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Andrzej Kaczmarek <andrzej.kaczmarek@...>
Subject: RE: NRF52 : use of NFFS file system

 

Sorry, I meant 0x30000 and 0x40000...

 


De : Laurence Pasteau
Envoyé : vendredi 31 août 2018 15:28
À : Cufi, Carles; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Thanks Carles,

 

the test lasts one or two minutes but can be shorten if necessary. My purpose is to have half of the flash (0x4000 bytes) in the file system. I have now a configuration with a flash system of 0x3000 bytes that has less problem but it still happens.

Files that are badly written are not recoverable, new weird files are not cleanable (with fs_unlink() function) so the system is not usable in my project for the moment.

 

If it is better, I can add an issue in github but I still don't know if I made a mistake in NFFS configuration or in the test, or if it is an issue in the file system.

 

Thanks in advance for any solution / idea / conclusions.

Laurence


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : mardi 28 août 2018 14:36
À : Laurence Pasteau; users@...; devel@...; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Hi Laurence,

 

I am copying a couple of people that might be able to help with NFFS config.

 

Carles

 

From: users@... <users@...> On Behalf Of Laurence Pasteau
Sent: 27 August 2018 10:06
To: users@...; devel@...
Subject: [Zephyr-users] NRF52 : use of NFFS file system

 

Hi everybody,

 

I worked on a board including a NRF52 and use the file system with NFFS but I never succeed in using it correctly.

 

I have a lot of errors depending on the configuration parameters that I set.

I reduce my problem to a little test that only writes in a loop 12 bytes in a single file. It fails very quickly.

Sometimes the operation seems good when checking the return value. However the file became a file of size null and a new file with another name appears with the previous file. Then some loops later, there is an error in a return value of the write function.

 

I tried to modify NFFS configuration.

In the two cases when  the CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE is higher and when the global size of the file system is higher ; the test is good during a longer time before failing.

If I write 24 instead of 12 bytes or if I write in two files instead of one, the issue comes sooner.

 

I think something in my configuration (or in my software) is wrong. If someone can help me it would be very helpful.

 

Attached is the little test and the conf file. To reduce the time before failing, I change the file system size to 0x2000.

 

 

Here is my configuration (I don't use MCU_BOOT) :

 

In the dts file :

    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x00000000 0xc000>;
        };
        slot0_partition: partition@c000 {
            label = "image-0";
            reg = <0x0000C000 0x32000>;
        };
        slot1_partition: partition@3e000 {
            label = "image-1";
            reg = <0x0003E000 0x32000>;
        };
        scratch_partition: partition@70000 {
            label = "image-scratch";
            reg = <0x00070000 0xa000>;
        };

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@7a000 {
            label = "storage";
            reg = <0x0007a000 0x00002000>;
        };
#endif
    };

 

In the conf file :

CONFIG_SOC_FLASH_NRF=y
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_INODES=64
CONFIG_HEAP_MEM_POOL_SIZE=4096
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12
CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE=128
CONFIG_FS_FLASH_STORAGE_PARTITION=y
CONFIG_SOC_FLASH_NRF_RADIO_SYNC=y

 

 

In the CMakeLists.txt :

set(BOARD nrf52_pca10040)

target_include_directories(app PRIVATE $ENV{ZEPHYR_BASE}/ext/fs/nffs/include)
target_link_libraries(app NFFS)

 

 

Thanks in advance for any help.

 

Regards,

Laurence

 

 

 

 


Re: NRF52 : use of NFFS file system

Puzdrowski, Andrzej
 

I think it was possible that you encounter lack of BLOCK representation in RAM (this is what -12 -ENOMEM stand for). Try to increase CONFIG_FS_NFFS_NUM_BLOCKS until success.

Looks like GC was unable to optimize object in flash.

Can you try my advice and let now the reslt?

 

BR

Andrzej

 

From: Laurence Pasteau [mailto:laurence.pasteau@...]
Sent: Friday, September 21, 2018 11:05 AM
To: zephyr-devel@...; zephyr-users@...
Cc: Andrzej Kaczmarek <andrzej.kaczmarek@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Cufi, Carles <Carles.Cufi@...>
Subject: NRF52 : use of NFFS file system

 

Hi all,

 

Thanks having resolved my first issue on NFFS file system.

I work on a nrf52_pca10040 board. My purpose is still to use the file system NFFS to fill the nrf52 flash.

 

My flash config booked half of the flash for the file system :

 

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@40000 {
            label = "storage";
            reg = <0x00040000 0x00040000>;
        };
#endif

 

My test writes in loop 24 bytes in one or more files, as much as possible. (main_test.c attached)

I find a configuration that writes successfully all flash in one single file :

 

CONFIG_SOC_FLASH_NRF=y
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_FILES=10
#CONFIG_FS_NFFS_NUM_INODES=64
CONFIG_HEAP_MEM_POOL_SIZE=1024
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=64
#CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE=4096
CONFIG_FS_FLASH_STORAGE_PARTITION=y
CONFIG_SOC_FLASH_NRF_RADIO_SYNC=y

 

Result test :

test_files : 1 nb files
file write error (-28)
FILE :  test1.bin size 235968
FILE :  test2.bin size 0
FILE :  test3.bin size 0
FILE :  test4.bin size 0
FILE :  test5.bin size 0

Error -28 indicates that the flash is full.That's great.

 

But when I write in 5 differents files, I can not write all the flash and I have another error :

 

Result test :

test_files : 5 nb files
file write error (-12)

FILE :  test1.bin size 20448
FILE :  test2.bin size 20448
FILE :  test3.bin size 20448
FILE :  test4.bin size 20424
FILE :  test5.bin size 20424
write4 error

 

Attached is the little test used to have this result. It is a quick test with both success and error tests.

 

All tests with more than one file fails and I don't understand why. I don't know if my NFFS configuration is not good or if it is an issue in NFFS file ssytem.

 

If someone can help me it will be very helpful.

Thanks in advance,

Regards,

Laurence

 

 

 

 

---

Laurence Pasteau

laurence.pasteau@...

1 Avenue du Professeur Jean Rouxel, ZAC de la Fleuriaye, 44470 Carquefou

www.stimio.fr

 

 

 


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : vendredi 31 août 2018 18:50
À : Laurence Pasteau; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Thanks Laurence, I’ve assigned it and we will deal with it as soon as we can.

 

Regards,

 

Carles

 

From: Laurence Pasteau <laurence.pasteau@...>
Sent: 31 August 2018 18:08
To: Cufi, Carles <Carles.Cufi@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Andrzej Kaczmarek <andrzej.kaczmarek@...>
Subject: RE: NRF52 : use of NFFS file system

 

 

Here is the link :

https://github.com/zephyrproject-rtos/zephyr/issues/9749

 

Regards,

Laurence

 

 


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : vendredi 31 août 2018 16:48
À : Laurence Pasteau; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Hi Laurence,

 

Yes please, if you could open a GitHub issue and then send us the link here we will be able to track it better.

 

Regards,

 

Carles

 

From: Laurence Pasteau <laurence.pasteau@...>
Sent: 31 August 2018 16:17
To: Cufi, Carles <Carles.Cufi@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Andrzej Kaczmarek <andrzej.kaczmarek@...>
Subject: RE: NRF52 : use of NFFS file system

 

Sorry, I meant 0x30000 and 0x40000...

 


De : Laurence Pasteau
Envoyé : vendredi 31 août 2018 15:28
À : Cufi, Carles; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Thanks Carles,

 

the test lasts one or two minutes but can be shorten if necessary. My purpose is to have half of the flash (0x4000 bytes) in the file system. I have now a configuration with a flash system of 0x3000 bytes that has less problem but it still happens.

Files that are badly written are not recoverable, new weird files are not cleanable (with fs_unlink() function) so the system is not usable in my project for the moment.

 

If it is better, I can add an issue in github but I still don't know if I made a mistake in NFFS configuration or in the test, or if it is an issue in the file system.

 

Thanks in advance for any solution / idea / conclusions.

Laurence


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : mardi 28 août 2018 14:36
À : Laurence Pasteau; users@...; devel@...; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Hi Laurence,

 

I am copying a couple of people that might be able to help with NFFS config.

 

Carles

 

From: users@... <users@...> On Behalf Of Laurence Pasteau
Sent: 27 August 2018 10:06
To: users@...; devel@...
Subject: [Zephyr-users] NRF52 : use of NFFS file system

 

Hi everybody,

 

I worked on a board including a NRF52 and use the file system with NFFS but I never succeed in using it correctly.

 

I have a lot of errors depending on the configuration parameters that I set.

I reduce my problem to a little test that only writes in a loop 12 bytes in a single file. It fails very quickly.

Sometimes the operation seems good when checking the return value. However the file became a file of size null and a new file with another name appears with the previous file. Then some loops later, there is an error in a return value of the write function.

 

I tried to modify NFFS configuration.

In the two cases when  the CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE is higher and when the global size of the file system is higher ; the test is good during a longer time before failing.

If I write 24 instead of 12 bytes or if I write in two files instead of one, the issue comes sooner.

 

I think something in my configuration (or in my software) is wrong. If someone can help me it would be very helpful.

 

Attached is the little test and the conf file. To reduce the time before failing, I change the file system size to 0x2000.

 

 

Here is my configuration (I don't use MCU_BOOT) :

 

In the dts file :

    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x00000000 0xc000>;
        };
        slot0_partition: partition@c000 {
            label = "image-0";
            reg = <0x0000C000 0x32000>;
        };
        slot1_partition: partition@3e000 {
            label = "image-1";
            reg = <0x0003E000 0x32000>;
        };
        scratch_partition: partition@70000 {
            label = "image-scratch";
            reg = <0x00070000 0xa000>;
        };

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@7a000 {
            label = "storage";
            reg = <0x0007a000 0x00002000>;
        };
#endif
    };

 

In the conf file :

CONFIG_SOC_FLASH_NRF=y
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_INODES=64
CONFIG_HEAP_MEM_POOL_SIZE=4096
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12
CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE=128
CONFIG_FS_FLASH_STORAGE_PARTITION=y
CONFIG_SOC_FLASH_NRF_RADIO_SYNC=y

 

 

In the CMakeLists.txt :

set(BOARD nrf52_pca10040)

target_include_directories(app PRIVATE $ENV{ZEPHYR_BASE}/ext/fs/nffs/include)
target_link_libraries(app NFFS)

 

 

Thanks in advance for any help.

 

Regards,

Laurence

 

 

 

 


Microbit Accelometer

William Fish <william.fish@...>
 

Hi All,

I’m attempting to get the accelometer on the microbit working in Zephyr. I have roughly created a driver based on others yet I could use some help double checking and implementing.

 

Attached are files:

 

Billy...


Virus-free. www.avg.com


Microbit accelerometer

William Fish
 

Hi All,

I’m attempting to get the accelerometer on the microbit working in Zephyr. I have roughly created a driver based on others yet I could use some help double checking and implementing.

Any and all help appreciated.

Attached are files:

 

 

Billy...


Re: Bluetooth: about using of NVS & setting Layer in single App

laczenJMS
 

Hi Vikrant,

The dts changes you propose might work, but there are some
disadvantages with it: if you are overlapping the scratch area with
NVS you will loose the data in NVS persistent storage after FOTA.

I guess this is related to your problem on using persistent storage
with btmesh. According to me the best way to use persistent storage in
combination with "btsettings" is to use "btsettings" to store and
retrieve your persistent variables. I don't have the time at the
moment to write a complete example but I can give you some guidelines:

Suppose we need to store a variable named: VID, and its value is
VID_VALUE. The values will be stored under "bt/ps". We will need to
define routines to apply the data at startup from flash: this is a set
routine. Other routines that we could define are export (to save the
data) and commit (to apply the data). For simplicity I will only
describe the case where there is only a set routine and storage will
be done directly.

Registering the routines is done by: BT_SETTINGS_DEFINE(ps, ps_set,
NULL, NULL): this will define a routine ps_set that will be called if
a variable is found under "bt/ps" (e.g. "bt/ps/VID"). The routine
ps_set itself is something like:

static int ps_set(int argc, char **argv, char *val) {
if (argc!=1) {
return -EINVAL;
}
if (strcmp(argv[0],"VID")==0) {
len = sizeof(VID_VALUE);
err = settings_bytes_from_str(val, VID_VALUE, &len);
}
}

This routine will be called at startup and when VID is found under
"bt/ps" its value will be used to update VID_VALUE.

To store the variable you have to call two routines :
str = settings_str_from_bytes(&VID_VALUE, sizeof(VID_VALUE), buf,
sizeof(buf));
settings_save_one("bt/ps/VID", str);

The used buffer is a char array that can be defined as: char
buf[BT_SETTINGS_SIZE(sizeof(VID_VALUE))];
Op ma 24 sep. 2018 om 10:36 schreef Vikrant More <vikrant8051@gmail.com>:


Hi,

I've modified nrf52840_pca10056.dts as follow ......

&flash0 {
/*
* For more information, see:
* http://docs.zephyrproject.org/latest/devices/dts/flash_partitions.html
*/
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;

boot_partition: partition@0 {
label = "mcuboot";
reg = <0x000000000 0x0000C000>;
};
slot0_partition: partition@c000 {
label = "image-0";
reg = <0x0000C000 0x000069000>;
};
slot1_partition: partition@75000 {
label = "image-1";
reg = <0x00075000 0x000069000>;
};
scratch_partition: partition@de000 {
label = "image-scratch";
reg = <0x000de000 0x0001B000>;
};
nvs_partition: partition@f9000 {
label = "storage";
reg = <0x000f9000 0x00003000>;
};

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
storage_partition: partition@fc000 {
label = "storage";
reg = <0x000fc000 0x00004000>;
};
#endif
};
};

That means some part of scratch partition will get utilize ( 12 KB) for #NVS storage.
After this I've to set #define NVS_STORAGE_OFFSET 0xF9000

Is it correct strategy to save App level data on SoC flash without disturbing
#settings_layer data as well feature of #FOTA ?

Thank You !!


Re: Running Hello World for Dragino-LSN50 on B-L072Z-LRWAN1 Dicovery Board

Erwan Gouriou
 

Sure, would be great to have this LORA board in tree.


On Sat, 22 Sep 2018 at 21:59, seems.deviant <seems.deviant@...> wrote:
After setting everything  in .dts and defconfig, Hello world finally started working.

Thanks for assistance. Do you think its worth creating pull request fwith my changes?


- Aleksandr
21 сент. 2018 г. 11:11 ПП | От: Erwan Gouriou <erwan.gouriou@...> | Сообщение:


Le ven. 21 sept. 2018 à 10:45, <seems.deviant@...> a écrit :

В Чтв, 20/09/2018 в 23:43 +0200, Erwan Gouriou пишет:
> Hi,
>
> Looking to B-L072Z-LRWAN1 user manual, it seems that you can get ST-
> Link VCP using USART2,
> Did you changed the console settings to match this configuration ?
>

In order to answer your question I've inspected the
boards/arm/nucleo_l073rz/nucleo_l073rz_defconfig which has a Virtual
COM Port. And I didn't find any UART-specific configuration
options except for CONFIG_SERIAL, CONFIG_CONSOLE and
CONFIG_UART_CONSOLE that should be specified for a VCP to work
correctly.

You don't have to care about VCP, this is internal to ST-Link chip, just make sure that console is set to uart2(.DTS) and enabled (_defconfig).

Could you point out which options do I need to change/specify?

> Then, fortunately, both boards share the same pin mapping on this
> UART,
> so on this point you should be fine.
>
> Last, one point to check would be the clock settings;
> Dragino uses HSI driven PLL, does this fit with B-L072Z-LRWAN1?
>

Yes, the B-L072Z-LRWAN1 uses the same HSI 16M clock source, that's what
datasheet says.

Great, you should be fine then!

> Cheers
>
>
>
> On Thu, 20 Sep 2018 at 22:16, Aleksandr Makarov <seems.deviant@gmail.
> com> wrote:
> > Hello,
> >
> > I am trying to run Hello World application built for Dragino-LSN50
> > on a
> > B-L072Z-LRWAN1 Dicovery Board. Those two boards both are SM32L0-
> > based
> > and share exactly the same MCU model - SMT32L072CZY.
> >
> > The build process and device flashing work fine, however I can't
> > see a
> > "Hello World!" print on a COM terminal after a reset.
> >
> > A working USART port is the only peripheral I care for now. The
> > USART
> > pin configuration for Dragino LSN50 board should be suitable for
> > L072Z-
> > LRWAN1 as well, though it is not working.
> >
> > Please advice.
> >
> >
> >


Bluetooth: about using of NVS & setting Layer in single App

vikrant8051 <vikrant8051@...>
 

Hi,

I've modified nrf52840_pca10056.dts as follow ......

&flash0 {
    /*
     * For more information, see:
     * http://docs.zephyrproject.org/latest/devices/dts/flash_partitions.html
     */
    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x000000000 0x0000C000>;
        };
        slot0_partition: partition@c000 {
            label = "image-0";
            reg = <0x0000C000 0x000069000>;
        };
        slot1_partition: partition@75000 {
            label = "image-1";
            reg = <0x00075000 0x000069000>;
        };
        scratch_partition: partition@de000 {
            label = "image-scratch";
            reg = <0x000de000 0x0001B000>;
        };

        nvs_partition: partition@f9000 {
            label = "storage";
            reg = <0x000f9000 0x00003000>;
        };


#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@fc000 {
            label = "storage";
            reg = <0x000fc000 0x00004000>;
        };
#endif
    };
};

That means some part of scratch partition will get utilize ( 12 KB) for #NVS storage.
After this I've to set #define NVS_STORAGE_OFFSET 0xF9000

Is it correct strategy to save App level data on SoC flash without disturbing
#settings_layer data as well feature of #FOTA ?

Thank You !!


3021 - 3040 of 8189