Date   

Bluetooth: Mesh: about pending things

vikrant8051 <vikrant8051@...>
 

Hi,
Just for curiosity, need list of pending things/issues (if any) in current Bluetooth Stack to fully satisfy SIG Mesh specification v1.0.

Till when it get entitled as Qualified Bluetooth Mesh stack?

Thank You !!



Re: change clock source #nrf52840

Rodrigo Peixoto <rodrigopex@...>
 

Hi,
You can set the CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y on your prj file. I had the same problem and I've solved that with it.

You can check the link:

Best regards,
Rodrigo Peixoto
Co-founder and Technical advisor

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex




Em sex, 28 de set de 2018 às 15:57, <reverett@...> escreveu:

Hi:
 
I am using a board that has a nrf52840 (Laird BL654 module) on it but has some differences with the nordic development board.
 
I want to change the clock source for the nrf52840 to use the on-chip RC oscillator as its clock source instead of
the external crystal. 
 
How would I go about doing this?

Thanks


change clock source #nrf52840

reverett@...
 

Hi:
 
I am using a board that has a nrf52840 (Laird BL654 module) on it but has some differences with the nordic development board.
 
I want to change the clock source for the nrf52840 to use the on-chip RC oscillator as its clock source instead of
the external crystal. 
 
How would I go about doing this?

Thanks


Re: [Zephyr-devel] 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: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos

Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
 

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: [Zephyr-devel] 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
    ===================================================


#mqtt #mbedtls: MQTT Mbedtls gives SSL- Memory allocation failed #mqtt

Prabhu Vinod, Karthik
 

Hi,

 

I am connecting a SAM_E70 board with a cloud. It connects initially with a TLS handshake and then after 30 secs the connection errors.

 

Error:

--------

I am getting a TLS error : mbedtls_ssl_write gives -0x7f00 ..SSL- Memory allocation failed. Attached is the detailed error log(minicom_error_trace) and the conf file for the sam_e70 board.

 

Look forward to some hints

 

Many Regards,

Karthik Prabhu Vinod

 

Help save the planet by choosing not to use single use plastics. Pick paper, bamboo or metal cutlery and carry your own bag to the grocery store. Every little thing you do makes an impact.


Re: NRF52 : use of NFFS file system

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

  • 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: 6 SERCOM on ATSAMD21G18A as UART

Kumar Gala
 

There isn’t anything in particular in Zephyr that would preclude this working. However you’d need to see if the board is capable of exposing all those UARTs, than get all the pin cfg setup in the code.

Also, it looks like right now we’ve only supported UART on port 0 through port 4. So not sure if that’s enough for your needs.

- k

On Sep 24, 2018, at 8:12 PM, Rodrigo Peixoto <rodrigopex@ayna.tech> wrote:

Hi,
I would like to know if it is possible to use 5 of the 6 SERCOM available on the ATSAMD21G18A as UARTs. Is it?

Any clue on how to do this? The Adafruit Feather M0 Basic Proto board seems to have just one enabled.


Thank you.
Best regards,
Rodrigo Peixoto
Co-founder and Technical advisor

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex



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 <Andrzej.Puzdrowski@...>
 

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

 

 

 

 


6 SERCOM on ATSAMD21G18A as UART

Rodrigo Peixoto <rodrigopex@...>
 

Hi,
I would like to know if it is possible to use 5 of the 6 SERCOM available on the ATSAMD21G18A as UARTs. Is it?

Any clue on how to do this? The Adafruit Feather M0 Basic Proto board seems to have just one enabled. 


Thank you.
Best regards,
Rodrigo Peixoto
Co-founder and Technical advisor

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex



NRF52 : use of NFFS file system

Laurence Pasteau
 

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: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos

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

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

 

Hi,

 

FYI,

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

It has last commit -> ba6763a187a347cfc825a2bece78e7d1ef28772d

 

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

MPU FAULT.

 

Thank You !!

 

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

Hi,

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

 

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

 

 

Thank You !!

 

 




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



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


#bluetoothmesh #nrf52840 strange debug error when using arm-none-eabi-gdb #bluetoothmesh #nrf52840

summer20100514@...
 

Hi guys here, I'm a newbie to Zephyr ble mesh and I have already built and ran the examples provided by zephyr successfully. However, when it comes to debugging the application, there is strange behavior which confused me a lot. I use arm-none-eabi-gdb tool and nrf52840 board, after I load the zephyr.elf file and connect to the gdb server and type continue, errs printed out as follow
[bt] [ERR] radio_event_adv_prepare: assert: '!_radio.ticker_id_prepare' failed
***** Kernel OOPS! *****
Current thread ID = 0x20001d0c
Faulting instruction address = 0x1eed4
Fatal fault in ISR! Spinning...
I try to type continue first and reset the board, seems the application runs well. But what still bothered me a lot is that all breakpoints seem not working as expected, in other words, the breakpoints are all set correctly but the application won't stop. Maybe the root cause is the strange behavior mentioned above?
C:\gnuarmemb>arm-none-eabi-gdb
GNU gdb (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 8.1.0.20180315-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) file "C:/Users/Administrator/Desktop/zephyr.elf"
Reading symbols from C:/Users/Administrator/Desktop/zephyr.elf...done.
(gdb) target remote localhost:2331
Remote debugging using localhost:2331
k_cpu_idle () at C:/Users/Administrator/zephyr/arch/arm/core\cpu_idle.S:135
135             bx lr
(gdb) c
Continuing.
 
Program received signal SIGTRAP, Trace/breakpoint trap.
k_cpu_idle () at C:/Users/Administrator/zephyr/arch/arm/core\cpu_idle.S:135
135             bx lr
(gdb) c
Thanks in advance for any inspirations and suggestions.


Re: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos

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

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

 

Hi,

 

FYI,

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

It has last commit -> ba6763a187a347cfc825a2bece78e7d1ef28772d

 

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

MPU FAULT.

 

Thank You !!

 

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

Hi,

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

 

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

 

 

Thank You !!

 

 




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


Re: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos

vikrant8051 <vikrant8051@...>
 

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

 

Hi,

 

FYI,

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

It has last commit -> ba6763a187a347cfc825a2bece78e7d1ef28772d

 

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

MPU FAULT.

 

Thank You !!

 

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

Hi,

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

 

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

 

 

Thank You !!

 

 




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


Re: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos

vikrant8051 <vikrant8051@...>
 

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

 

Hi,

 

FYI,

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

It has last commit -> ba6763a187a347cfc825a2bece78e7d1ef28772d

 

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

MPU FAULT.

 

Thank You !!

 

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

Hi,

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

 

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

 

 

Thank You !!

 

 




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


Re: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos

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

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

 

Hi,

 

FYI,

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

It has last commit -> ba6763a187a347cfc825a2bece78e7d1ef28772d

 

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

MPU FAULT.

 

Thank You !!

 

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

Hi,

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

 

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

 

 

Thank You !!

 

 




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


Re: [solved] nrf52810 basic blinky example not running

Marcio Montenegro
 

Hi Carles,
Thanks for feedback.After checking hardware and software I find the problem:
The zephyr kernel enables  internal DC/DC regulator.
Using the internal converter is the best option but actually I don't have the external inductors for the DC/DC converter circuit. 
So I ran the ninja menuconfig  and disabled the internal DC/DC.


1501 - 1520 of 2603