Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STM32F4 - Add STORAGE driver #2556

Closed
wants to merge 3 commits into from
Closed

Conversation

svastm
Copy link
Contributor

@svastm svastm commented Aug 26, 2016

This is a work in progress, please do not merge.

This PR add a first implementation of STORAGE feature for STM32F4 targets.

For now, only the synchronous version pass the tests.

Concern for now :

  • NUCLEO_F429ZI
  • DISCO_F429ZI
  • DISCO_F469NI

TODO:

  • syncronous version
  • asyncronous version
  • port on smaller targets

There is still some points not very clear to me.


Flash Size

Compare to the K64F, the flash on STM32F4 targets is divided in big sectors. example for a 1MB flash :

+----------------------+ <--- 0x08000000
|  Sector 0  |  16kB   |
+----------------------+
|  Sector 1  |  16kB   |
+----------------------+
|  Sector 2  |  16kB   |
+----------------------+
|  Sector 3  |  16kB   |
+----------------------+
|  Sector 4  |  64kB   |
+----------------------+
|  Sector 5  |  128kB  |
+----------------------+
|  Sector 6  |  128kB  |
+----------------------+
|    ...     |  ...    |
+----------------------+
|  Sector 11 |  128kB  |
+----------------------+ <--- 0x08100000

Usually the firmware is stored at the beginning of the flash and the storage at the end. That mean the cfstorage use sectors of 128kB (= ERASE_UNIT). If the space needed by cfstorage does not exceed 64kB (no FOTA ?) we could put the cfstorage in the sectors 0 to 3 and the firmware after that ? It would reduce ERASE_UNIT to 16kB.

So my question is, is it mandatory to support a big cfstorage size ? Is it meant to be a file system or only to be used to store configurations ? What size should we usually keep for firmware ?

Test timeout

I tried features-storage-feature_storage-tests-flash_journal-basicapi but it looks like greentea put a 60s timeout on test suite. Also the test pass if it is split in two parts. I did not find a way to change timeout so maybe we should consider to split the test ?

Asynchronous

If the asynch mode is used, who is responsible for checking that no command is ongoing before starting a new one ? I have added a wait before read(), program_data() and erase() but it should be handle higher right ? For now, this is not handle in the tests so i think i missed something.


Tests

  • Synchronous

    • ARM
    +-------------------+---------------+----------------------------------------------------------+--------+--------------------+-------------+
    | target            | platform_name | test suite                                               | result | elapsed_time (sec) | copy_method |
    +-------------------+---------------+----------------------------------------------------------+--------+--------------------+-------------+
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-add_del   | OK     | 24.73              | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-close     | OK     | 13.87              | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-create    | OK     | 17.49              | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-dump      | OK     | 19.16              | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-example1  | OK     | 9.37               | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-example2  | OK     | 13.62              | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-example3  | OK     | 15.95              | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-example4  | OK     | 9.45               | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-example5  | OK     | 9.39               | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-find      | OK     | 15.74              | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-find2     | OK     | 13.75              | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-flash     | OK     | 14.83              | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-flash_set | OK     | 10.53              | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-flush     | OK     | 8.78               | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-flush2    | OK     | 15.8               | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-flush3    | OK     | 9.7                | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-init      | OK     | 13.89              | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-misc      | OK     | 15.46              | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-open      | OK     | 17.67              | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-read      | OK     | 14.54              | shell       |
    | NUCLEO_F429ZI-ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-write     | OK     | 14.32              | shell       |
    +-------------------+---------------+----------------------------------------------------------+--------+--------------------+-------------+
    
    • GCC_ARM
    +-----------------------+---------------+----------------------------------------------------------+---------+--------------------+-------------+
    | target                | platform_name | test suite                                               | result  | elapsed_time (sec) | copy_method |
    +-----------------------+---------------+----------------------------------------------------------+---------+--------------------+-------------+
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-add_del   | OK      | 25.67              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-close     | OK      | 14.84              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-create    | OK      | 18.59              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-dump      | OK      | 20.13              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-example1  | OK      | 17.12              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-example2  | OK      | 14.52              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-example3  | OK      | 17.32              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-example4  | OK      | 10.31              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-example5  | OK      | 10.24              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-find      | OK      | 16.5               | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-find2     | OK      | 14.56              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-flash     | OK      | 15.85              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-flash_set | OK      | 11.38              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-flush     | TIMEOUT | 69.73              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-flush2    | OK      | 16.74              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-flush3    | OK      | 10.21              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-init      | OK      | 14.75              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-misc      | OK      | 16.38              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-open      | OK      | 18.53              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-read      | OK      | 15.33              | shell       |
    | NUCLEO_F429ZI-GCC_ARM | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-write     | OK      | 15.22              | shell       |
    +-----------------------+---------------+----------------------------------------------------------+---------+--------------------+-------------+
    
    • IAR
    +-------------------+---------------+----------------------------------------------------------+--------+--------------------+-------------+
    | target            | platform_name | test suite                                               | result | elapsed_time (sec) | copy_method |
    +-------------------+---------------+----------------------------------------------------------+--------+--------------------+-------------+
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-add_del   | OK     | 24.8               | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-close     | OK     | 13.92              | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-create    | OK     | 17.7               | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-dump      | OK     | 19.24              | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-example1  | OK     | 8.91               | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-example2  | OK     | 13.78              | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-example3  | OK     | 16.05              | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-example4  | OK     | 9.4                | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-example5  | OK     | 9.47               | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-find      | OK     | 15.67              | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-find2     | OK     | 13.86              | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-flash     | OK     | 15.16              | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-flash_set | OK     | 10.54              | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-flush     | OK     | 8.82               | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-flush2    | OK     | 15.88              | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-flush3    | OK     | 9.4                | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-init      | OK     | 13.81              | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-misc      | OK     | 15.32              | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-open      | OK     | 17.93              | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-read      | OK     | 14.62              | shell       |
    | NUCLEO_F429ZI-IAR | NUCLEO_F429ZI | features-storage-feature_storage-tests-cfstore-write     | OK     | 14.26              | shell       |
    +-------------------+---------------+----------------------------------------------------------+--------+--------------------+-------------+
    

Results

The features-storage-feature_storage-tests-cfstore-flush fail only on GCC_ARM because the test suite is specific to this toolchain ? I don't know why. The test failed is named cfstore_flush_test_02_k64f.

@svastm
Copy link
Contributor Author

svastm commented Aug 31, 2016

@0xc0170 @screamerbg Do you know any people who can be interested in this PR ?

@svastm
Copy link
Contributor Author

svastm commented Sep 8, 2016

Any news ?

"detect_code": ["0796"],
"features": ["IPV4"],
"features": ["IPV4", "STORAGE"],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Storage is not a feature

@sg-
Copy link
Contributor

sg- commented Sep 8, 2016

@svastm well have a look.

@rgrover

@svastm
Copy link
Contributor Author

svastm commented Sep 9, 2016

Storage is not a feature

The storage is in the features folder. If I remove "STORAGE" from the features field, I have only access to the storage_abstraction tests (and not the cfstore/flash-journal ones).
I didn't checked in detail the way the features are linked but from my point of view, the "STORAGE" in device_has field mean The device is able to store things in non volatile memory and the "STORAGE" in features field mean you can use cfstore on this target, with volatile or non volatile memory. Also, the implementation on K64F define the "STORAGE" in both fields.

@sg-
Copy link
Contributor

sg- commented Sep 9, 2016

CFStore and its use on internal storage/journal is under discussion. For now its best to get this working not worrying about those. The hal API may also change so please beware.

@marcuschangarm
Copy link
Contributor

I'm very interested in seeing this PR go into mbed-os.

@svastm do you have all the information you need to proceed?

@rgrover
Copy link
Contributor

rgrover commented Sep 15, 2016

Thanks for submitting Storage implementations.

So my question is, is it mandatory to support a big cfstorage size ? Is it meant to be a file system or only to be used to store configurations ? What size should we usually keep for firmware ?

It is not mandatory to support a large cf-store. cf-store isn't meant to be a filesystem; it is meant as a small persistent dictionary of key-value pairs. It is up to the application to choose a size for its config-store; failing which, the system designer/porter should provide a reasonable default.
@simonqhughes may be able to comment more on this.

I tried features-storage-feature_storage-tests-flash_journal-basicapi but it looks like greentea put a 60s timeout on test suite. Also the test pass if it is split in two parts. I did not find a way to change timeout so maybe we should consider to split the test ?

It is OK to split the test specification in order to allow time for the tests to pass. Perhaps there's too much bundled into basicAPI to fit within 60 seconds on all platforms. But there is some value in bundling API testing together, and I'd rather raise the 60-second limit to something which allows tests to run to completion on the ST platforms:

update the following within greentea_setup() as appropriate and include that into your pull request:

GREENTEA_SETUP(60, "default_auto");

Will 120 seconds suffice?

If the asynch mode is used, who is responsible for checking that no command is ongoing before starting a new one ? I have added a wait before read(), program_data() and erase() but it should be handle higher right ? For now, this is not handle in the tests so i think i missed something.

The Storage driver works under the assumption that only one command can be active at a time.

All data-oriented commands (i.e. commands with result in hardware interaction) may return ARM_DRIVER_ERROR_BUSY if another operation is currently pending. Refer to the following recurring idiom within the K64F flash driver:

    if (controllerCurrentlyBusy()) {
        /* The user cannot initiate any further FTFE commands until notified that the
         * current command has completed.*/
        return (int32_t)ARM_DRIVER_ERROR_BUSY;
    }

Such a check (resulting in a return) is made very early during command validation to avoid affecting existing operations.

Higher layers may also introduce synchronization to serialize access to Storage.

Copy link
Contributor

@rgrover rgrover left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please implement the storage driver to cover all of internal flash; not just a space that would be expected to hold the config-store.

Please combine sectors into ARM_STORAGE_BLOCKs.

Please consider implementing optimizations for double-word access.

My quick reading uncovered some minor bugs; please address that.

#endif

#include <stdint.h>
#include "flash-journal-strategy-sequential/config.h"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is no need to depend on the flash-journal. Furthermore, this particular file doesn't exist any longer (or is in the process of getting obsoleted by one of the pull requests).

#include <stdint.h>
#include "flash-journal-strategy-sequential/config.h"

#define ERASE_UNIT (128 * 1024) /* Max size of a sector (in bytes) */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the case of ST micros, it doesn't make sense to have a single ERASE_UNIT (since this varies over the storage)

#define OPTIMAL_PROGRAM_UNIT (0) /* Not used, we are flashing bytes */

/* Size of the flash block */
#define BLOCK_SIZE (SEQUENTIAL_FLASH_JOURNAL_MAX_LOGGED_BLOBS * ERASE_UNIT)
Copy link
Contributor

@rgrover rgrover Sep 15, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

likewise, there is no one single BLOCK_SIZE. Particularly, this has nothing to do with the flash-journal.

#define BLOCK_SIZE (SEQUENTIAL_FLASH_JOURNAL_MAX_LOGGED_BLOBS * ERASE_UNIT)

/* Address of the flash block */
#define BLOCK_ADDR (FLASH_TOP_ADDR - BLOCK_SIZE)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this value doesn't make sense. It seems like you're setting aside one config-store partition equivalent to SEQUENTIAL_FLASH_JOURNAL_MAX_LOGGED_BLOBS units of 128K at the end of flash. This sort of thing shouldn't contaminate a generic Storage implementation.


#include "storage_driver_info.h"

const flash_sector_info_t flash_sector_info_table[] = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be better to model this as an array of ARM_STORAGE_BLOCK; multiple 'sectors' with identical attributes can be combined into a single ARM_STORAGE_BLOCK. So instead of having 4 entries of 16K sectors, it may be better to have a single ARM_STORAGE_BLOCK with a 16k erase-unit.

EraseInitStruct.NbSectors = nb_sectors;

if (capabilities.asynchronous_ops == 0) {

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove un-necessary blank line


context->command = ARM_STORAGE_OPERATION_ERASE;

int8_t base_sector = -1;
Copy link
Contributor

@rgrover rgrover Sep 15, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this paragraph of code needs re-implementation based on ARM_STORAGE_BLOCK, not sectors.

/* Synchronous programming */
HAL_FLASH_Unlock();
for (uint64_t i = 0; i < size; i++) {
if (HAL_FLASH_Program(FLASH_TYPEPROGRAM_BYTE, (uint32_t)(i + addr), ((const uint8_t *)data)[i]) != HAL_OK) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doing I/O one byte at a time is going to be inefficient.

static const ARM_STORAGE_INFO informations = {
.total_storage = BLOCK_SIZE,
.program_unit = PROGRAM_UNIT,
.optimal_program_unit = OPTIMAL_PROGRAM_UNIT,
Copy link
Contributor

@rgrover rgrover Sep 15, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the optimal program unit for this family of ST micros would be a double-word--i.e. 8 bytes. It seems you don't want to offer that optimization at this stage.

#define ERASE_UNIT (128 * 1024) /* Max size of a sector (in bytes) */
#define FLASH_TOP_ADDR (0x8200000UL) /* Top of the flash address */
#define PROGRAM_UNIT (8UL) /* Program alignement (8 bytes) */
#define OPTIMAL_PROGRAM_UNIT (0) /* Not used, we are flashing bytes */
Copy link
Contributor

@rgrover rgrover Sep 15, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this could be as large as a double-word. That would be good for performance and energy-consumption.

@svastm svastm force-pushed the storage_f4 branch 2 times, most recently from 5a77ab8 to b2b440c Compare September 20, 2016 09:23
@svastm
Copy link
Contributor Author

svastm commented Sep 20, 2016

Thank you for the complete answers. Also I focus now this PR on storage driver and forget about cfstorage.

Please combine sectors into ARM_STORAGE_BLOCKs.

Done. My sector_table was a copy of this struct.

Please implement the storage driver to cover all of internal flash; not just a space that would be expected to hold the config-store.

This can be done but the storage_abstraction-basicAPI test use the first block to test erase and program. Also during the test the firmware will be delete if we include it in the storage area. So for now the blocks do not cover the total flash.

Please consider implementing optimizations for double-word access.

The voltages of the NUCLEO boards allow only a word size programming but I did the change.

Tests

  • Synch
+------------------+---------------+--------------------------------------------+------------------------------------------+--------+--------+--------+--------------------+
| target           | platform_name | test suite                                 | test case                                | passed | failed | result | elapsed_time (sec) |
+------------------+---------------+--------------------------------------------+------------------------------------------+--------+--------+--------+--------------------+
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase all                                | 1      | 0      | OK     | 0.12               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase eight units                        | 2      | 0      | OK     | 0.15               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase four units                         | 3      | 0      | OK     | 0.16               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase single unit                        | 5      | 0      | OK     | 0.37               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase two units                          | 4      | 0      | OK     | 0.15               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase with invalid parameters            | 1      | 0      | OK     | 0.06               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | get capabilities                         | 1      | 0      | OK     | 0.05               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | get info                                 | 1      | 0      | OK     | 0.03               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | get version                              | 1      | 0      | OK     | 0.04               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | initialize                               | 3      | 0      | OK     | 0.08               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | power control                            | 2      | 0      | OK     | 0.09               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data using optimal_program_unit  | 5      | 0      | OK     | 0.48               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data using program_unit          | 5      | 0      | OK     | 0.42               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data with invalid parameters     | 1      | 0      | OK     | 0.07               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data with multiple program units | 2      | 0      | OK     | 0.5                |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | read data                                | 5      | 0      | OK     | 0.08               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | uninitialize                             | 3      | 0      | OK     | 0.08               |
+------------------+---------------+--------------------------------------------+------------------------------------------+--------+--------+--------+--------------------+
  • Asynch
+------------------+---------------+--------------------------------------------+------------------------------------------+--------+--------+--------+--------------------+
| target           | platform_name | test suite                                 | test case                                | passed | failed | result | elapsed_time (sec) |
+------------------+---------------+--------------------------------------------+------------------------------------------+--------+--------+--------+--------------------+
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase all                                | 1      | 0      | OK     | 0.12               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase eight units                        | 2      | 0      | OK     | 0.16               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase four units                         | 3      | 0      | OK     | 0.15               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase single unit                        | 5      | 0      | OK     | 0.32               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase two units                          | 4      | 0      | OK     | 0.15               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase with invalid parameters            | 1      | 0      | OK     | 0.06               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | get capabilities                         | 1      | 0      | OK     | 0.05               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | get info                                 | 1      | 0      | OK     | 0.03               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | get version                              | 1      | 0      | OK     | 0.04               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | initialize                               | 3      | 0      | OK     | 0.08               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | power control                            | 2      | 0      | OK     | 0.08               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data using optimal_program_unit  | 5      | 0      | OK     | 0.36               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data using program_unit          | 5      | 0      | OK     | 0.35               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data with invalid parameters     | 1      | 0      | OK     | 0.07               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data with multiple program units | 2      | 0      | OK     | 0.38               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | read data                                | 5      | 0      | OK     | 0.07               |
| DISCO_F469NI-ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | uninitialize                             | 3      | 0      | OK     | 0.08               |
+------------------+---------------+--------------------------------------------+------------------------------------------+--------+--------+--------+--------------------+
+----------------------+---------------+--------------------------------------------+------------------------------------------+--------+--------+--------+--------------------+
| target               | platform_name | test suite                                 | test case                                | passed | failed | result | elapsed_time (sec) |
+----------------------+---------------+--------------------------------------------+------------------------------------------+--------+--------+--------+--------------------+
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase all                                | 1      | 0      | OK     | 0.12               |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase eight units                        | 2      | 0      | OK     | 0.15               |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase four units                         | 3      | 0      | OK     | 0.15               |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase single unit                        | 5      | 0      | OK     | 0.41               |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase two units                          | 4      | 0      | OK     | 0.15               |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase with invalid parameters            | 1      | 0      | OK     | 0.06               |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | get capabilities                         | 1      | 0      | OK     | 0.05               |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | get info                                 | 1      | 0      | OK     | 0.04               |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | get version                              | 1      | 0      | OK     | 0.05               |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | initialize                               | 3      | 0      | OK     | 0.08               |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | power control                            | 2      | 0      | OK     | 0.08               |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data using optimal_program_unit  | 5      | 0      | OK     | 0.47               |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data using program_unit          | 5      | 0      | OK     | 0.4                |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data with invalid parameters     | 1      | 0      | OK     | 0.06               |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data with multiple program units | 2      | 0      | OK     | 0.51               |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | read data                                | 5      | 0      | OK     | 0.08               |
| DISCO_F469NI-GCC_ARM | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | uninitialize                             | 3      | 0      | OK     | 0.08               |
+----------------------+---------------+--------------------------------------------+------------------------------------------+--------+--------+--------+--------------------+
+------------------+---------------+--------------------------------------------+------------------------------------------+--------+--------+--------+--------------------+
| target           | platform_name | test suite                                 | test case                                | passed | failed | result | elapsed_time (sec) |
+------------------+---------------+--------------------------------------------+------------------------------------------+--------+--------+--------+--------------------+
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase all                                | 1      | 0      | OK     | 0.12               |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase eight units                        | 2      | 0      | OK     | 0.15               |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase four units                         | 3      | 0      | OK     | 0.16               |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase single unit                        | 5      | 0      | OK     | 0.4                |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase two units                          | 4      | 0      | OK     | 0.15               |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | erase with invalid parameters            | 1      | 0      | OK     | 0.06               |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | get capabilities                         | 1      | 0      | OK     | 0.04               |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | get info                                 | 1      | 0      | OK     | 0.03               |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | get version                              | 1      | 0      | OK     | 0.05               |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | initialize                               | 3      | 0      | OK     | 0.08               |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | power control                            | 2      | 0      | OK     | 0.08               |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data using optimal_program_unit  | 5      | 0      | OK     | 0.47               |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data using program_unit          | 5      | 0      | OK     | 0.39               |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data with invalid parameters     | 1      | 0      | OK     | 0.07               |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | program data with multiple program units | 2      | 0      | OK     | 0.5                |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | read data                                | 5      | 0      | OK     | 0.07               |
| DISCO_F469NI-IAR | DISCO_F469NI  | mbed-os-tests-storage_abstraction-basicapi | uninitialize                             | 3      | 0      | OK     | 0.08               |
+------------------+---------------+--------------------------------------------+------------------------------------------+--------+--------+--------+--------------------+

Copy link
Contributor

@rgrover rgrover left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Much better. Thanks. We're nearly there.

#define FLASH_INFO_H

/* Total size reserved for the storage */
#define FLASH_INFO_TOTAL_STORAGE (0x00100000)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1MB is the total storage, isn't it. You've correctly pointed out that if the entire internal flash is covered by Storage then the tests might inadvertently overwrite/erase portions of the test-application.
Perhaps this 'TOTAL_STORAGE' (together with start address) could be configuration variable(s).


static const ARM_STORAGE_INFO informations = {
.total_storage = FLASH_INFO_TOTAL_STORAGE,
.program_unit = 4, /* word (4 bytes) programming */
Copy link
Contributor

@rgrover rgrover Sep 20, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

program_unit can still be 1 byte; that allows finer granularity for updates.

@rgrover
Copy link
Contributor

rgrover commented Sep 20, 2016

Please implement the storage driver to cover all of internal flash; not just a space that would be expected to hold the config-store.

This can be done but the storage_abstraction-basicAPI test use the first block to test erase and program. Also during the test the firmware will be delete if we include it in the storage area. So for now the blocks do not cover the total flash.

Your correct in pointing this out. Perhaps you could have the Storage driver configurable in its start-addr and total-size parameters. By default , these parameters could be set to span the second half of the internal flash space.

Please consider implementing optimizations for double-word access.

The voltages of the NUCLEO boards allow only a word size programming but I did the change.

Thanks for making this effort. Could you take a small additional step of allowing program_unit as low as 1 byte? Word access should still be possible and indicated by setting optimal_program_unit as 4.

The program() operation should internally switch to word sized updates for write sequences larger than a word.

@svastm
Copy link
Contributor Author

svastm commented Sep 21, 2016

Your correct in pointing this out. Perhaps you could have the Storage driver configurable in its start-addr and total-size parameters. By default , these parameters could be set to span the second half of the internal flash space.

Is there something in the API to do it ? For now, the interface give information about the size but to know where the start address of the storage is we have to use getBlock(). It is not a good solution when you have more than one block. We could provide a way to know where the begin of storage is to the user and let him decide where he wants to flash.

Thanks for making this effort. Could you take a small additional step of allowing program_unit as low as 1 byte? Word access should still be possible and indicated by setting optimal_program_unit as 4.

it would be a good optimization. Unfortunately the test of programData() require a 4 bytes aligned program_unit. The test might be wrong here ?

// line 381 of storage_abstraction/basicAPI.cpp
size_t sizeofData = info.program_unit;
TEST_ASSERT(BUFFER_SIZE >= sizeofData);
TEST_ASSERT((sizeofData % sizeof(uint32_t)) == 0);
for (size_t index = 0; index < sizeofData / sizeof(uint32_t); index++) {
    ((uint32_t *)buffer)[index] = BYTE_PATTERN;
}

@rgrover
Copy link
Contributor

rgrover commented Sep 21, 2016

Your correct in pointing this out. Perhaps you could have the Storage driver configurable in its start-addr and total-size parameters. By default , these parameters could be set to span the second half of the internal flash space.

Is there something in the API to do it ?

Here's an example of how the start addr is set for the K64F storage driver. This is a configuration variable which can be tweaked at compile time. You could arbitrarily start midway from the flash, and range until the end.

This approach works with the K64F because all sectors come in the same size. It may not work as nicely with STM32, where sector sizes increase exponentially.

What you could do is to have a smart GetBlock() which knows the full block-map, but also knows a start-address from which to hand out blocks. For instance, if the user-configurable start-address is halfway through the range of internal flash, the first block returned by GetBlock() would be adjusted start start at that address.

Thanks for making this effort. Could you take a small additional step of allowing program_unit as low as 1 byte? Word access should still be possible and indicated by setting optimal_program_unit as 4.

it would be a good optimization. Unfortunately the test of programData() require a 4 bytes aligned program_unit. The test might be wrong here ?

Yes, the test (as you pointed out) places an arbitrary requirement upon program_unit being at least 4 bytes. This is un-necessary. I'm happy for you to replace

static const uint32_t BYTE_PATTERN = 0xAA551122;

(line 378) with

static const uint8_t BYTE_PATTERN = 0xAA;

and subsequently replace uint32_t with uint8_t. It makes for a weaker test to relax the 4-byte pattern into a 1-byte pattern, but it allows for smaller program_units, which is more valuable.

@svastm svastm force-pushed the storage_f4 branch 2 times, most recently from c5d3e3e to 1777440 Compare September 26, 2016 13:37
@svastm
Copy link
Contributor Author

svastm commented Sep 26, 2016

What you could do is to have a smart GetBlock() which knows the full block-map, but also knows a start-address from which to hand out blocks. For instance, if the user-configurable start-address is halfway through the range of internal flash, the first block returned by GetBlock() would be adjusted start start at that address.

The new getNextBlock(NULL, &block); return now the first block of the storage. The start of the storage is defined by STORAGE_START_SECTOR. If the macro == 0, the storage cover all the flash.

using namespace utest::v1;

#if defined(TARGET_K64F)
extern ARM_DRIVER_STORAGE ARM_Driver_Storage_MTD_K64F;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@simonqhughes Is this renamed by accident ?

@marcuschangarm
Copy link
Contributor

Usually the firmware is stored at the beginning of the flash and the storage at the end. That mean the cfstorage use sectors of 128kB (= ERASE_UNIT). If the space needed by cfstorage does not exceed 64kB (no FOTA ?) we could put the cfstorage in the sectors 0 to 3 and the firmware after that ? It would reduce ERASE_UNIT to 16kB.

Hi @svastm, I'm curious how you would put the cfstorage in sectors 0 to 3? I thought your bootloader expects the firmware to start in either sector 1 or 2? Or am I reading application note AN2606 wrong?

Also, I see the PR passes all checks now. Do you feel it is feature complete or should I wait a bit before using it?

Thanks!

@svastm
Copy link
Contributor Author

svastm commented Sep 27, 2016

@marcuschangarm it was just an idea but you are right; it wouldn't be as easy as I expected and we wouldn't be able to store data in sector 0.

As @sg- pointed out, the API may change so I see this PR more like a first implementation. You should maybe wait for the deployment over all the ST families to use it.

@marcuschangarm
Copy link
Contributor

@svastm @simonqhughes @rgrover @0xc0170 @sg- @simonfordarm

How close is this PR to be good enough for the three boards in question?

Can we make a push for getting this into the 5.2 release, please?

Copy link
Contributor

@rgrover rgrover left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@simonqhughes, @marcuschangarm : This pull request tries to introduce a config-variable STORAGE_START_SECTOR to define the boundary of the storage space to be managed by the underlying Storage driver. There are two things to consider here:

  • Is this a reasonable config variable that we'll support? Does this fit with our general design of Storage/Config-store?
  • Is sector-count the correct unit for this variable? An alternative could be start-address.

Please comment.

const ARM_STORAGE_BLOCK *iter = &block_table[0];
uint8_t sector = 0;
for (size_t index = 0; index < block_table_size; ++index, ++iter) {
if (sector < STORAGE_START_SECTOR) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the expression in this check is incorrect. It should be:

if ((sector + (iter->size / iter->attributes.erase_unit) <= STORAGE_START_SECTOR) {

Please reconsider.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand. Does it change the behavior of the loop ?

Copy link
Contributor

@rgrover rgrover Sep 29, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the loop has a bug as you've coded it. Imagine that the first block has 2 sectors and STORAGE_START_SECTOR is set to 1; in this case, the loop should terminate at the first block. And in this case, the start_addr of the returned BLOCK should also be adjusted to start at 1 * sector_size; that's missing too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the example. I forgot the mention that the STORAGE_START_SECTOR have to correspond to the start of a block. It's also required by the erase function. Should we allow STORAGE_START_SECTOR to be non block aligned ? If not, I will add some docs in the storage_driver_info.h

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if STORAGE_START_SECTOR is the correct abstraction to use in this case. I've posted a question to solicit input on this. It may be that STORAGE_START_SECTOR should remain as 0, and therefore implicit, and we use the storage-volume-manager to arbitrate access to partitions within a Storage driver.
I'm hoping @simonqhughes, @marcuschangarm and @sg- would be able to provide input and drive a consensus.

break;
}
}
return ARM_DRIVER_OK;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please note that it is valid to call GetNextBlock(NULL, NULL), if the caller is only interested in establishing the existence of a storage Block. In your code, calling GetNextBlock(NULL, NULL) will return ARM_DRIVER_OK without checking (block_table_size > 1).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right. I'm changing this.

Copy link
Contributor

@rgrover rgrover left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please provide more explanation for your changes to the tests around timeouts.

extern ARM_DRIVER_STORAGE ARM_Driver_Storage_MTD_K64F;
ARM_DRIVER_STORAGE *drv = &ARM_Driver_Storage_MTD_K64F;
#else
extern ARM_DRIVER_STORAGE ARM_Driver_Storage_(0);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not use ARM_Driver_Storage_(0); it is too generic, and could lead to name-clashes when supporting more than one Storage devices concurrently.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok so I rename the ST one in ARM_Driver_Storage_MTD_STM32

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks

@@ -371,17 +377,16 @@ control_t test_programDataUsingProgramUnit(const size_t call_count)
TEST_ASSERT(rc >= 0);
if (rc == ARM_DRIVER_OK) {
TEST_ASSERT_EQUAL(1, capabilities.asynchronous_ops);
return (call_count < REPEAT_INSTANCES) ? CaseTimeout(200) + CaseRepeatAll: CaseTimeout(200);
return (call_count < REPEAT_INSTANCES) ? CaseTimeout(ERASE_CASE_TIMEOUT) + CaseRepeatAll: CaseTimeout(ERASE_CASE_TIMEOUT);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You've combined two different things into a single commit. It is better to separate conceptually different changes into distinct commits.

What is the justification for changing the erase Timeouts? Were you hitting this timeout on the ST NVM?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, i changed the erase timeouts because they were hitten. Typical erase time for a 128kB sector on STM32F429ZI is 1s and for a 16kB sector, 0.25 s.

@@ -911,7 +916,7 @@ control_t test_programDataWithMultipleProgramUnits(const size_t call_count)
TEST_ASSERT(rc >= 0);
if (rc == ARM_DRIVER_OK) {
TEST_ASSERT_EQUAL(1, capabilities.asynchronous_ops);
return CaseTimeout(500);
return CaseTimeout(1000);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why has this timeout been changed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one was hitten too. I don't remember the N value but with this timeout the test pass.

@marcuschangarm
Copy link
Contributor

I don't think the functionality provided by STORAGE_START_SECTOR should be part of the driver, but be handled by the Volume Manager, as it is on "other" platforms.

Setting the STORAGE_START_SECTOR to 0 should fix this, right?

@rgrover
Copy link
Contributor

rgrover commented Sep 29, 2016

@marcuschangarm : I agree that the volume manager is better suited for arbitrating access to regions of Storage. In some cases, the Storage driver might want to limit the exposed address-space even further using a config-option like STORAGE_START_SECTOR. Such a 'narrowing' might help avoid RWW (read-while-write issue) completely.

Perhaps @simonqhughes and others would like to comment on what strategy would be suitable for mbedOS.

@svastm svastm force-pushed the storage_f4 branch 2 times, most recently from f6bc620 to 14695d2 Compare September 29, 2016 13:53
@marcuschangarm
Copy link
Contributor

@rgrover I don't think the RWW problem should be handled by limiting the storage drivers access, but by choosing sensible locations for your configuration store and other libraries that uses NVM.

Enable storage driver for the following targets:
 - NUCLEO_F429ZI
 - DISCO_F429ZI
 - DISCO_F469NI
- Increase some timeouts
- Allow program_unit smaller than 4 bytes
@svastm
Copy link
Contributor Author

svastm commented Sep 30, 2016

@adustm

@sg-
Copy link
Contributor

sg- commented Oct 3, 2016

Needs a lot of work as to how drivers are composed and used. This is mainly a problem with not following the mbed C hal rather bringing in a new hal. Not sure the solution ATM but this will not fly and goes against all that we're trying to do.

+#if defined(TARGET_K64F)
  extern ARM_DRIVER_STORAGE ARM_Driver_Storage_MTD_K64F;          extern ARM_DRIVER_STORAGE ARM_Driver_Storage_MTD_K64F;
  ARM_DRIVER_STORAGE *drv = &ARM_Driver_Storage_MTD_K64F;         ARM_DRIVER_STORAGE *drv = &ARM_Driver_Storage_MTD_K64F;
 +#elif defined(TARGET_STM)
 +extern ARM_DRIVER_STORAGE ARM_Driver_Storage_MTD_STM32;
 +ARM_DRIVER_STORAGE *drv = &ARM_Driver_Storage_MTD_STM32;
 +#else
 +extern ARM_DRIVER_STORAGE ARM_Driver_Storage_(0);
 +ARM_DRIVER_STORAGE *drv = &ARM_Driver_Storage_(0);
 +#endif

@adustm
Copy link
Member

adustm commented Nov 24, 2016

Hello @sg-
Did Arm progress on this topic ?
Let us know when you are ready so that we can implement storage for NUCLEO_F429ZI / DISCO_F429ZI and DISCO_F469NI
Kind regards
Armelle

@0xc0170
Copy link
Contributor

0xc0170 commented Mar 20, 2017

@svastm I think this one can be closed? the new replacement is in place.

@adustm
Copy link
Member

adustm commented Mar 23, 2017

Hello @0xc0170
svastm is not in our team anymore, do you have admin rights to close this PR ?
Kind regards
Armelle

@0xc0170 0xc0170 closed this Mar 23, 2017
artokin pushed a commit to artokin/mbed-os that referenced this pull request Jan 22, 2021
…..91f3ff6

91f3ff6 Merge branch 'release_internal' into release_external
3999b6e Iotthd 4495 (ARMmbed#2556)
90c3263 RPL Prefix handling update:
f761409 Close Nanostack v12.8.0 ChangeLog (ARMmbed#2549)

git-subtree-dir: features/nanostack/sal-stack-nanostack
git-subtree-split: 91f3ff6
artokin pushed a commit to artokin/mbed-os that referenced this pull request Apr 20, 2021
…..0903b81

0903b81 Merge remote-tracking branch 'origin/release_internal' into release_external
51429c9 FHSS WS: api function to set TX allowance level (ARMmbed#2612)
01b1188 Fix Child NUD with long ARO registrations
20b49ce Optimize out of memory handler to remove more memory in EF mode
f1b03bc FHSS WS: Allow transmitting unicast frames on broadcast channel for 1st hop node in EF mode (ARMmbed#2609)
2f5e5e2 Generic forwarding callback and EF state enabler for Wi-SUN BBR.
007dfa2 Allow transmitting on RX slot for 1st hop device in expedited forwarding mode (ARMmbed#2607)
6524872 Implemented FHSS expedited forwarding mode (ARMmbed#2606)
91e0b4c QoS traffic class documentation update.
3acd3a4 Fix warnings found by cppcheck (ARMmbed#2605)
d2f5347 MPX and MAC API update
7310cc0 MAC: "CCA fail on RX" event for TX done callback (ARMmbed#2602)
cd109c3 Clear Ack tx and tx process in MAC reset (ARMmbed#2601)
45504fd Optimize stagger based on uptime and startup type
ed5209e Iotthd 4584 (ARMmbed#2599)
60726dc Fixed blacklisting overflow (ARMmbed#2597)
23334b7 Added support for High Priority forward state
3ec2a2c Corrected freed memory access on incoming EAPOL handling
aecadc4 Fixed delayed interrupt (ARMmbed#2596)
1fca2c1 CCA backoffs max to 9 (ARMmbed#2595)
f3d2fa1 Added API function to get neighbor table information from Wi-SUN
3bb089b Validate randomized fixed channel (ARMmbed#2592)
70743a1 MAC stabilisation fixes (ARMmbed#2591)
e936a26 Reduce periodic DNS traces
a45fe3f Improved CSMA-CA logic for Wi-SUN (ARMmbed#2585)
56b7735 improved Wi-SUN stack statistics added
e656190 Wi-SUN neighbour allocate update
799f837 Added address check for Whiteboard address ADD
0b6caa3 Wi-SUN network timing parameter tuning
4921465 Supress warnings
f5cecd7 Enable external connection for routers
e129a0a Added LLC EAPOL temporary neighbor remove when authentication completes (ARMmbed#2583)
fa20fb9 Added calculation of LLC and LLC EAPOL message queue average (ARMmbed#2582)
7f7c01a Added retry traces to authenticator EAP-TLS, 4WH, and GKH
a87646d On startup deletes NVM GTKs if EUI-64 has been changed (ARMmbed#2576)
509a6f9 Add CI commands to PR template (ARMmbed#2579)
eb6a4f7 Change stagger calculation to give more bandwidth to application
82f1d54 Wi-SUN bpptstrap clear destination cache at discovery phase.
71b0588 Destination cache update:
f92c385 Enabled PMTU timeout to destination cache after used.
957b358 DHCP server and Agent relay update
25b9124 Merge remote-tracking branch 'origin/release_internal' into release_external
c825b04 Corrected covery warning on delay_us multiplication
be63bbb Updated changelog
77a76c7 Corrected nw size set on automatic mode
65e6c2d Updated unit tests
16e3402 Added waiting queue to EAPOL authentications to Border Router
b9c0b7d Wi-SUN border router starts faster in static configuration
2f427e1 Local repair start and stop clear advertised_dodag_membership_since_last_repair when state is updated.
0a01ab1 RPL dio send update
dd39963 Wi-SUN Border router uses Static address as DODAGID
7a3c833 Additional check to detect parent connection problem
ffe48c9 WS management: domain configuration functions implemented (ARMmbed#2567)
5e9ac4e Added new Callback to RPL indicate Multicast DIS received from RPL Parent
85b949e Bootstrap and EAPOL treats all MAC TX failure causes similarly
b57d9bc Add support for anonymous addressing in Wi-SUN border router (ARMmbed#2565)
7400c8b CFG: API for PHY mode id and channel plan id get & validate (ARMmbed#2564)
2832fe8 Added Socket reference limitter
890aad1 Wi-SUN MTU size update and IPv6 minium MTU routing skip
3ad28c1 Added throttling of number of simultaneous EAPOL authentications
0b84299 Source route handler call Wi-Sun border router alive function.
c8343b1 Added support for dynamic RPL default lifetime
d258068 Iotthd 4478 (ARMmbed#2560)
7ca6c24 Enable and modify memory limits for packet receiving
e2b028d Close CHANGELOG.md for v12.8.1 (ARMmbed#2557)
91f3ff6 Merge branch 'release_internal' into release_external
3999b6e Iotthd 4495 (ARMmbed#2556)
90c3263 RPL Prefix handling update:
f761409 Close Nanostack v12.8.0 ChangeLog (ARMmbed#2549)
f8ae0e9 Merge remote-tracking branch 'origin/release_internal' into release_external
3275f83 Added support for handle RPL hop by Hop sender rank 0.
d62c589 Activated RPL force tunnel for wi-sun.
3e1064a RPL tunnel force functionality update
3207e5c RPL parent select timer random update from 1.0-1.2 to 1.0-1.5.
bc09cba MAC Ack wait fixed for OFDM (ARMmbed#2552)
5106b1d Fixed unused variable and function warnings.
4096c1a Wi-SUN bootstrap support RPL poison from Connected state to Discovery
66378d1 RPL Poison update

git-subtree-dir: features/nanostack/sal-stack-nanostack
git-subtree-split: 0903b81
artokin pushed a commit to artokin/mbed-os that referenced this pull request Apr 21, 2021
…183d87..0903b81

0903b81 Merge remote-tracking branch 'origin/release_internal' into release_external
51429c9 FHSS WS: api function to set TX allowance level (ARMmbed#2612)
01b1188 Fix Child NUD with long ARO registrations
20b49ce Optimize out of memory handler to remove more memory in EF mode
f1b03bc FHSS WS: Allow transmitting unicast frames on broadcast channel for 1st hop node in EF mode (ARMmbed#2609)
2f5e5e2 Generic forwarding callback and EF state enabler for Wi-SUN BBR.
007dfa2 Allow transmitting on RX slot for 1st hop device in expedited forwarding mode (ARMmbed#2607)
6524872 Implemented FHSS expedited forwarding mode (ARMmbed#2606)
91e0b4c QoS traffic class documentation update.
3acd3a4 Fix warnings found by cppcheck (ARMmbed#2605)
d2f5347 MPX and MAC API update
7310cc0 MAC: "CCA fail on RX" event for TX done callback (ARMmbed#2602)
cd109c3 Clear Ack tx and tx process in MAC reset (ARMmbed#2601)
45504fd Optimize stagger based on uptime and startup type
ed5209e Iotthd 4584 (ARMmbed#2599)
60726dc Fixed blacklisting overflow (ARMmbed#2597)
23334b7 Added support for High Priority forward state
3ec2a2c Corrected freed memory access on incoming EAPOL handling
aecadc4 Fixed delayed interrupt (ARMmbed#2596)
1fca2c1 CCA backoffs max to 9 (ARMmbed#2595)
f3d2fa1 Added API function to get neighbor table information from Wi-SUN
3bb089b Validate randomized fixed channel (ARMmbed#2592)
70743a1 MAC stabilisation fixes (ARMmbed#2591)
e936a26 Reduce periodic DNS traces
a45fe3f Improved CSMA-CA logic for Wi-SUN (ARMmbed#2585)
56b7735 improved Wi-SUN stack statistics added
e656190 Wi-SUN neighbour allocate update
799f837 Added address check for Whiteboard address ADD
0b6caa3 Wi-SUN network timing parameter tuning
4921465 Supress warnings
f5cecd7 Enable external connection for routers
e129a0a Added LLC EAPOL temporary neighbor remove when authentication completes (ARMmbed#2583)
fa20fb9 Added calculation of LLC and LLC EAPOL message queue average (ARMmbed#2582)
7f7c01a Added retry traces to authenticator EAP-TLS, 4WH, and GKH
a87646d On startup deletes NVM GTKs if EUI-64 has been changed (ARMmbed#2576)
509a6f9 Add CI commands to PR template (ARMmbed#2579)
eb6a4f7 Change stagger calculation to give more bandwidth to application
82f1d54 Wi-SUN bpptstrap clear destination cache at discovery phase.
71b0588 Destination cache update:
f92c385 Enabled PMTU timeout to destination cache after used.
957b358 DHCP server and Agent relay update
25b9124 Merge remote-tracking branch 'origin/release_internal' into release_external
c825b04 Corrected covery warning on delay_us multiplication
be63bbb Updated changelog
77a76c7 Corrected nw size set on automatic mode
65e6c2d Updated unit tests
16e3402 Added waiting queue to EAPOL authentications to Border Router
b9c0b7d Wi-SUN border router starts faster in static configuration
2f427e1 Local repair start and stop clear advertised_dodag_membership_since_last_repair when state is updated.
0a01ab1 RPL dio send update
dd39963 Wi-SUN Border router uses Static address as DODAGID
7a3c833 Additional check to detect parent connection problem
ffe48c9 WS management: domain configuration functions implemented (ARMmbed#2567)
5e9ac4e Added new Callback to RPL indicate Multicast DIS received from RPL Parent
85b949e Bootstrap and EAPOL treats all MAC TX failure causes similarly
b57d9bc Add support for anonymous addressing in Wi-SUN border router (ARMmbed#2565)
7400c8b CFG: API for PHY mode id and channel plan id get & validate (ARMmbed#2564)
2832fe8 Added Socket reference limitter
890aad1 Wi-SUN MTU size update and IPv6 minium MTU routing skip
3ad28c1 Added throttling of number of simultaneous EAPOL authentications
0b84299 Source route handler call Wi-Sun border router alive function.
c8343b1 Added support for dynamic RPL default lifetime
d258068 Iotthd 4478 (ARMmbed#2560)
7ca6c24 Enable and modify memory limits for packet receiving
e2b028d Close CHANGELOG.md for v12.8.1 (ARMmbed#2557)
91f3ff6 Merge branch 'release_internal' into release_external
3999b6e Iotthd 4495 (ARMmbed#2556)
90c3263 RPL Prefix handling update:
f761409 Close Nanostack v12.8.0 ChangeLog (ARMmbed#2549)
f8ae0e9 Merge remote-tracking branch 'origin/release_internal' into release_external
3275f83 Added support for handle RPL hop by Hop sender rank 0.
d62c589 Activated RPL force tunnel for wi-sun.
3e1064a RPL tunnel force functionality update
3207e5c RPL parent select timer random update from 1.0-1.2 to 1.0-1.5.
bc09cba MAC Ack wait fixed for OFDM (ARMmbed#2552)
5106b1d Fixed unused variable and function warnings.
4096c1a Wi-SUN bootstrap support RPL poison from Connected state to Discovery
66378d1 RPL Poison update

git-subtree-dir: connectivity/nanostack/sal-stack-nanostack
git-subtree-split: 0903b81
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants