Date   

USB: Question about usb_write() API

Sundar Subramaniyan
 

Hi,

While developing a USB device controller driver for the Nordic nRF52840 SoC,
I ran into the problem of handling chunked/partial write() while coding the usb_dc_ep_write() function.

From what I could gather, the usb_write() API documentation states that the application calling
this function may choose to write all the data buffer at once even if it is larger than the maximum
packet size supported by the USB endpoint to which we're writing to.
Let's call this method "write all at once".

If the application or the class driver can manage to write in parts, then it must use the "bytes_ret" argument
to know how much data is written on the bus so as to know if there's anymore data remaining to be written in
the subsequent call. Let's call this method "write in parts".

In my case, I'm using bt_usb and it tries to write all at once - i.e. there's no handling of remaining data.
This mandates the USB device controller driver to take care of the writing in parts within the driver itself.
While this can be done in a simple loop if the driver talks synchronously to the USBD HW and do a poll and
a yield or use a semaphore till the HW completes the DMA and there's room to write more.

Here's what bt_usb does:
https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/bluetooth/hci_usb/src/main.c#L665

When I looked at other drivers to see how they are implemented, the designware USB driver seems to assume
the application/class drivers always support the "write in parts" method. I'm not blaming the driver or it's
implementation but I just wanted to point out that there are drivers which do not support handling chunked
write within them.

Here's the DW driver implementation:
https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/usb/device/usb_dc_dw.c#L1004
https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/usb/device/usb_dc_dw.c#L423

Another class driver, netusb does it a little differently by writing in parts, but this too assumes the usb_write()
to be synchronous.

Here's what it does:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/usb/class/netusb/netusb.c#L189

One more thing to consider is the write callbacks. In most cases, the application/class driver is the one that registers
the Bulk/Interrupt endpoint callbacks and the device stack has no way of knowing when to perform the next write, even
if it wants to handle this in the USB device stack.

My question now is, what is the ideal place to take care of truncation and chunk handling as per the USB device stack design?
Why the driver needs to handle the multi-part write and synchronization?

I understand that there are not going to be multiple USBD controllers on a given chip and taking care of this in the
driver won't cost much from memory/CPU cycles point of view but from USB DC driver implementation perspective
this might save a lot of time if the stack can abstract them.

Please let me know your opinions.

Thanks,
Sundar


Re: Saving #BluetoothMesh Provisioning & Configuration related data on flash of nRF52 using NFFS #bluetoothmesh

Vikrant More <vikrant8051@...>
 

After testing I found that it is necessary to add
__attribute__((packed)) after structure defination
Why ??  This will be helpful --> http://www.avabodh.com/cin/structure.html

So I edit above mentioned structure definition as (in both locations)

struct prov_data
    {
        u8_t pdu[25];
        u8_t dev_key[16];
        u8_t flags;
        u16_t net_idx;
        u16_t addr;
        u32_t iv_index;
    }__attribute__((packed));



On Tue, Jan 30, 2018 at 3:49 PM, Vikrant More <vikrant8051@...> wrote:
Hello World !!

By including NFFS support into #BluetoothMesh project, now I can access flash of nRF52.

{
  Some useful links:

  http://docs.zephyrproject.org/api/file_system.html
  https://lists.zephyrproject.org/pipermail/zephyr-devel/2018-January/thread.html (threads related to NFFS will be helpful to others )
}

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

I've edited prov_data( ) function which is available at $zephyr_base/subssy/bluetooth/host/mesh/prov.c as follow,

static void prov_data(const u8_t *data)
{
    struct net_buf_simple *msg = PROV_BUF(1);
    u8_t session_key[16];
    u8_t nonce[13];
    u8_t dev_key[16];
    u8_t pdu[25];
    u8_t flags;
    u32_t iv_index;
    u16_t addr;
    u16_t net_idx;
    int err;

    BT_DBG("");

    err = bt_mesh_session_key(link.dhkey, link.prov_salt, session_key);
    if (err) {
        BT_ERR("Unable to generate session key");
        close_link(PROV_ERR_UNEXP_ERR, CLOSE_REASON_FAILED);
        return;
    }

    BT_DBG("SessionKey: %s", bt_hex(session_key, 16));

    err = bt_mesh_prov_nonce(link.dhkey, link.prov_salt, nonce);
    if (err) {
        BT_ERR("Unable to generate session nonce");
        close_link(PROV_ERR_UNEXP_ERR, CLOSE_REASON_FAILED);
        return;
    }

    BT_DBG("Nonce: %s", bt_hex(nonce, 13));

    err = bt_mesh_prov_decrypt(session_key, nonce, data, pdu);
    if (err) {
        BT_ERR("Unable to decrypt provisioning data");
        close_link(PROV_ERR_DECRYPT, CLOSE_REASON_FAILED);
        return;
    }

    err = bt_mesh_dev_key(link.dhkey, link.prov_salt, dev_key);
    if (err) {
        BT_ERR("Unable to generate device key");
        close_link(PROV_ERR_UNEXP_ERR, CLOSE_REASON_FAILED);
        return;
    }

    BT_DBG("DevKey: %s", bt_hex(dev_key, 16));

    net_idx = sys_get_be16(&pdu[16]);
    flags = pdu[18];
    iv_index = sys_get_be32(&pdu[19]);
    addr = sys_get_be16(&pdu[23]);

    BT_DBG("net_idx %u iv_index 0x%08x, addr 0x%04x",
           net_idx, iv_index, addr);

    prov_buf_init(msg, PROV_COMPLETE);
    prov_send(msg);

    /* Ignore any further PDUs on this link */
    link.expect = 0;

    bt_mesh_provision(pdu, net_idx, flags, iv_index, 0, addr, dev_key);


//------------------------------------------------------------------------------------------------------------------------------------------

    struct prov_data
    {
        u8_t pdu[25];
        u8_t dev_key[16];
        u8_t flags;
        u16_t net_idx;
        u16_t addr;
        u32_t iv_index;
    };

    union
    {
        unsigned char array[50];
        struct prov_data a;
    }foo;
   
     int i;

    for(i=0;i<=24;i++)
    {
        foo.a.pdu[i]=pdu[i];
    }

    for(i=0;i<=15;i++)
    {
        foo.a.dev_key[i]=dev_key[i];
    }

    foo.a.flags = flags;
    foo.a.net_idx = net_idx;
    foo.a.addr = addr;   
    foo.a.iv_index = iv_index;
 
    fs_file_t fp;   

    err = fs_open(&fp,"/prov.txt");
    if (err != 0)
    {
        printk("\n\rerror %d while opening prov_cfg.txt for write\n\r", err);
    }

    err = fs_write(&fp, foo.array, 50);
    if (err != 50)
    {
        printk("\n\rerror %d while writing PDU\n\r", err);
    }

    err = fs_close(&fp);
    if (err != 0)
    {
        printk("\n\rerror %d while closing prov_cfg.txt after write\n\r", err);
    }

//------------------------------------------------------------------------------------------------------------------------------------------


}


Similarly, edit bt_ready( ) from $zephyr_base/samples/bluetooth/mesh/src/main.c as follow

static void bt_ready(int err)
{
    .
    .
    .
    .
    printk("Mesh initialized\n\r");

    struct fs_dirent entry;

    struct prov_data
    {
        u8_t pdu[25];
        u8_t dev_key[16];
        u8_t flags;
        u16_t net_idx;
        u16_t addr;
        u32_t iv_index;
    };

    union
    {
        unsigned char array[50];
        struct prov_data a;
    }test;

    if(fs_stat("/prov.txt",&entry)==0)
    {
        printk("\n\rprov.txt is available\n\r");

        fs_file_t fp;

        err = fs_open(&fp,"/prov.txt");
        if (err != 0) {
            printk("error %d while opening for read\n\r", err);
        }

        err = fs_read(&fp, test.array, 50);
        if (err < 0) {
            printk("error %d while reading\n\r", err);
        }

        err = fs_close(&fp);
        if (err != 0) {
            printk("error %d while closing after read\n\r", err);
        }

        err = bt_mesh_provision(test.a.pdu, test.a.net_idx, test.a.flags, test.a.iv_index, 0, test.a.addr, test.a.dev_key);
   
        if(err)
        {
            printk("Provisioning failed (err %d)\n", err);
            return;
        }

        printk("Provisioning completed\n\r");
   
    }

}

So after reset if prov.txt is available then DEVICE will automatically provision itself.
And as per my testing it is working perfectly.

But is it right approach since I've dare to touch stack ? 🤔

Now I wanna save data related to configuration which happens just after provisioning.

Where I will find that function ?

I'm aware about bt_mesh_cfg_app_key_add( ) this function but for that we've to enable CONFIG_BT_MESH_CFG_CLI=y
Is it necessary ? ...because even we disable it, provisioner APP trigger some function which does every thing like bt_mesh_cfg_app_key_add( ) does.

So please tell me where I will find that function, so that I can save ALL data related configuration into cfg.txt ?

As per my understanding once we complete, Provisioning & Configuration process, then there is no need to touch prov.txt & cfg.txt
in future for writing ? Am I right ?

Besides prov.txt & cfg.txt , how many files we have to create ?

If there will be standard for creating files for #BluetoothMesh then that will helpful for all.

Thank You !!



Saving #BluetoothMesh Provisioning & Configuration related data on flash of nRF52 using NFFS #bluetoothmesh

Vikrant More <vikrant8051@...>
 

Hello World !!

By including NFFS support into #BluetoothMesh project, now I can access flash of nRF52.

{
  Some useful links:

  http://docs.zephyrproject.org/api/file_system.html
  https://lists.zephyrproject.org/pipermail/zephyr-devel/2018-January/thread.html (threads related to NFFS will be helpful to others )
}

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

I've edited prov_data( ) function which is available at $zephyr_base/subssy/bluetooth/host/mesh/prov.c as follow,

static void prov_data(const u8_t *data)
{
    struct net_buf_simple *msg = PROV_BUF(1);
    u8_t session_key[16];
    u8_t nonce[13];
    u8_t dev_key[16];
    u8_t pdu[25];
    u8_t flags;
    u32_t iv_index;
    u16_t addr;
    u16_t net_idx;
    int err;

    BT_DBG("");

    err = bt_mesh_session_key(link.dhkey, link.prov_salt, session_key);
    if (err) {
        BT_ERR("Unable to generate session key");
        close_link(PROV_ERR_UNEXP_ERR, CLOSE_REASON_FAILED);
        return;
    }

    BT_DBG("SessionKey: %s", bt_hex(session_key, 16));

    err = bt_mesh_prov_nonce(link.dhkey, link.prov_salt, nonce);
    if (err) {
        BT_ERR("Unable to generate session nonce");
        close_link(PROV_ERR_UNEXP_ERR, CLOSE_REASON_FAILED);
        return;
    }

    BT_DBG("Nonce: %s", bt_hex(nonce, 13));

    err = bt_mesh_prov_decrypt(session_key, nonce, data, pdu);
    if (err) {
        BT_ERR("Unable to decrypt provisioning data");
        close_link(PROV_ERR_DECRYPT, CLOSE_REASON_FAILED);
        return;
    }

    err = bt_mesh_dev_key(link.dhkey, link.prov_salt, dev_key);
    if (err) {
        BT_ERR("Unable to generate device key");
        close_link(PROV_ERR_UNEXP_ERR, CLOSE_REASON_FAILED);
        return;
    }

    BT_DBG("DevKey: %s", bt_hex(dev_key, 16));

    net_idx = sys_get_be16(&pdu[16]);
    flags = pdu[18];
    iv_index = sys_get_be32(&pdu[19]);
    addr = sys_get_be16(&pdu[23]);

    BT_DBG("net_idx %u iv_index 0x%08x, addr 0x%04x",
           net_idx, iv_index, addr);

    prov_buf_init(msg, PROV_COMPLETE);
    prov_send(msg);

    /* Ignore any further PDUs on this link */
    link.expect = 0;

    bt_mesh_provision(pdu, net_idx, flags, iv_index, 0, addr, dev_key);


//------------------------------------------------------------------------------------------------------------------------------------------

    struct prov_data
    {
        u8_t pdu[25];
        u8_t dev_key[16];
        u8_t flags;
        u16_t net_idx;
        u16_t addr;
        u32_t iv_index;
    };

    union
    {
        unsigned char array[50];
        struct prov_data a;
    }foo;
   
     int i;

    for(i=0;i<=24;i++)
    {
        foo.a.pdu[i]=pdu[i];
    }

    for(i=0;i<=15;i++)
    {
        foo.a.dev_key[i]=dev_key[i];
    }

    foo.a.flags = flags;
    foo.a.net_idx = net_idx;
    foo.a.addr = addr;   
    foo.a.iv_index = iv_index;
 
    fs_file_t fp;   

    err = fs_open(&fp,"/prov.txt");
    if (err != 0)
    {
        printk("\n\rerror %d while opening prov_cfg.txt for write\n\r", err);
    }

    err = fs_write(&fp, foo.array, 50);
    if (err != 50)
    {
        printk("\n\rerror %d while writing PDU\n\r", err);
    }

    err = fs_close(&fp);
    if (err != 0)
    {
        printk("\n\rerror %d while closing prov_cfg.txt after write\n\r", err);
    }

//------------------------------------------------------------------------------------------------------------------------------------------


}


Similarly, edit bt_ready( ) from $zephyr_base/samples/bluetooth/mesh/src/main.c as follow

static void bt_ready(int err)
{
    .
    .
    .
    .
    printk("Mesh initialized\n\r");

    struct fs_dirent entry;

    struct prov_data
    {
        u8_t pdu[25];
        u8_t dev_key[16];
        u8_t flags;
        u16_t net_idx;
        u16_t addr;
        u32_t iv_index;
    };

    union
    {
        unsigned char array[50];
        struct prov_data a;
    }test;

    if(fs_stat("/prov.txt",&entry)==0)
    {
        printk("\n\rprov.txt is available\n\r");

        fs_file_t fp;

        err = fs_open(&fp,"/prov.txt");
        if (err != 0) {
            printk("error %d while opening for read\n\r", err);
        }

        err = fs_read(&fp, test.array, 50);
        if (err < 0) {
            printk("error %d while reading\n\r", err);
        }

        err = fs_close(&fp);
        if (err != 0) {
            printk("error %d while closing after read\n\r", err);
        }

        err = bt_mesh_provision(test.a.pdu, test.a.net_idx, test.a.flags, test.a.iv_index, 0, test.a.addr, test.a.dev_key);
   
        if(err)
        {
            printk("Provisioning failed (err %d)\n", err);
            return;
        }

        printk("Provisioning completed\n\r");
   
    }

}

So after reset if prov.txt is available then DEVICE will automatically provision itself.
And as per my testing it is working perfectly.

But is it right approach since I've dare to touch stack ? 🤔

Now I wanna save data related to configuration which happens just after provisioning.

Where I will find that function ?

I'm aware about bt_mesh_cfg_app_key_add( ) this function but for that we've to enable CONFIG_BT_MESH_CFG_CLI=y
Is it necessary ? ...because even we disable it, provisioner APP trigger some function which does every thing like bt_mesh_cfg_app_key_add( ) does.

So please tell me where I will find that function, so that I can save ALL data related configuration into cfg.txt ?

As per my understanding once we complete, Provisioning & Configuration process, then there is no need to touch prov.txt & cfg.txt
in future for writing ? Am I right ?

Besides prov.txt & cfg.txt , how many files we have to create ?

If there will be standard for creating files for #BluetoothMesh then that will helpful for all.

Thank You !!


Re: undefined reference to `bt_uuid_str'

Johan Hedberg
 

Hi Paul,

On Mon, Jan 29, 2018, Gavrikov Paul wrote:
builing a mesh app with debug logs for provisioning fails, due to a
missing ref. HEAD is at dbba22397c439ff4675de61407635ae4b5e5ac38

Log:

subsys/bluetooth/host/mesh/libsubsys__bluetooth__host__mesh.a(prov.c.obj): In function `bt_mesh_prov_init':
C:/Users/pgavrikov/Desktop/zephyr/subsys/bluetooth/host/mesh/prov.c:1568: undefined reference to `bt_uuid_str'
collect2.exe: error: ld returned 1 exit status
%
make[3]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:106: zephyr/zephyr_prebuilt.elf] Fehler 1
make[2]: *** [CMakeFiles/Makefile2:600: zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Fehler 2
make[1]: *** [CMakeFiles/Makefile2:2119: zephyr/cmake/flash/CMakeFiles/flash.dir/rule] Fehler 2
make: *** [Makefile:430: flash] Fehler 2
I'm unable to reproduce this. Is this your own app and a custom
configuration, or a sample from the Zephyr tree? If it's your custom
app, could you provide the output of the following:

grep CONFIG_BT_ <build dir>/zephyr/.config

Johan


Re: Zephyr nRF52840 USBD driver development: EPSTATUS vs EPDATASTATUS register

Sundar Subramaniyan
 

Hi Carles,

Thanks for the information.
I'll get back if I run into other doubts.

Sundar


On Mon, Jan 29, 2018 at 3:55 PM, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Sundar,

 

I am told internally that it should be EPDATASTATUS, there is an mistake in the documentation.

 

Thanks,

 

Carles

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Sundar Subramaniyan
Sent: 27 January 2018 17:13
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Zephyr nRF52840 USBD driver development: EPSTATUS vs EPDATASTATUS register

 

Hi,



I'm developing a driver for USB device controller on nRF52840. I came across the BULK/INTERRUPT section in the datasheet and have some doubts.
My question is about the significance of EPSTATUS and EPDATASTATUS registers.

In Section 51.10.2 from the nRF52840 datasheet, it's mentioned that EPSTATUS register gets set when EPDATA event happens on one of the BULK/Interrupt OUT endpoint.

Here's the excerpt:
"Upon receiving the next OUT + DATA transaction, an ACK handshake
is returned to the host while a EPDATA event is sent (and EPSTATUS register flags set to indicate on which
endpoint this happened), and once the EasyDMA is prepared and enabled through writing the EPOUT[n]
registers and sending the STARTEPOUT[n] task, the incoming data will be transferred to Data RAM."

 

But according to section 51.13.23, EPSTATUS notifies only about the capture of EasyDMA registers. There's no mention about acknowledged data transfer on the USB bus.
Per section 51.13.24, the EPDATASTATUS register is the one that tells if there's an acknowledged DATA transfer on the USB bus.

So when a EPDATA event occurs, should I be reading EPSTATUS and EPDATASTATUS registers and infer which endpoint the event happened depending on the context/type of data exchange?
Could anyone please clarify?

Thanks in advance.

Sundar



Re: Zephyr nRF52840 USBD driver development: EPSTATUS vs EPDATASTATUS register

Sundar Subramaniyan
 

Hi Andrzej,

I'll make it read the EPDATASTATUS register alone for bulk/interrupt in that case.
Thanks for the clarification.

Sundar

On Mon, Jan 29, 2018 at 2:34 PM, Głąbek, Andrzej <Andrzej.Glabek@...> wrote:

Hi Sundar,

 

The EPDATASTATUS register is the one that you should examine after getting the EPDATA event (our USB expert has confirmed this).

nRF52840 documentation is a bit imprecise in this regard in section 51.10.2.

 

Best regards,

Andrzej

 

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Sundar Subramaniyan
Sent: Saturday, January 27, 2018 5:13 PM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Zephyr nRF52840 USBD driver development: EPSTATUS vs EPDATASTATUS register

 

Hi,

I'm developing a driver for USB device controller on nRF52840. I came across the BULK/INTERRUPT section in the datasheet and have some doubts.
My question is about the significance of EPSTATUS and EPDATASTATUS registers.

In Section 51.10.2 from the nRF52840 datasheet, it's mentioned that EPSTATUS register gets set when EPDATA event happens on one of the BULK/Interrupt OUT endpoint.

Here's the excerpt:
"Upon receiving the next OUT + DATA transaction, an ACK handshake
is returned to the host while a EPDATA event is sent (and EPSTATUS register flags set to indicate on which
endpoint this happened), and once the EasyDMA is prepared and enabled through writing the EPOUT[n]
registers and sending the STARTEPOUT[n] task, the incoming data will be transferred to Data RAM."

 

But according to section 51.13.23, EPSTATUS notifies only about the capture of EasyDMA registers. There's no mention about acknowledged data transfer on the USB bus.
Per section 51.13.24, the EPDATASTATUS register is the one that tells if there's an acknowledged DATA transfer on the USB bus.

So when a EPDATA event occurs, should I be reading EPSTATUS and EPDATASTATUS registers and infer which endpoint the event happened depending on the context/type of data exchange?
Could anyone please clarify?

Thanks in advance.

Sundar



undefined reference to `bt_uuid_str'

Gavrikov Paul <Paul.Gavrikov@...>
 

Hello,

 

builing a mesh app with debug logs for provisioning fails, due to a missing ref. HEAD is at dbba22397c439ff4675de61407635ae4b5e5ac38

 

Log:

 

subsys/bluetooth/host/mesh/libsubsys__bluetooth__host__mesh.a(prov.c.obj): In function `bt_mesh_prov_init':

C:/Users/pgavrikov/Desktop/zephyr/subsys/bluetooth/host/mesh/prov.c:1568: undefined reference to `bt_uuid_str'

collect2.exe: error: ld returned 1 exit status

%

make[3]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:106: zephyr/zephyr_prebuilt.elf] Fehler 1

make[2]: *** [CMakeFiles/Makefile2:600: zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Fehler 2

make[1]: *** [CMakeFiles/Makefile2:2119: zephyr/cmake/flash/CMakeFiles/flash.dir/rule] Fehler 2

make: *** [Makefile:430: flash] Fehler 2

 

Best regards,

Paul Gavrikov

 

eMail: Paul.Gavrikov@...

web:  www.newtec.de

 

NewTec GmbH

Heinrich-von-Stephan-Straße 8

D-79100 Freiburg

Geschäftsführer: Johannes Werbach, Harald Molle, Ulrich Schwer, Michael Tröscher Registergericht Memmingen - HRB 7236 USt.-IdNr. DE130850199

 


Re: tests/subsys/fs/nffs_fs_api fails after commit ff7dfc4fb44b5c987e42afc847dce33f43d520ba

Steve Brown
 

Hi Carles,

The test now builds and runs successfully.

Thanks,

Steve

On Mon, 2018-01-29 at 11:31 +0000, Cufi, Carles wrote:
Hi Steve,

Andrzej has posted a PR today:

https://github.com/zephyrproject-rtos/zephyr/pull/5869

Regards,

Carles

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-
devel-
bounces@lists.zephyrproject.org] On Behalf Of Steve Brown
Sent: 27 January 2018 11:15
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] tests/subsys/fs/nffs_fs_api fails after
commit
ff7dfc4fb44b5c987e42afc847dce33f43d520ba

From bisect
dts: bindings: add support for the flash driver name


***** BOOTING ZEPHYR OS v1.10.99 - BUILD: Jan 27 2018 10:01:12
*****
Running test suite nffs_fs_basic_test
===================================================================
starting test - test_unlink
***** BUS FAULT *****
Executing thread ID (thread): 0x20025920
Faulting instruction address: 0x9f38018
Instruction bus error
Fatal fault in thread 0x20025920! Aborting.

The board is a nrf52840_pca10056.

Additionally, there is a typo in the CMakeLists.txt file for this
board.

zephyrt_compile_definitions -> zephyr_compile_definitions

Also, the set CONF_FILE for this board doesn't have an effect.
prj.conf
is still used.

CONF_FILE=nrf5x.conf cmake -DBOARD=nrf52840_pca10056 ..

Selects the proper config file.

Steve

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: tests/subsys/fs/nffs_fs_api fails after commit ff7dfc4fb44b5c987e42afc847dce33f43d520ba

Carles Cufi
 

Hi Steve,

Andrzej has posted a PR today:

https://github.com/zephyrproject-rtos/zephyr/pull/5869

Regards,

Carles

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-
bounces@lists.zephyrproject.org] On Behalf Of Steve Brown
Sent: 27 January 2018 11:15
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] tests/subsys/fs/nffs_fs_api fails after commit
ff7dfc4fb44b5c987e42afc847dce33f43d520ba

From bisect
dts: bindings: add support for the flash driver name


***** BOOTING ZEPHYR OS v1.10.99 - BUILD: Jan 27 2018 10:01:12 *****
Running test suite nffs_fs_basic_test
===================================================================
starting test - test_unlink
***** BUS FAULT *****
Executing thread ID (thread): 0x20025920
Faulting instruction address: 0x9f38018
Instruction bus error
Fatal fault in thread 0x20025920! Aborting.

The board is a nrf52840_pca10056.

Additionally, there is a typo in the CMakeLists.txt file for this board.

zephyrt_compile_definitions -> zephyr_compile_definitions

Also, the set CONF_FILE for this board doesn't have an effect. prj.conf
is still used.

CONF_FILE=nrf5x.conf cmake -DBOARD=nrf52840_pca10056 ..

Selects the proper config file.

Steve

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Zephyr nRF52840 USBD driver development: EPSTATUS vs EPDATASTATUS register

Carles Cufi
 

Hi Sundar,

 

I am told internally that it should be EPDATASTATUS, there is an mistake in the documentation.

 

Thanks,

 

Carles

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Sundar Subramaniyan
Sent: 27 January 2018 17:13
To: zephyr-devel@...
Subject: [Zephyr-devel] Zephyr nRF52840 USBD driver development: EPSTATUS vs EPDATASTATUS register

 

Hi,

I'm developing a driver for USB device controller on nRF52840. I came across the BULK/INTERRUPT section in the datasheet and have some doubts.
My question is about the significance of EPSTATUS and EPDATASTATUS registers.

In Section 51.10.2 from the nRF52840 datasheet, it's mentioned that EPSTATUS register gets set when EPDATA event happens on one of the BULK/Interrupt OUT endpoint.

Here's the excerpt:
"Upon receiving the next OUT + DATA transaction, an ACK handshake
is returned to the host while a EPDATA event is sent (and EPSTATUS register flags set to indicate on which
endpoint this happened), and once the EasyDMA is prepared and enabled through writing the EPOUT[n]
registers and sending the STARTEPOUT[n] task, the incoming data will be transferred to Data RAM."

 

But according to section 51.13.23, EPSTATUS notifies only about the capture of EasyDMA registers. There's no mention about acknowledged data transfer on the USB bus.
Per section 51.13.24, the EPDATASTATUS register is the one that tells if there's an acknowledged DATA transfer on the USB bus.

So when a EPDATA event occurs, should I be reading EPSTATUS and EPDATASTATUS registers and infer which endpoint the event happened depending on the context/type of data exchange?
Could anyone please clarify?

Thanks in advance.

Sundar


Re: FW: support for NFFS file system

Vikrant More <vikrant8051@...>
 

I forgot to inform that, we have to add ext/fs/nffs/include into list of include directories.

For that edit $zephyr_base/CMakeLists.txt as follow .... so it will looks like..

zephyr_include_directories(
  kernel/include
  arch/${ARCH}/include
  arch/${ARCH}/soc/${SOC_PATH}
  arch/${ARCH}/soc/${SOC_PATH}/include
  arch/${ARCH}/soc/${SOC_FAMILY}/include
  ${BOARD_DIR}
  include
  include/drivers
  ${PROJECT_BINARY_DIR}/include/generated
  ${USERINCLUDE}
  ${STDINCLUDE}
  ext/fs/nffs/include
)


I have also corrected my main.c. Plz consider it.


On Mon, Jan 29, 2018 at 12:19 PM, Vikrant More <vikrant8051@...> wrote:
Thanks Michael !!

Now I can access flash of nRF52840 using NFFS file system APIs.

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.

Thank You !!

On Fri, Jan 26, 2018 at 1:43 AM, Michael Hope <michaelh@...> wrote:
You can look up the error numbers to see what they mean in:


-19 is ENODEV which suggests you have a flash driver configuration problem.

I put together a little sample at https://github.com/nzmichaelh/zephyr_mini_samples  I tested it on an Arduino Zero, not a NRF5 board, so you will need to update prj.conf but I hope it helps.

-- Michael

On Thu, 25 Jan 2018 at 05:37 Vikrant More <vikrant8051@...> wrote:
fs_open( ) returns -19 instead of 0.

On Thu, Jan 25, 2018 at 12:10 AM, Michael Hope <michaelh@...> wrote:
Hi Vikrant.  I'm pretty sure you're reading past the end of the file - you'll need to close and reopen it before you can read back what you just wrote.  Try something like:

fs_open(...)
fs_write(...)
fs_close(...)

fs_open(...)
fs_read(...)

I also recommend checking the return value when you're experimenting.  In this case, you'll find that fs_read() is returning zero, i.e. it read zero bytes which is a good clue as to why there's no data in the buffer.

-- Michael

On Wed, 24 Jan 2018 at 13:29 Vikrant More <vikrant8051@...> wrote:
Hi Vinayak, it works !!

I make following changes .....

    fs_file_t my_zfp;
    unsigned char ptr[32];

    for(cntr=0;cntr<=31;cntr++)
    {
        ptr[cntr]='@';
    }

    fs_open(&my_zfp,"mesh.prv");
    fs_write(&my_zfp,"0123456789ABCDEF",16);
    fs_read(&my_zfp,ptr,32);
    fs_close(&my_zfp);

    for(cntr=0;cntr<=31;cntr++)
    {
        printk("%c",ptr[cntr]);
    }

But it prints --> @@@@@@@@@@@@@@@@
instead of --> 0123456789ABCDEF

Any clue ??

Thanks !!

On Wed, Jan 24, 2018 at 5:41 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Its:

 

fs_file_t my_zfp; // no * please;

 

and

 

fs_open(&my_zfp,"mesh.prv"); // & please J

 

That said, I am not expert on FS!

 

-Vinayak

 

From: zephyr-devel-bounces@...hyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Wednesday, January 24, 2018 1:06 PM
To: Michael Hope <michaelh@...>
Cc: zephyr-users@...ct.org; zephyr-devel@...ct.org
Subject: Re: [Zephyr-devel] FW: support for NFFS file system

 

I copied & pasted $zephyr/ext/fs/nffs directory into $zephyr_base/include
----------------------------------------------------------------------------------------------------------------------

& edit $zephyr_base/include/fs/nffs_fs.h as follow

/*
 * Copyright (c) 2017 Codecoup
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#ifndef _NFFS_FS_H_
#define _NFFS_FS_H_

#include <sys/types.h>
#include <nffs/include/nffs/nffs.h>

#ifdef __cplusplus
extern "C" {
#endif

FS_FILE_DEFINE(struct nffs_file *fp);
FS_DIR_DEFINE(struct nffs_dir *dp);

#define MAX_FILE_NAME 256

#ifdef __cplusplus
}
#endif

#endif /* _NFFS_FS_H_ */

-------------------------------------------------------------------------------------------------------------------------

& add following config into my prj.conf

CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y
CONFIG_SOC_FLASH_NRF5=y
CONFIG_SOC_FLASH_NRF5_DEV_NAME="NRF52_FLASH"
CONFIG_SOC_FLASH_NRF5_RADIO_SYNC=y
CONFIG_ZTEST_STACKSIZE=2048
CONFIG_MAIN_STACK_SIZE=1024
CONFIG_HEAP_MEM_POOL_SIZE=1024


CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12

------------------------------------------------------------------------------------------------------------------------

& add following lines in main.c

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

After all this every thing gets compiled with warning :

 

warning: ‘my_zfp’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  fs_open(my_zfp,"mesh.prv");

Could you please help me, how to initialized my_zfp here ?

 

 

On Tue, Jan 23, 2018 at 1:15 AM, Michael Hope <michaelh@...> wrote:

Hi Vikrant.  You also need to enable NFFS in your configuration - try 'make menuconfig' > File Systems > File system support = y; Supported file systems -> NFFS.

You can also check out the NFFS test case under tests/subsys/fs and especially the configuration in https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/subsys/fs/nffs_fs_api/nrf5x.conf

-- Michael

 

On Fri, 19 Jan 2018 at 11:46 Vikrant More <vikrant8051@...> wrote:

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

I've edited main.c in my project as mentioned above.

And add CONFIG_FILE_SYSTEM_NFFS=y in prj.conf

 

1st time I got following error,

 

In file included from /home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:3:0:
/home/vikrant/projects/zephyr/zephyr/include/fs.h:66:12: error: ‘MAX_FILE_NAME’ undeclared here (not in a function)
  char name[MAX_FILE_NAME + 1];
            ^~~~~~~~~~~~~
CMakeFiles/app.dir/build.make:302: recipe for target 'CMakeFiles/app.dir/src/main.c.obj' failed
make[2]: *** [CMakeFiles/app.dir/src/main.c.obj] Error 1
CMakeFiles/Makefile2:259: recipe for target 'CMakeFiles/app.dir/all' failed
make[1]: *** [CMakeFiles/app.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

To overcome it I added ,    #define MAX_FILE_NAME 10   in zephyr/include/fs.h

 

After this I got following error,

 

../libapp.a(main.c.obj): In function `main':
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:226: undefined reference to `fs_open'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:227: undefined reference to `fs_write'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:228: undefined reference to `fs_read'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:229: undefined reference to `fs_close'
collect2: error: ld returned 1 exit status
zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:104: recipe for target 'zephyr/zephyr_prebuilt.elf' failed
make[2]: *** [zephyr/zephyr_prebuilt.elf] Error 1
CMakeFiles/Makefile2:569: recipe for target 'zephyr/CMakeFiles/zephyr_prebuilt.dir/all' failed
make[1]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

 

 

 

Following line are already present in zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts

 


#if defined(CONFIG_FILE_SYSTEM_NFFS)
        nffs_partition: partition@fc000 {
            label = "nffs";
            reg = <0x000fc000 0x00004000>;
        };
#endif

 

Could you please tell me what I'm missing ?

 

Thank You !!

 

On Fri, Jan 19, 2018 at 12:15 AM, Michael Hope <michaelh@...> wrote:

 

1. Ensure the board has a nffs partition defined in Device Tree.  See here for an example.

2. Turn on CONFIG_FILE_SYSTEM_NFFS in the config

3. Use the APIs in include/fs.h such as fs_open() etc

If you turn on CONFIG_FILE_SYSTEM_SHELL then you'll also get a simple interactive shell where you can list directories etc.

-- Michael

 

On Thu, 18 Jan 2018 at 15:16 Vikrant More <vikrant8051@...> wrote:

Thanks for reply.

 

Where I will find APIs & sample codes based on it to access internal flash of nrf52840 ?

 

 

On Jan 18, 2018 3:38 PM, "Puzdrowski, Andrzej" <Andrzej.Puzdrowski@nordicsemi.no> wrote:

NFFS Is supported since 1.10 release:

https://www.zephyrproject.org/releases/1-10-release-december-2017/

 

Andrzej

From: zephyr-devel-bounces@...hyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Thursday, January 18, 2018 10:09 AM
To: zephyr-devel@...ct.org; zephyr-users@...ct.org
Subject: [Zephyr-devel] support for NFFS file system

 

Hello World !!

 

My question is related to this link's requirement,
https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-July/007888.html

Is Zephyr going to add support for NFFS file system in upcoming 1.11 (March 20148) release ?

What is current status of NFFS file system development ?

Could anybody explain me from Zephyr Core developer team ?

Thank You !! 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 

 



On Wed, Jan 24, 2018 at 5:41 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Its:

 

fs_file_t my_zfp; // no * please;

 

and

 

fs_open(&my_zfp,"mesh.prv"); // & please J

 

That said, I am not expert on FS!

 

-Vinayak

 

From: zephyr-devel-bounces@...hyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Wednesday, January 24, 2018 1:06 PM
To: Michael Hope <michaelh@...>
Cc: zephyr-users@...ct.org; zephyr-devel@...ct.org
Subject: Re: [Zephyr-devel] FW: support for NFFS file system

 

I copied & pasted $zephyr/ext/fs/nffs directory into $zephyr_base/include
----------------------------------------------------------------------------------------------------------------------

& edit $zephyr_base/include/fs/nffs_fs.h as follow

/*
 * Copyright (c) 2017 Codecoup
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#ifndef _NFFS_FS_H_
#define _NFFS_FS_H_

#include <sys/types.h>
#include <nffs/include/nffs/nffs.h>

#ifdef __cplusplus
extern "C" {
#endif

FS_FILE_DEFINE(struct nffs_file *fp);
FS_DIR_DEFINE(struct nffs_dir *dp);

#define MAX_FILE_NAME 256

#ifdef __cplusplus
}
#endif

#endif /* _NFFS_FS_H_ */

-------------------------------------------------------------------------------------------------------------------------

& add following config into my prj.conf

CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y
CONFIG_SOC_FLASH_NRF5=y
CONFIG_SOC_FLASH_NRF5_DEV_NAME="NRF52_FLASH"
CONFIG_SOC_FLASH_NRF5_RADIO_SYNC=y
CONFIG_ZTEST_STACKSIZE=2048
CONFIG_MAIN_STACK_SIZE=1024
CONFIG_HEAP_MEM_POOL_SIZE=1024


CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12

------------------------------------------------------------------------------------------------------------------------

& add following lines in main.c

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

After all this every thing gets compiled with warning :

 

warning: ‘my_zfp’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  fs_open(my_zfp,"mesh.prv");

Could you please help me, how to initialized my_zfp here ?

 

 

On Tue, Jan 23, 2018 at 1:15 AM, Michael Hope <michaelh@...> wrote:

Hi Vikrant.  You also need to enable NFFS in your configuration - try 'make menuconfig' > File Systems > File system support = y; Supported file systems -> NFFS.

You can also check out the NFFS test case under tests/subsys/fs and especially the configuration in https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/subsys/fs/nffs_fs_api/nrf5x.conf

-- Michael

 

On Fri, 19 Jan 2018 at 11:46 Vikrant More <vikrant8051@...> wrote:

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

I've edited main.c in my project as mentioned above.

And add CONFIG_FILE_SYSTEM_NFFS=y in prj.conf

 

1st time I got following error,

 

In file included from /home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:3:0:
/home/vikrant/projects/zephyr/zephyr/include/fs.h:66:12: error: ‘MAX_FILE_NAME’ undeclared here (not in a function)
  char name[MAX_FILE_NAME + 1];
            ^~~~~~~~~~~~~
CMakeFiles/app.dir/build.make:302: recipe for target 'CMakeFiles/app.dir/src/main.c.obj' failed
make[2]: *** [CMakeFiles/app.dir/src/main.c.obj] Error 1
CMakeFiles/Makefile2:259: recipe for target 'CMakeFiles/app.dir/all' failed
make[1]: *** [CMakeFiles/app.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

To overcome it I added ,    #define MAX_FILE_NAME 10   in zephyr/include/fs.h

 

After this I got following error,

 

../libapp.a(main.c.obj): In function `main':
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:226: undefined reference to `fs_open'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:227: undefined reference to `fs_write'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:228: undefined reference to `fs_read'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:229: undefined reference to `fs_close'
collect2: error: ld returned 1 exit status
zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:104: recipe for target 'zephyr/zephyr_prebuilt.elf' failed
make[2]: *** [zephyr/zephyr_prebuilt.elf] Error 1
CMakeFiles/Makefile2:569: recipe for target 'zephyr/CMakeFiles/zephyr_prebuilt.dir/all' failed
make[1]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

 

 

 

Following line are already present in zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts

 


#if defined(CONFIG_FILE_SYSTEM_NFFS)
        nffs_partition: partition@fc000 {
            label = "nffs";
            reg = <0x000fc000 0x00004000>;
        };
#endif

 

Could you please tell me what I'm missing ?

 

Thank You !!

 

On Fri, Jan 19, 2018 at 12:15 AM, Michael Hope <michaelh@...> wrote:

 

1. Ensure the board has a nffs partition defined in Device Tree.  See here for an example.

2. Turn on CONFIG_FILE_SYSTEM_NFFS in the config

3. Use the APIs in include/fs.h such as fs_open() etc

If you turn on CONFIG_FILE_SYSTEM_SHELL then you'll also get a simple interactive shell where you can list directories etc.

-- Michael

 

On Thu, 18 Jan 2018 at 15:16 Vikrant More <vikrant8051@...> wrote:

Thanks for reply.

 

Where I will find APIs & sample codes based on it to access internal flash of nrf52840 ?

 

 

On Jan 18, 2018 3:38 PM, "Puzdrowski, Andrzej" <Andrzej.Puzdrowski@nordicsemi.no> wrote:

NFFS Is supported since 1.10 release:

https://www.zephyrproject.org/releases/1-10-release-december-2017/

 

Andrzej

From: zephyr-devel-bounces@...hyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Thursday, January 18, 2018 10:09 AM
To: zephyr-devel@...ct.org; zephyr-users@...ct.org
Subject: [Zephyr-devel] support for NFFS file system

 

Hello World !!

 

My question is related to this link's requirement,
https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-July/007888.html

Is Zephyr going to add support for NFFS file system in upcoming 1.11 (March 20148) release ?

What is current status of NFFS file system development ?

Could anybody explain me from Zephyr Core developer team ?

Thank You !! 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 

 






Re: Zephyr nRF52840 USBD driver development: EPSTATUS vs EPDATASTATUS register

Andrzej G??bek
 

Hi Sundar,

 

The EPDATASTATUS register is the one that you should examine after getting the EPDATA event (our USB expert has confirmed this).

nRF52840 documentation is a bit imprecise in this regard in section 51.10.2.

 

Best regards,

Andrzej

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Sundar Subramaniyan
Sent: Saturday, January 27, 2018 5:13 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] Zephyr nRF52840 USBD driver development: EPSTATUS vs EPDATASTATUS register

 

Hi,

I'm developing a driver for USB device controller on nRF52840. I came across the BULK/INTERRUPT section in the datasheet and have some doubts.
My question is about the significance of EPSTATUS and EPDATASTATUS registers.

In Section 51.10.2 from the nRF52840 datasheet, it's mentioned that EPSTATUS register gets set when EPDATA event happens on one of the BULK/Interrupt OUT endpoint.

Here's the excerpt:
"Upon receiving the next OUT + DATA transaction, an ACK handshake
is returned to the host while a EPDATA event is sent (and EPSTATUS register flags set to indicate on which
endpoint this happened), and once the EasyDMA is prepared and enabled through writing the EPOUT[n]
registers and sending the STARTEPOUT[n] task, the incoming data will be transferred to Data RAM."

 

But according to section 51.13.23, EPSTATUS notifies only about the capture of EasyDMA registers. There's no mention about acknowledged data transfer on the USB bus.
Per section 51.13.24, the EPDATASTATUS register is the one that tells if there's an acknowledged DATA transfer on the USB bus.

So when a EPDATA event occurs, should I be reading EPSTATUS and EPDATASTATUS registers and infer which endpoint the event happened depending on the context/type of data exchange?
Could anyone please clarify?

Thanks in advance.

Sundar


Re: FW: support for NFFS file system

Vikrant More <vikrant8051@...>
 

Thanks Michael !!

Now I can access flash of nRF52840 using NFFS file system APIs.

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.

Thank You !!

On Fri, Jan 26, 2018 at 1:43 AM, Michael Hope <michaelh@...> wrote:
You can look up the error numbers to see what they mean in:


-19 is ENODEV which suggests you have a flash driver configuration problem.

I put together a little sample at https://github.com/nzmichaelh/zephyr_mini_samples  I tested it on an Arduino Zero, not a NRF5 board, so you will need to update prj.conf but I hope it helps.

-- Michael

On Thu, 25 Jan 2018 at 05:37 Vikrant More <vikrant8051@...> wrote:
fs_open( ) returns -19 instead of 0.

On Thu, Jan 25, 2018 at 12:10 AM, Michael Hope <michaelh@...> wrote:
Hi Vikrant.  I'm pretty sure you're reading past the end of the file - you'll need to close and reopen it before you can read back what you just wrote.  Try something like:

fs_open(...)
fs_write(...)
fs_close(...)

fs_open(...)
fs_read(...)

I also recommend checking the return value when you're experimenting.  In this case, you'll find that fs_read() is returning zero, i.e. it read zero bytes which is a good clue as to why there's no data in the buffer.

-- Michael

On Wed, 24 Jan 2018 at 13:29 Vikrant More <vikrant8051@...> wrote:
Hi Vinayak, it works !!

I make following changes .....

    fs_file_t my_zfp;
    unsigned char ptr[32];

    for(cntr=0;cntr<=31;cntr++)
    {
        ptr[cntr]='@';
    }

    fs_open(&my_zfp,"mesh.prv");
    fs_write(&my_zfp,"0123456789ABCDEF",16);
    fs_read(&my_zfp,ptr,32);
    fs_close(&my_zfp);

    for(cntr=0;cntr<=31;cntr++)
    {
        printk("%c",ptr[cntr]);
    }

But it prints --> @@@@@@@@@@@@@@@@
instead of --> 0123456789ABCDEF

Any clue ??

Thanks !!

On Wed, Jan 24, 2018 at 5:41 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Its:

 

fs_file_t my_zfp; // no * please;

 

and

 

fs_open(&my_zfp,"mesh.prv"); // & please J

 

That said, I am not expert on FS!

 

-Vinayak

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Wednesday, January 24, 2018 1:06 PM
To: Michael Hope <michaelh@...>
Cc: zephyr-users@lists.zephyrproject.org; zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] FW: support for NFFS file system

 

I copied & pasted $zephyr/ext/fs/nffs directory into $zephyr_base/include
----------------------------------------------------------------------------------------------------------------------

& edit $zephyr_base/include/fs/nffs_fs.h as follow

/*
 * Copyright (c) 2017 Codecoup
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#ifndef _NFFS_FS_H_
#define _NFFS_FS_H_

#include <sys/types.h>
#include <nffs/include/nffs/nffs.h>

#ifdef __cplusplus
extern "C" {
#endif

FS_FILE_DEFINE(struct nffs_file *fp);
FS_DIR_DEFINE(struct nffs_dir *dp);

#define MAX_FILE_NAME 256

#ifdef __cplusplus
}
#endif

#endif /* _NFFS_FS_H_ */

-------------------------------------------------------------------------------------------------------------------------

& add following config into my prj.conf

CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y
CONFIG_SOC_FLASH_NRF5=y
CONFIG_SOC_FLASH_NRF5_DEV_NAME="NRF52_FLASH"
CONFIG_SOC_FLASH_NRF5_RADIO_SYNC=y
CONFIG_ZTEST_STACKSIZE=2048
CONFIG_MAIN_STACK_SIZE=1024
CONFIG_HEAP_MEM_POOL_SIZE=1024


CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12

------------------------------------------------------------------------------------------------------------------------

& add following lines in main.c

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

After all this every thing gets compiled with warning :

 

warning: ‘my_zfp’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  fs_open(my_zfp,"mesh.prv");

Could you please help me, how to initialized my_zfp here ?

 

 

On Tue, Jan 23, 2018 at 1:15 AM, Michael Hope <michaelh@...> wrote:

Hi Vikrant.  You also need to enable NFFS in your configuration - try 'make menuconfig' > File Systems > File system support = y; Supported file systems -> NFFS.

You can also check out the NFFS test case under tests/subsys/fs and especially the configuration in https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/subsys/fs/nffs_fs_api/nrf5x.conf

-- Michael

 

On Fri, 19 Jan 2018 at 11:46 Vikrant More <vikrant8051@...> wrote:

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

I've edited main.c in my project as mentioned above.

And add CONFIG_FILE_SYSTEM_NFFS=y in prj.conf

 

1st time I got following error,

 

In file included from /home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:3:0:
/home/vikrant/projects/zephyr/zephyr/include/fs.h:66:12: error: ‘MAX_FILE_NAME’ undeclared here (not in a function)
  char name[MAX_FILE_NAME + 1];
            ^~~~~~~~~~~~~
CMakeFiles/app.dir/build.make:302: recipe for target 'CMakeFiles/app.dir/src/main.c.obj' failed
make[2]: *** [CMakeFiles/app.dir/src/main.c.obj] Error 1
CMakeFiles/Makefile2:259: recipe for target 'CMakeFiles/app.dir/all' failed
make[1]: *** [CMakeFiles/app.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

To overcome it I added ,    #define MAX_FILE_NAME 10   in zephyr/include/fs.h

 

After this I got following error,

 

../libapp.a(main.c.obj): In function `main':
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:226: undefined reference to `fs_open'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:227: undefined reference to `fs_write'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:228: undefined reference to `fs_read'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:229: undefined reference to `fs_close'
collect2: error: ld returned 1 exit status
zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:104: recipe for target 'zephyr/zephyr_prebuilt.elf' failed
make[2]: *** [zephyr/zephyr_prebuilt.elf] Error 1
CMakeFiles/Makefile2:569: recipe for target 'zephyr/CMakeFiles/zephyr_prebuilt.dir/all' failed
make[1]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

 

 

 

Following line are already present in zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts

 


#if defined(CONFIG_FILE_SYSTEM_NFFS)
        nffs_partition: partition@fc000 {
            label = "nffs";
            reg = <0x000fc000 0x00004000>;
        };
#endif

 

Could you please tell me what I'm missing ?

 

Thank You !!

 

On Fri, Jan 19, 2018 at 12:15 AM, Michael Hope <michaelh@...> wrote:

 

1. Ensure the board has a nffs partition defined in Device Tree.  See here for an example.

2. Turn on CONFIG_FILE_SYSTEM_NFFS in the config

3. Use the APIs in include/fs.h such as fs_open() etc

If you turn on CONFIG_FILE_SYSTEM_SHELL then you'll also get a simple interactive shell where you can list directories etc.

-- Michael

 

On Thu, 18 Jan 2018 at 15:16 Vikrant More <vikrant8051@...> wrote:

Thanks for reply.

 

Where I will find APIs & sample codes based on it to access internal flash of nrf52840 ?

 

 

On Jan 18, 2018 3:38 PM, "Puzdrowski, Andrzej" <Andrzej.Puzdrowski@nordicsemi.no> wrote:

NFFS Is supported since 1.10 release:

https://www.zephyrproject.org/releases/1-10-release-december-2017/

 

Andrzej

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Thursday, January 18, 2018 10:09 AM
To: zephyr-devel@lists.zephyrproject.org; zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-devel] support for NFFS file system

 

Hello World !!

 

My question is related to this link's requirement,
https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-July/007888.html

Is Zephyr going to add support for NFFS file system in upcoming 1.11 (March 20148) release ?

What is current status of NFFS file system development ?

Could anybody explain me from Zephyr Core developer team ?

Thank You !! 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 

 



On Wed, Jan 24, 2018 at 5:41 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Its:

 

fs_file_t my_zfp; // no * please;

 

and

 

fs_open(&my_zfp,"mesh.prv"); // & please J

 

That said, I am not expert on FS!

 

-Vinayak

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Wednesday, January 24, 2018 1:06 PM
To: Michael Hope <michaelh@...>
Cc: zephyr-users@lists.zephyrproject.org; zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] FW: support for NFFS file system

 

I copied & pasted $zephyr/ext/fs/nffs directory into $zephyr_base/include
----------------------------------------------------------------------------------------------------------------------

& edit $zephyr_base/include/fs/nffs_fs.h as follow

/*
 * Copyright (c) 2017 Codecoup
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#ifndef _NFFS_FS_H_
#define _NFFS_FS_H_

#include <sys/types.h>
#include <nffs/include/nffs/nffs.h>

#ifdef __cplusplus
extern "C" {
#endif

FS_FILE_DEFINE(struct nffs_file *fp);
FS_DIR_DEFINE(struct nffs_dir *dp);

#define MAX_FILE_NAME 256

#ifdef __cplusplus
}
#endif

#endif /* _NFFS_FS_H_ */

-------------------------------------------------------------------------------------------------------------------------

& add following config into my prj.conf

CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y
CONFIG_SOC_FLASH_NRF5=y
CONFIG_SOC_FLASH_NRF5_DEV_NAME="NRF52_FLASH"
CONFIG_SOC_FLASH_NRF5_RADIO_SYNC=y
CONFIG_ZTEST_STACKSIZE=2048
CONFIG_MAIN_STACK_SIZE=1024
CONFIG_HEAP_MEM_POOL_SIZE=1024


CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12

------------------------------------------------------------------------------------------------------------------------

& add following lines in main.c

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

After all this every thing gets compiled with warning :

 

warning: ‘my_zfp’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  fs_open(my_zfp,"mesh.prv");

Could you please help me, how to initialized my_zfp here ?

 

 

On Tue, Jan 23, 2018 at 1:15 AM, Michael Hope <michaelh@...> wrote:

Hi Vikrant.  You also need to enable NFFS in your configuration - try 'make menuconfig' > File Systems > File system support = y; Supported file systems -> NFFS.

You can also check out the NFFS test case under tests/subsys/fs and especially the configuration in https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/subsys/fs/nffs_fs_api/nrf5x.conf

-- Michael

 

On Fri, 19 Jan 2018 at 11:46 Vikrant More <vikrant8051@...> wrote:

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

I've edited main.c in my project as mentioned above.

And add CONFIG_FILE_SYSTEM_NFFS=y in prj.conf

 

1st time I got following error,

 

In file included from /home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:3:0:
/home/vikrant/projects/zephyr/zephyr/include/fs.h:66:12: error: ‘MAX_FILE_NAME’ undeclared here (not in a function)
  char name[MAX_FILE_NAME + 1];
            ^~~~~~~~~~~~~
CMakeFiles/app.dir/build.make:302: recipe for target 'CMakeFiles/app.dir/src/main.c.obj' failed
make[2]: *** [CMakeFiles/app.dir/src/main.c.obj] Error 1
CMakeFiles/Makefile2:259: recipe for target 'CMakeFiles/app.dir/all' failed
make[1]: *** [CMakeFiles/app.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

To overcome it I added ,    #define MAX_FILE_NAME 10   in zephyr/include/fs.h

 

After this I got following error,

 

../libapp.a(main.c.obj): In function `main':
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:226: undefined reference to `fs_open'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:227: undefined reference to `fs_write'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:228: undefined reference to `fs_read'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:229: undefined reference to `fs_close'
collect2: error: ld returned 1 exit status
zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:104: recipe for target 'zephyr/zephyr_prebuilt.elf' failed
make[2]: *** [zephyr/zephyr_prebuilt.elf] Error 1
CMakeFiles/Makefile2:569: recipe for target 'zephyr/CMakeFiles/zephyr_prebuilt.dir/all' failed
make[1]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

 

 

 

Following line are already present in zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts

 


#if defined(CONFIG_FILE_SYSTEM_NFFS)
        nffs_partition: partition@fc000 {
            label = "nffs";
            reg = <0x000fc000 0x00004000>;
        };
#endif

 

Could you please tell me what I'm missing ?

 

Thank You !!

 

On Fri, Jan 19, 2018 at 12:15 AM, Michael Hope <michaelh@...> wrote:

 

1. Ensure the board has a nffs partition defined in Device Tree.  See here for an example.

2. Turn on CONFIG_FILE_SYSTEM_NFFS in the config

3. Use the APIs in include/fs.h such as fs_open() etc

If you turn on CONFIG_FILE_SYSTEM_SHELL then you'll also get a simple interactive shell where you can list directories etc.

-- Michael

 

On Thu, 18 Jan 2018 at 15:16 Vikrant More <vikrant8051@...> wrote:

Thanks for reply.

 

Where I will find APIs & sample codes based on it to access internal flash of nrf52840 ?

 

 

On Jan 18, 2018 3:38 PM, "Puzdrowski, Andrzej" <Andrzej.Puzdrowski@nordicsemi.no> wrote:

NFFS Is supported since 1.10 release:

https://www.zephyrproject.org/releases/1-10-release-december-2017/

 

Andrzej

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Thursday, January 18, 2018 10:09 AM
To: zephyr-devel@lists.zephyrproject.org; zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-devel] support for NFFS file system

 

Hello World !!

 

My question is related to this link's requirement,
https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-July/007888.html

Is Zephyr going to add support for NFFS file system in upcoming 1.11 (March 20148) release ?

What is current status of NFFS file system development ?

Could anybody explain me from Zephyr Core developer team ?

Thank You !! 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 

 





Re: tests/subsys/fs/nffs_fs_api fails after commit ff7dfc4fb44b5c987e42afc847dce33f43d520ba

Carles Cufi
 

Hi Steve,

Thanks for reporting this. Andrzej and I will take a look.

Carles

Am 27.01.2018 um 11:15 schrieb Steve Brown <sbrown@cortland.com>:

From bisect
dts: bindings: add support for the flash driver name


***** BOOTING ZEPHYR OS v1.10.99 - BUILD: Jan 27 2018 10:01:12 *****
Running test suite nffs_fs_basic_test
===================================================================
starting test - test_unlink
***** BUS FAULT *****
Executing thread ID (thread): 0x20025920
Faulting instruction address: 0x9f38018
Instruction bus error
Fatal fault in thread 0x20025920! Aborting.

The board is a nrf52840_pca10056.

Additionally, there is a typo in the CMakeLists.txt file for this
board.

zephyrt_compile_definitions -> zephyr_compile_definitions

Also, the set CONF_FILE for this board doesn't have an effect. prj.conf
is still used.

CONF_FILE=nrf5x.conf cmake -DBOARD=nrf52840_pca10056 ..

Selects the proper config file.

Steve

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Zephyr nRF52840 USBD driver development: EPSTATUS vs EPDATASTATUS register

Sundar Subramaniyan
 

Hi,

I'm developing a driver for USB device controller on nRF52840. I came across the BULK/INTERRUPT section in the datasheet and have some doubts.
My question is about the significance of EPSTATUS and EPDATASTATUS registers.

In Section 51.10.2 from the nRF52840 datasheet, it's mentioned that EPSTATUS register gets set when EPDATA event happens on one of the BULK/Interrupt OUT endpoint.

Here's the excerpt:
"Upon receiving the next OUT + DATA transaction, an ACK handshake
is returned to the host while a EPDATA event is sent (and EPSTATUS register flags set to indicate on which
endpoint this happened), and once the EasyDMA is prepared and enabled through writing the EPOUT[n]
registers and sending the STARTEPOUT[n] task, the incoming data will be transferred to Data RAM."

But according to section 51.13.23, EPSTATUS notifies only about the capture of EasyDMA registers. There's no mention about acknowledged data transfer on the USB bus.
Per section 51.13.24, the EPDATASTATUS register is the one that tells if there's an acknowledged DATA transfer on the USB bus.

So when a EPDATA event occurs, should I be reading EPSTATUS and EPDATASTATUS registers and infer which endpoint the event happened depending on the context/type of data exchange?
Could anyone please clarify?

Thanks in advance.

Sundar


tests/subsys/fs/nffs_fs_api fails after commit ff7dfc4fb44b5c987e42afc847dce33f43d520ba

Steve Brown
 

From bisect
dts: bindings: add support for the flash driver name


***** BOOTING ZEPHYR OS v1.10.99 - BUILD: Jan 27 2018 10:01:12 *****
Running test suite nffs_fs_basic_test
===================================================================
starting test - test_unlink
***** BUS FAULT *****
Executing thread ID (thread): 0x20025920
Faulting instruction address: 0x9f38018
Instruction bus error
Fatal fault in thread 0x20025920! Aborting.

The board is a nrf52840_pca10056.

Additionally, there is a typo in the CMakeLists.txt file for this
board.

zephyrt_compile_definitions -> zephyr_compile_definitions

Also, the set CONF_FILE for this board doesn't have an effect. prj.conf
is still used.

CONF_FILE=nrf5x.conf cmake -DBOARD=nrf52840_pca10056 ..

Selects the proper config file.

Steve


Re: Confusion about Zephyr ADC API semantics

Marti Bolivar
 

Hi everyone,

Thanks to everybody who responded.

Unfortunately due to some priority changes at my company, I'm not able to continue this work as much as I had originally thought. I've heard from some people who are interested in using an nRF SAADC driver, even out of tree. I have something hackish up here:


I also spoke on IRC with Giuliano Franchetto, who pointed me at this driver:


I think these could be a good starting point for people who need something now, and hopefully this can be taken up again in the future.

Thanks,
Marti



On Sun, Jan 7, 2018 at 6:55 PM, Piotr Mienkowski <piotr.mienkowski@...> wrote:
Hi Marti,

Sorry for a late reply. I would like to add a few points to the
discussion. At first I'll quote your email as you wrote it a while ago.

On 16.12.2017 03:00, Marti Bolivar wrote:
> I've been reading through the ADC API, its users, and its test cases,
> and I'm confused about the semantics of struct adc_seq_entry, in
> particular the field named "buffer". The API docs are vague and the
> users contradict each other; something seems wrong to me.
>
> (I volunteer to try to improve the documentation if we can clear
> things up; I'm working on an ADC driver and would like to make sure
> I'm doing the right thing.)
>
> The main header says "buffer" is a byte array:
>
> https://github.com/zephyrproject-rtos/zephyr/blob/master/include/adc.h#L39
>
> But it doesn't say anything about the contents. That's strange,
> especially since common ADC IPs can do 12+ bit conversions. (I at
> least expected a u16*, and something written about the left- or
> right-alignment of sample data, e.g. how a 12 bit sample is stored in
> a 16 bit word.)
>
> That same header only has this to say about the returned values from
> an adc_read() call:
>
> * The sample data can be retrieved from the memory buffers in
> * the sequence table structure.
>
> So I looked at the API users to find out more, but the results were
> even more confusing.
>
> This "simple" test wants to interpret the results as though the buffer
> field points at an array of u32 (note the _print_sample_in_hex
> implementation and the "delta" printk in adc_test):
>
> https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/drivers/adc/adc_simple/src/main.c#L36
>
> It also says buffer should be void*, which isn't true:
>
> https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/drivers/adc/adc_simple/src/main.c#L78
>
> This "api" test thinks buffer is u16*:
>
> https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/drivers/adc/adc_api/src/test_adc.c#L53
>
> The ADC-based grove temperature driver treats Zephyr samples as if
> they were 12 bit right aligned values in a u16 array, and has a
> comment saying that's the common convention:
>
> https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/grove/temperature_sensor.c#L46
>
> Can anyone clarify what the correct interpretation of this field is?
>

The alignment of the data within the buffer is unfortunately not the
only problem with this API. Also the meaning of the 'buffer_length'
field is pretty mysterious. I will not go into the details, suffice to
say that every single adc driver (we have a few of them already)
understands and implements it differently.

The fact that the implementation of ADC API among existing drivers is
incompatible is actually the smaller of the issues. The bigger problem
is that this API does not support typical use cases in a straightforward
way and neither takes into account capabilities of common hardware. IMHO
improving the documentation will not help much here. We should better
deprecate this API and come up with a new design.

Regards,
Piotr
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: [RFC] Issues with Zephyr Sensors API and ways to resolve them

Paul Sokolovsky
 

Hello Anas,

On Fri, 26 Jan 2018 00:36:17 +0000
"Nashif, Anas" <anas.nashif@intel.com> wrote:

I am fine with humidity unit change and now that I see the original
author’s reply I am more comfortable with this.\
Thanks, that sounds reassuring. I'll collect evidence on millimeter
-> meter switchover then ;-).

[]

Yes, the original author of Sensors API, Vlad Dogaru, replied on
Github and pointed that is the case
https://github.com/zephyrproject-rtos/zephyr/issues/5693#issuecomment-360461449 .
However, Linux uses milli-degrees for temperature, but we degrees.
[]


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: [RFC] Issues with Zephyr Sensors API and ways to resolve them

Nashif, Anas
 

I am fine with humidity unit change and now that I see the original author’s reply I am more comfortable with this.

Anas

On 26/01/2018, 02:10, "Paul Sokolovsky" <paul.sokolovsky@linaro.org> wrote:

Hello Anas,

On Thu, 25 Jan 2018 14:16:20 +0000
"Nashif, Anas" <anas.nashif@intel.com> wrote:

> Hi,
> If I remember correctly, the PCM units for humidity are coming from
> Linux sysfs.

Yes, the original author of Sensors API, Vlad Dogaru, replied on Github
and pointed that is the case
https://github.com/zephyrproject-rtos/zephyr/issues/5693#issuecomment-360461449 .
However, Linux uses milli-degrees for temperature, but we degrees.

> When this interface was originally proposed, it tried to
> follow a few things from the Linux world.
>
> See https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface
>
> In general and for other units, you really need to think about high
> accuracy sensors.

We don't have problems with that, allowing for precision of one
millionth of a unit. Of all physical (well, let's say "environmental")
quantities, relative humidity is the least to worry about re:
precision - it's a challenge to find a sensor offering precision
of 0.1 unit (unit being a percent).

> I do not think it is terribly bad how the units are
> defined as long as they are defined and are consistent. So this is
> basically not a bug, but if there is a general agreement that it
> should be changed and for a good reason other than avoiding
> additional calculation, I am fine with that.

They aren't consistent, that's the problem. It's not a bug indeed, but
an inconsistency, which can only become more glaring going forward.
Even now, few have few confused samples and even one driver which mix
up milli-percents and percents.

So far, nobody seems to object to the change, and it seems that's last
reasonable chance to do it, to allow one release of "stability" before
the expected 1.12 LTS.

>
> Anas
>

Thanks for the comments. Any thoughts on the 2 other points?

> 2. By extension, we may want to re-review unit of
> measurements used for other values too.
> 3. Definition of struct sensor_value is vague, leading to
> confusion.

[]
--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: [RFC] Issues with Zephyr Sensors API and ways to resolve them

Paul Sokolovsky
 

Hello Anas,

On Thu, 25 Jan 2018 14:16:20 +0000
"Nashif, Anas" <anas.nashif@intel.com> wrote:

Hi,
If I remember correctly, the PCM units for humidity are coming from
Linux sysfs.
Yes, the original author of Sensors API, Vlad Dogaru, replied on Github
and pointed that is the case
https://github.com/zephyrproject-rtos/zephyr/issues/5693#issuecomment-360461449 .
However, Linux uses milli-degrees for temperature, but we degrees.

When this interface was originally proposed, it tried to
follow a few things from the Linux world.

See https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface

In general and for other units, you really need to think about high
accuracy sensors.
We don't have problems with that, allowing for precision of one
millionth of a unit. Of all physical (well, let's say "environmental")
quantities, relative humidity is the least to worry about re:
precision - it's a challenge to find a sensor offering precision
of 0.1 unit (unit being a percent).

I do not think it is terribly bad how the units are
defined as long as they are defined and are consistent. So this is
basically not a bug, but if there is a general agreement that it
should be changed and for a good reason other than avoiding
additional calculation, I am fine with that.
They aren't consistent, that's the problem. It's not a bug indeed, but
an inconsistency, which can only become more glaring going forward.
Even now, few have few confused samples and even one driver which mix
up milli-percents and percents.

So far, nobody seems to object to the change, and it seems that's last
reasonable chance to do it, to allow one release of "stability" before
the expected 1.12 LTS.


Anas
Thanks for the comments. Any thoughts on the 2 other points?

2. By extension, we may want to re-review unit of
measurements used for other values too.
3. Definition of struct sensor_value is vague, leading to
confusion.
[]
--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

4481 - 4500 of 8521