In my opinion Flash driver API hasn’t well-defined common behavior. It could cause additional complexity in component added on top of flash driver because the incompatibility must be deferred at highe

Hi David. Thanks for your answer. Bellow I responds to your comments: I totally agree. Agree on that - driver shouldn’t break hardware specification If hw doesn't allow rewrites then driver shouldn't

It is still possible to assert bit-field implementation (static assert). Then in case of incompatibilities we will have an early porting alarm. This could be done even once for a SoC. Andrzej

Hi. You need to provide description of how to use the description you introduced. Look at https://github.com/zephyrproject-rtos/zephyr/blob/master/dts/common/yaml/partition.yaml For details how BOT pa

Ad 2.) You might also introduce any compiler option using menuconfig: Compile and Link Features > Compiler Options > Custom compiler options. You can for example put here "-O0" for disabling any optim

Hi. I’ve ported boot serial recovery feature which had been originally provided for mynewt targets. Tools needed for create the image and transfer it to the FWU target are the same as for mynewt targe

I’m planning to implement abstraction over flash devices driver similar to this what Mynewt has in flash_mam module. This is using description of different flash areas. Some of this flash areas could

Hi Gene Maybe your mass storage issue is a problem with assigning free disk letter on windows? There are loot of tutorials how to fix this. BR Andrzej

Hi Marti Of course the providing of substitute of flash_area primitives is intermedium step for adding other modules. I will adapt mynewt FCB (Flash Circular Buffer) to zephyr, I will take mynewt Conf

> Well, board configuration is different, different pins are used for LEDs, buttons and UART, but from BLE point of view everything should be the same, correct? Can you check how you configured UART f

Hi. For nRF52840 I2C driver is zephyr. All its option are in general i2c Kconfig file. I attached configuration I had used to compile example you mentioned. BR Andrzej

Hi Tiaga I think you can take good enough Interrupt driven serial adapter form mcuboot repository here: https://github.com/runtimeco/mcuboot/blob/master/boot/zephyr/serial_adapter.c https://github.com

Can you chech whether is it similar to previous mail-list thread topic: NRF5x I2C driver and the sensor/th02 example (on https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-November/thread.htm

NFFS Is supported since 1.10 release: https://www.zephyrproject.org/releases/1-10-release-december-2017/ Andrzej From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...

Add configuration CONFIG_MPU_ALLOW_FLASH_WRITE=y to the project (or select via Kconfig). This should help. Andrzej

> I request Zephyr OS maintainer to create & add following attached main.c under $zephyr_base/samples/boards/nrf52/nffs/src & prj.conf under $zephyr_base/samples/boards/nrf52/nffs/ on Github. Great, s

Hi So you must have supplied nRF52840 from VDDH pin – so it power regulator circuit works in high voltage mode. Then internal regulator generate the GPIO output voltage: You need to set UICR->REGOUT0

I also see that error cods defined in <errno.h> are insufficient. I think definition value-space for module specific codes are good idea in general. But I'm afraid we can go down the road in case we r

Hi. I Think it will be possible – (but can’t be sure). At last Jehudi Maes (the NVS author) is considering right now ho to provide nvs-back-end for the setting (I’m in touch with him). Andrzej

#fcb #nvs #bluetoothmesh

Hi As you notice right now it is impossible to use both NVS and FCB out of the box. So you need a hack. I think finally this problem should be resolved by introduction of dedicate flash slot which are

#nvs #fcb #bluetoothmesh