Hi,

If I understand correctly: the  LittleFS partition is configured to start at the 0x080FC000, where you write your data with external tool?

The LitteFS does not recognize the data on partition and formats it for itself, by erasing your data and writing the LittleFS superblock.

Regards,

Dominik

Hi there!

I'm using the Samples/Littlefs with an STM32 EVB without any problems.

I want to save some data files (txt, html, json, etc) in the uC's flash, so I can read them during the code execution.

At this moment I can save the data directly to the memory (starting at 0x080FC000), using external tools, but when I upload the program the data that I have stored previously is overwritten as depicted in the figure.

Is this supposed to happen, or I'm doing something wrong?

Thank you

Hi all,

I'd like to inform STM32   DMA  users  that I'm pushing a change [1] to simplify the definition of the <dma—cells> properties for dma peripherals of the stm32 MCUs.

This change now proposes 3 versions of the dma plus the dmamux in the dts and selects the nb of elements for the <dma-cells>

It depends on the type of DMA instance of the stm32 MCU (from Ref. Man). With this :

DMA V1 : DMA with FIFO control

à the <dma-cells>   has 4 elements : ‘channel’, ‘slot’, ‘channel-config’, ‘feature’

for example on stm32F4 or stm32F2 MCUs

DMA V2 : DMA without FIFO control and selectable request for each channel

à  the <dma-cells>   has 3 elements : : ‘channel’, ‘slot’, ‘channel-config’

for example on stm32L4xx or stm32L0xx MCUs

DMA  V2bis : DMA without FIFO control and fixed request (slot) for each channel

à the <dma-cells>   has 2 elements : : ‘channel’,  ‘channel-config’

 For stm32L1 and stm32F1   MCUs

DMAMUX   multiplexing DMA channels : like a DMA V2

à does not require ‘feature’ parameter

For example on stm32G4 or stm32WB   MCUs

Benefit is to remove unused parameters in the DTS and simply the structure of the dma peripherals.

To declare a new peripheral client of the DMA, the version of the DMA must be first identify, according to the stm32  Ref Manual.

Then the <dma-cells> properties is filled with :

‘channel’ to select a free DMA channel for transfer

‘slot’ to select the peripheral request in DMA V1 or DMA V2 or DMAMUX versions

‘channel-config’,  to configure the dma channel

‘feature’  for configuring the FIFO in DMA V1 versions

This change will be hopefully integrated in the next Zephyr DV that will be released in October ‘21.

Cheers

FRASTM

[1] https://github.com/zephyrproject-rtos/zephyr/pull/34666

Hi Jacob,

Thank you for the response. The issue got resolved now.

Regards,

Srinivasan

From: devel@... <devel@...> On Behalf Of Jacob Avraham
Sent: 26 June 2021 03:56 PM
To: devel@...
Subject: Re: [Zephyr-devel] Use the drivers files from the custom application directory instead of ZEPHYR_BASE

Hi Carl,

Question 1, it is a bug, please feel free to send a pull request.

Question 2, the window widening requires that the packet is listened for earlier that the periodic interval, hence the reduced interval_us. And the window used is twice the window widening value in the lower link layer. Thereafter, the drift is compensated for based on successful anchor point reception. No action required in the implementation.

Regards,

Vinayak

I am having some difficulty establishing and maintaining scan
synchronization to a Periodic Advertising train when the Periodic
Advertising interval is relatively long (e.g. 10+ seconds).

I am using 2 nRF52840 DK boards (v1.1.10 2019.9) and a post-Zephyr
v2.6.0 version (commit #1836f10bb701f2b20f18bc59ec943cc39f57a9fc).

The Advertiser is samples/bluetooth/periodic_adv (with modified
Periodic Advertising interval values of 8000 i.e. 10sec).

The Scanner is samples/bluetooth/periodic_sync

Synchronization works well with shorter intervals (and sometimes
with longer intervals).

I have two questions:

1. In subsys/bluetooth/controller/ll_sw/ull_scan_aux.c
   ull_scan_aux_setup(), should the block:

    if (aux_ptr->ca) {
        window_widening_us = aux_offset_us / 2000U;
    } else {
        window_widening_us = aux_offset_us / 20000U;
    }

be instead:

    if (aux_ptr->ca) {
        window_widening_us = aux_offset_us / 20000U;
    } else {
        window_widening_us = aux_offset_us / 2000U;
    }

The reason being that in the Core Specification 5.2 Vol 6, Part B
2.3.4.5 AuxPtr field, CA value of 0 is 51-500ppm so window widening
should be greater than for CA value of 1, which is 0-50ppm.


2. In subsys/bluetooth/controller/ll_sw/ull_sync.c: ull_sync_setup()
[and perhaps subsys/bluetooth/controller/ll_sw/ull_slave.c:
ull_slave_setup()], should the "remainder_periodic" argument to
ticker_start() equal the interval after window widening?

Currently, the "ticks_periodic" argument to ticker_start() is
computed from:
    interval_us -= lll->window_widening_periodic_us;
(presumably to advance the scan by the window widening amount?)
but "remainder_periodic" is also computed from the same value.

Perhaps:
  "ticks_periodic" = interval_us - lll->window_widening_periodic_us;
  "remainder_periodic" = interval_us + lll->window_widening_periodic_us;


Regards,
Carl