devel@lists.zephyrproject.org

NRF52 : use of NFFS file system

Laurence Pasteau

#5141

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

Show quoted text

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

main_test.c

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

Erwan Gouriou

#5140

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 ?

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?

Cheers

Show quoted text

On Thu, 20 Sep 2018 at 22:16, Aleksandr Makarov <seems.deviant@...> 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.

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

Aleksandr Makarov <seems.deviant@...>

#5139

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.

Choosing Tx Buffers in BLE stack

dhguja@gmail.com

#5138

Hello,
I am working on a BLE HID keyboard application using zephyr 1.13.

I was playing around with Tx buffers (specifically Maximum number of pending TX buffers, Number of Tx buffers).
With default buffer settings the characters were transmitted very slowly due to small number of buffers. But as soon as
i increased it to 3 pending buffers and 3 Tx buffers i saw significant improvement in the speed of characters transmitted.
My question is how to choose the buffer values for this?.

The reason is currently i face a compatibility problem with my HID application, where it works fine in Linux, Android, iOS devices
with increased number of buffers, but crashes on windows system. When i debugged the HCI log (from btmon) i saw that with
increased buffers, characters are sent very quickly on the order of 500 us for each character. This causes the data (of 20 characters)
to be transmitted within one or two connection intervals. Maybe this causes some overflow in windows systems. I would like to know
what are the implications of choosing a number of Tx buffers and pending buffers.

It will be helpful if anyone can tell how to choose the number of Tx buffers? or even point to some direction in the BLE specification?

Thank you,
Dhananjay G J

Re: MISRA-C and Zephyr

Flavio Ceolin

#5137

Hi Szymon,

Hello,

I was wondering about where did void casting for functions like memcpy,
memset comes from.
Could commit messages for this point to specific rule?Sure thing ! Next commits I'll add which rule that commits is fixing.
Thanks for pointint it out :)


On 14 September 2018 at 20:46, Flavio Ceolin <flavio.ceolin@intel.com>
wrote:

Hi guys,

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

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

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

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

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

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

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

Regards,
Flavio Ceolin




-- 
pozdrawiam
Szymon K. JancRegards,
Flavio Ceolin

Re: MISRA-C and Zephyr

Szymon Janc

#5136

Hello,

I was wondering about where did void casting for functions like memcpy, memset comes from.

Could commit messages for this point to specific rule?

Show quoted text

On 14 September 2018 at 20:46, Flavio Ceolin <flavio.ceolin@...> wrote:

Hi guys,

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

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

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

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

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

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

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

Regards,
Flavio Ceolin

--

pozdrawiam

Szymon K. Janc

Re: MISRA-C and Zephyr

Reto Schneider <reto@...>

#5135

On 9/17/18 10:48 AM, Jiří Kubias wrote:
I have one practical question regarding MISRA-C standard. Where I can
get the standard as a regular coder? I can buy one for £15 + VAT, but I
dont thing that every body want to buy it.You have to buy it.

Is there any public description of this standard? There are many of us
who never met with MISRA standard.This fairly new publication might help you: https://arxiv.org/abs/1809.00821

Kind regards,
Reto

Re: cmake is not recognizing board variable set in CMakeLists.txt

Marti Bolivar <marti@...>

#5134

On Tue, Sep 18, 2018 at 4:04 AM Sathishkumar Duraisamy
<bewithsathish@gmail.com> wrote:

On Tue, Sep 18, 2018 at 3:29 PM, Sathishkumar Duraisamy <bewithsathish@gmail.com> wrote:

Hi all,

I am Sathishkumar. I am experimenting with zephyr and learning to contribute to it. I am coming form Linux and feels home with kconfig, dts, etc.

As per the application primer, I have set(BOARD qemu_cortex_m3)  in CMakeLists.txt. But cmake complaints :

 BOARD is not being defined on the CMake command-line in the environment or
  by the app.

Are this expected?
It seems set(BOARD qemu_cortex_m3) has to be in the beginning of the file after cmake version. It works.The important thing is it must be set before you include the boilerplate file.

Regards,
Sathishkumar D
https://sathishscripts.ccom

--
Regards,
Sathishkumar D

Re: cmake is not recognizing board variable set in CMakeLists.txt

Sathishkumar Duraisamy <bewithsathish@...>

#5133

On Tue, Sep 18, 2018 at 3:29 PM, Sathishkumar Duraisamy <bewithsathish@...> wrote:

Hi all,

I am Sathishkumar. I am experimenting with zephyr and learning to contribute to it. I am coming form Linux and feels home with kconfig, dts, etc.

As per the application primer, I have set(BOARD qemu_cortex_m3) in CMakeLists.txt. But cmake complaints :

BOARD is not being defined on the CMake command-line in the environment or
by the app.

Are this expected?

It seems set(BOARD qemu_cortex_m3) has to be in the beginning of the file after cmake version. It works.

Regards,
Sathishkumar D
https://sathishscripts.ccom

--

Regards,
Sathishkumar D

cmake is not recognizing board variable set in CMakeLists.txt

Sathishkumar Duraisamy <bewithsathish@...>

#5132

Hi all,

I am Sathishkumar. I am experimenting with zephyr and learning to contribute to it. I am coming form Linux and feels home with kconfig, dts, etc.

As per the application primer, I have set(BOARD qemu_cortex_m3) in CMakeLists.txt. But cmake complaints :

BOARD is not being defined on the CMake command-line in the environment or
by the app.

Are this expected?

Regards,
Sathishkumar D

https://sathishscripts.ccom

Re: MPU fault while testing Bluetooth Mesh Sample demos

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

#5131

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:

Show quoted text

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
===================================================

Re: MPU fault while testing Bluetooth Mesh Sample demos

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

#5130

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:

Show quoted text

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

vikrant8051 <vikrant8051@...>

#5129

Hi Jiri,

After replying to your email, I once again started testing thoroughly.

And yes, once again I got MPU fault.

Regards,

Vikrant

Show quoted text

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: SPI driver development

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

#5128

Hi Vincent,

Im open minded 8-). I have implemented SPI driver with polling - seems to be working fine for moth ways. But configuration stuff need some recheck and only one CS is supported. I have tried to implement the DMA (I can compile it) into my driver but it fails when I bind the DMA - I have received MPU protection fault. Unfortunately there not many examples with DMA so it is not so simply to implement it... In another thread was reported also MPU fault with v1.13 which Im using. But it seems to be fixed in GIT so I have to recheck it again to see if the problem is still there or not. I would like to finish it this week but Im sharing my time with another projects....

I will also try to implement the flash driver - but I didnt started yet.

Regards,

Jiri

2018-09-17 15:07 GMT+02:00 <vincent@...>:

Show quoted text

Hi Jiri,

I'm was planning a SPI driver for the SAM4S and later on the SAMe70.
I have sufficient boards to test the SPI driver, with displays, flash, IMU and transceivers on them to push its boundries. I can add the IRQ and DMA also, as I was using both with another RTOS before.

Perhaps we can combine effort for this.

Kind regards,
Vincent

--

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

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

Re: SPI driver development

Vincent - VLoTech

#5127

Hi Jiri,

I'm was planning a SPI driver for the SAM4S and later on the SAMe70.
I have sufficient boards to test the SPI driver, with displays, flash, IMU and transceivers on them to push its boundries. I can add the IRQ and DMA also, as I was using both with another RTOS before.

Perhaps we can combine effort for this.

Kind regards,
Vincent

Re: MPU fault while testing Bluetooth Mesh Sample demos

vikrant8051 <vikrant8051@...>

#5126

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

Show quoted text

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
===================================================

Looking for new maintainer for RPL

Ravi kumar Veeramally

#5125

Hello,

RPL (mesh routing) technology over 802.15.4 has been supported in Zephyr
from the beginning. Originally it was taken from Contiki OS and modified
according to Zephyr network buffer management.

While developing sample RPL applications like rpl_border_router and
rpl_node, we fixed various issues in RPL base code. No new RPL features
nor bug fixes from upstream Contiki have been merged after that.

Upstream Contiki has continued development and is now quite far from
Zephyr RPL implementation. For example Contiki supports non-storing mode
which Zephyr does not support.

There is a lot of re-engineering work going on in Zephyr network stack
right now. Like network buffer changes and socket based support for
application level protocols.

Due to on-going efforts for network stack re-engineering, RPL needs also
modifications. At our side, current priorities are are different from
supporting WPAN family of IoT enablers.

Therefore, we are seeking new maintainers and stakeholders to support
RPL in Zephyr. If no new maintainers are found, the current plan is to
deprecate RPL code in near future.

Thanks in advance,
Ravi.

sensor.h "error: invalid conversion from ..."

Paul ADAM <paul.adam@...>

#5124

Hello,
when I am compiling sensor.h in a cpp file, I have following error 5 times:

/home/.../zephyr/include/sensor.h: In function ‘int sensor_trigger_set(device*, sensor_trigger*, sensor_trigger_handler_t)’:
/home/.../zephyr/include/sensor.h:339:45: error: invalid conversion from ‘const void*’ to ‘const sensor_driver_api*’ [-fpermissive]
  const struct sensor_driver_api *api = dev->driver_api;
                                        ~~~~~^~~~~~~~~~

The solution (if I do not want to let the compiler be more permissive) is to change the code like this:

    const struct sensor_driver_api *api = ( const struct sensor_driver_api * ) dev->driver_api;

What do you think about? Is there another solution?
Someone told me that this is required by MISRA-C standard. Do you confirm?
Should I do a git pull request? Or can someone modify the code in the repository?

Best regards
Paul

Re: sensor.h "error: invalid conversion from ..."

Mark Ruvald Pedersen (MPED)

#5123

FYI, Zephyr is not MISRA-C compliant as Zephyr currently uses several GNU C extensions.

Some little work is ongoing to at least make Zephyr more C99 compliant.

MISRA-C Rule 1 (required): "All code shall conform to ISO 9899 standard C, with no extensions permitted."

Regards, Mark

Show quoted text

From: devel@... [devel@...] on behalf of Paul ADAM [paul.adam@...]
Sent: Monday, September 17, 2018 11:18
To: Zephyr-devel@...
Subject: [Zephyr-devel] sensor.h "error: invalid conversion from ..."

Hello,
when I am compiling sensor.h in a cpp file, I have following error 5 times:

/home/.../zephyr/include/sensor.h: In function ‘int sensor_trigger_set(device*, sensor_trigger*, sensor_trigger_handler_t)’:/home/.../zephyr/include/sensor.h:339:45: error: invalid conversion from ‘const void*’ to ‘const sensor_driver_api*’ [-fpermissive] const struct sensor_driver_api *api = dev->driver_api; ~~~~~^~~~~~~~~~
The solution (if I do not want to let the compiler be more permissive) is to change the code like this:

const struct sensor_driver_api *api = ( const struct sensor_driver_api * ) dev->driver_api;
What do you think about? Is there another solution?
I was told that this explicit conversion is required by MISRA-C standard. Do you confirm?
Should I do a git pull request? Or can someone modify the code in the repository?

Best regards
Paul

sensor.h "error: invalid conversion from ..."

Paul ADAM <paul.adam@...>

#5122

Hello,
when I am compiling sensor.h in a cpp file, I have following error 5 times:

/home/.../zephyr/include/sensor.h: In function ‘int sensor_trigger_set(device*, sensor_trigger*, sensor_trigger_handler_t)’:/home/.../zephyr/include/sensor.h:339:45: error: invalid conversion from ‘const void*’ to ‘const sensor_driver_api*’ [-fpermissive] const struct sensor_driver_api *api = dev->driver_api; ~~~~~^~~~~~~~~~
The solution (if I do not want to let the compiler be more permissive) is to change the code like this:

const struct sensor_driver_api *api = ( const struct sensor_driver_api * ) dev->driver_api;
What do you think about? Is there another solution?
I was told that this explicit conversion is required by MISRA-C standard. Do you confirm?
Should I do a git pull request? Or can someone modify the code in the repository?

Best regards
Paul