Date   

Zephyr Project using Eclipse

Nicholas Yameen <Nicholas.Yameen@...>
 

Hello,

 

I want to develop applications using the FRDM-K64F board from NXP using Eclipse.  Is there any way to use Eclipse as an IDE and create a program, then flash it onto the board? I want to do my development all from Eclipse.  Or do is Eclipse only used as a debugger? Thank you.

 

Regards,

Nick

Nicholas Yameen
R&D Engineer

D  978-975-9675 x59675
E  Nicholas.Yameen@...

800 Federal Street
Andover, MA 01810
United States

Blog Blog Blog Blog Blog Blog Blog 

*Please consider the environment before printing this e-mail

 

 


Re: __ASSERT - transfer to error handler

Boie, Andrew P
 

I'm patiently waiting for a paradise times when on CPU exception, assert, etc.,
we'll be ending up in debugger, point to the instruction where the problem
happened (or it can be seen in backtrace).
We do dump this info to the console on a fatal CPU exception. On x86 there's even a crude stack trace.
But it would be nice, if running some application under GDB, for the exception to simply break the debugger at the offending instruction rather than go through Zephyr's exception handling path.

I'm not sure how this could work, perhaps have the Zephyr exception handler set up the stack/registers to the original context and issue a debug exception? Or would this involve some kind of Zephyr-aware extension to GDB? The problem is always that the stack layout for a CPU exception is different than a function call, and might not even be on the same stack, so you can't easily unwind through when the exception happened to the original faulting context.

Andrew


Re: __ASSERT - transfer to error handler

Boie, Andrew P
 

It's better to call k_oops() or k_panic() than _SysFatalErrorHandler() directly. You will actually get useful information about where the error occurred, instead of having to pass in a NULL exception stack frame.

 

Andrew

 

From: devel@... [mailto:devel@...] On Behalf Of Skøien, Kristoffer
Sent: Friday, November 9, 2018 12:11 AM
To: devel@...
Subject: [Zephyr-devel] __ASSERT - transfer to error handler

 

Current implementation:

The __ASSERT macro is extensively used in the Zephyr codebase and in application code for debugging during development.

In case of an ASSERT, the code jumps to __ASSERT_POST which spins the given thread in a while(1).

 

Issue:

During development and debugging, simply looping the thread will mask that the ASSERT has triggered. The only feedback the user gets of an assert is a printout.

This can be missed if e.g.:

- The RTT or Serial debug interface is down or unused

- There is too much logging so that the “ASSERTION FAIL” can be missed

 

Proposed solution:

In __ASSERT_POST provide a function call that will end up a user definable error handler. E.g. _SysFatalErrorHandler

 

This will let the developer set given SOC pins in case of an ASSERT, ask for a specific LED pattern to be set or print further debug messages.

 

Feedback is appreciated.

 

Kind regards

Kristoffer

 


Re: Zephyr: FDRM_K64f board from NXP

Florian Fouillet <Florian.Fouillet@...>
 

Thanks everyone, I will have a look at the DTS.

 

Cheers,

 

From: Diego Sueiro [mailto:diego.sueiro@...]
Sent: Friday, November 9, 2018 10:32 AM
To: Andrei <andrei.emeltchenko.news@...>
Cc: Florian Fouillet <Florian.Fouillet@...>; devel@...
Subject: Re: [Zephyr-devel] Zephyr: FDRM_K64f board from NXP

 

[External email: Use caution with links and attachments]


 

 

On Fri, 9 Nov 2018, 3:22 pm Andrei <andrei.emeltchenko.news@... wrote:

Hi,

On Fri, Nov 09, 2018 at 01:05:42PM +0000, Florian Fouillet wrote:
>    Hi,
>
>     
>
>    I am currently working on the Zephyr OS with a FDRM_K64f board from NXP. I
>    am just going through the documentation and the code example for now.
>
>    I have trouble to understand where is the implementation of the macro for
>    the Freedom board. For eample in the blinky project example
>    (zephyr/samples/basic/blinky/src/main.c) we have a #define LED
>    LED0_GPIO_PIN. we should have somewhere the definition of this
>    LED0_GPIO_PIN to match with the board I am using. however I don't know
>    where is this implementation. In addition of that, do you know where I can
>    find a list of every define like this LED0_GPIO_PIN. For example for PWM
>    or SPI or UART?

It is done somehow through DTS, you need to search i.e.
./zephyr/include/generated/generated_dts_board.h

 

Take a look at the documentation to understand how this process works:

 


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________


Re: Zephyr: FDRM_K64f board from NXP

Diego Sueiro
 


On Fri, 9 Nov 2018, 3:22 pm Andrei <andrei.emeltchenko.news@... wrote:
Hi,

On Fri, Nov 09, 2018 at 01:05:42PM +0000, Florian Fouillet wrote:
>    Hi,
>
>     
>
>    I am currently working on the Zephyr OS with a FDRM_K64f board from NXP. I
>    am just going through the documentation and the code example for now.
>
>    I have trouble to understand where is the implementation of the macro for
>    the Freedom board. For eample in the blinky project example
>    (zephyr/samples/basic/blinky/src/main.c) we have a #define LED
>    LED0_GPIO_PIN. we should have somewhere the definition of this
>    LED0_GPIO_PIN to match with the board I am using. however I don't know
>    where is this implementation. In addition of that, do you know where I can
>    find a list of every define like this LED0_GPIO_PIN. For example for PWM
>    or SPI or UART?

It is done somehow through DTS, you need to search i.e.
./zephyr/include/generated/generated_dts_board.h

Take a look at the documentation to understand how this process works:


Re: Zephyr: FDRM_K64f board from NXP

Andrei
 

Hi,

On Fri, Nov 09, 2018 at 01:05:42PM +0000, Florian Fouillet wrote:
Hi,

 

I am currently working on the Zephyr OS with a FDRM_K64f board from NXP. I
am just going through the documentation and the code example for now.

I have trouble to understand where is the implementation of the macro for
the Freedom board. For eample in the blinky project example
(zephyr/samples/basic/blinky/src/main.c) we have a #define LED
LED0_GPIO_PIN. we should have somewhere the definition of this
LED0_GPIO_PIN to match with the board I am using. however I don't know
where is this implementation. In addition of that, do you know where I can
find a list of every define like this LED0_GPIO_PIN. For example for PWM
or SPI or UART?
It is done somehow through DTS, you need to search i.e.
./zephyr/include/generated/generated_dts_board.h

Best regards
Andrei Emeltchenko


Zephyr: FDRM_K64f board from NXP

Florian Fouillet <Florian.Fouillet@...>
 

Hi,

 

I am currently working on the Zephyr OS with a FDRM_K64f board from NXP. I am just going through the documentation and the code example for now.

I have trouble to understand where is the implementation of the macro for the Freedom board. For eample in the blinky project example (zephyr/samples/basic/blinky/src/main.c) we have a #define LED LED0_GPIO_PIN. we should have somewhere the definition of this LED0_GPIO_PIN to match with the board I am using. however I don't know where is this implementation. In addition of that, do you know where I can find a list of every define like this LED0_GPIO_PIN. For example for PWM or SPI or UART?


Zephyr 1.13.0 HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle

Vieren Frank <F.Vieren@...>
 

Hallo Zephyr community,

 

Anyone knowing why the BD address is always the ZERO address, when using the nRF52 board running the Zephyr HCI uart hex.

I also see that the random address remains the same after power cycling the nRF board.

Also differences in showing the address for the HCI controller when running the bluetoothctl and hcitool dev commands.

 

Please see my findings described here in the Nordic Dev Zone, last reply in message queue.

 

https://devzone.nordicsemi.com/f/nordic-q-a/22194/read-or-change-nrf51-mac-address-on-zephyr/156634#156634

 

Any feedback is very welcome,

Thanks in advance,

Frank


__ASSERT - transfer to error handler

Skøien, Kristoffer <Kristoffer.Skoien@...>
 

Current implementation:

The __ASSERT macro is extensively used in the Zephyr codebase and in application code for debugging during development.

In case of an ASSERT, the code jumps to __ASSERT_POST which spins the given thread in a while(1).

 

Issue:

During development and debugging, simply looping the thread will mask that the ASSERT has triggered. The only feedback the user gets of an assert is a printout.

This can be missed if e.g.:

- The RTT or Serial debug interface is down or unused

- There is too much logging so that the “ASSERTION FAIL” can be missed

 

Proposed solution:

In __ASSERT_POST provide a function call that will end up a user definable error handler. E.g. _SysFatalErrorHandler

 

This will let the developer set given SOC pins in case of an ASSERT, ask for a specific LED pattern to be set or print further debug messages.

 

Feedback is appreciated.

 

Kind regards

Kristoffer


Re: __ASSERT - transfer to error handler

kristoffer.skoien@...
 

Thanks for your reply Paul.

Perhaps something simliar to this:

#if defined(CONFIG_ARCH_POSIX)
extern void posix_exit(int exit_code);
#define __ASSERT_POST posix_exit(1)
#elif defined(CONFIG_ASSERT_ERR_HANDLER)
#define __ASSERT_POST _SysFatalErrorHandler(?,?)
#else
#define __ASSERT_POST             \
for (;;) {                \
/* spin thread */ \
}
#endif


Re: Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle #nrf52832

Carles Cufi
 

Hi there,

 

The *public* address is all zeroes because Nordic ICs do not come with one pre-assigned. The *random static* address is set by BlueZ itself, so it will be whatever BlueZ decides it to be.

You don’t typically need a public address to work with BLE.

 

Carles

 

From: devel@... <devel@...> On Behalf Of frv
Sent: 09 November 2018 11:49
To: Zephyr-devel@...
Subject: [Zephyr-devel] Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle #nrf52832

 

Hallo Zephyr community,

 

Anyone knowing why the BD address is always the ZERO address, when using the nRF52 board running the Zephyr HCI uart hex.

I also see that the random address remains the same after power cycling the nRF board.

Also differences in showing the address for the HCI controller when running the bluetoothctl and hcitool dev commands.

Nor using the hcitool or btmgmt tool makes it possible to adjust the addressing, only so far the hcitool cmd 0x3f 0x006 address makes a difference as long as the board is not power cycled (as the setting is volatile, the default non volatile addresses to zero it seems).

 

Please see my findings described more in detail here in the Nordic Dev Zone, last reply in the message queue.

 

https://devzone.nordicsemi.com/f/nordic-q-a/22194/read-or-change-nrf51-mac-address-on-zephyr/156634#156634

 

Any feedback is very welcome,

Thanks in advance,

Frank


Re: __ASSERT - transfer to error handler

Paul Sokolovsky
 

Hello Kristoffer,

As a quick reply, definitely ack on the problem statement. I can say
more, I'm patiently waiting for a paradise times when on CPU exception,
assert, etc., we'll be ending up in debugger, point to the instruction
where the problem happened (or it can be seen in backtrace). (To be
exact, I'm talking about running in QEMU first of all, I actually
don't remember how that works on real hw.)

As for specific implementation, perhaps more knowledgeable people can
comment. I would just point that an obvious override point is
__ASSERT_POST macro itself. I.e. instead of defining it
unconditionally, we can have #ifdef around it, and let a user override
it before inclusion of Zephyr headers. That's the simplest, but
perhaps not the most scalable solution.


On Fri, 09 Nov 2018 01:39:34 -0800
kristoffer.skoien@nordicsemi.no wrote:

Current implementation:

The __ASSERT macro is extensively used in the Zephyr code base and in
application code for debugging during development.

In case of an ASSERT, the code jumps to __ASSERT_POST which spins the
given thread in a while(1).

 

Issue:

During development and debugging, simply looping the thread will mask
that the ASSERT has triggered. The only feedback the user gets of an
assert is a printout.

This can be missed if e.g.:

- The RTT or Serial debug interface is down or unused

- There is too much logging so that the “ASSERTION FAIL” can be missed

 

Proposed solution:

In __ASSERT_POST provide a function call that will end up a user
definable error handler. E.g. _SysFatalErrorHandler()

 

This will let the developer set given SOC pins in case of an ASSERT,
ask for a specific LED pattern to be set or print further debug
messages.

 

Feedback is appreciated.

 

Kind regards

Kristoffer




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


Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle #nrf52832

frv
 

Hallo Zephyr community,

 

Anyone knowing why the BD address is always the ZERO address, when using the nRF52 board running the Zephyr HCI uart hex.

I also see that the random address remains the same after power cycling the nRF board.

Also differences in showing the address for the HCI controller when running the bluetoothctl and hcitool dev commands.

Nor using the hcitool or btmgmt tool makes it possible to adjust the addressing, only so far the hcitool cmd 0x3f 0x006 address makes a difference as long as the board is not power cycled (as the setting is volatile, the default non volatile addresses to zero it seems).

 

Please see my findings described more in detail here in the Nordic Dev Zone, last reply in the message queue.

 

https://devzone.nordicsemi.com/f/nordic-q-a/22194/read-or-change-nrf51-mac-address-on-zephyr/156634#156634

 

Any feedback is very welcome,

Thanks in advance,

Frank


Re: #nrf52840 #ble unstable connection #nrf52840 #ble

Chettimada, Vinayak Kariappa
 

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

Could you please test the PR on your board and let me know if its better.

Find attach the patch file as alternative to the diff in PR. Use "git am <patch file>" to apply the changes on latest zephyr master branch.

-Vinayak

-----Original Message-----
From: Randy Chou <rchou3@logitech.com>
Date: Friday, 9 November 2018 at 9:22 AM
To: Vinayak Chettimada <vinayak.kariappa.chettimada@nordicsemi.no>
Cc: "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>, Nestor Lopez Casado <nlopezcasad@logitech.com>
Subject: Re: [Zephyr-devel] #nrf52840 #ble unstable connection

Hi Vinayak,
Thanks for your reply. If you have any idea about this issue I can do the tests from my site.


Regards,
Randy


Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> 於 2018年11月8日 週四 下午6:17寫道:


Your config file looks ok.

I will check if errata 201 will solve your issues. I will try to send you a patch by this weekend.
As I will need to reproduce the issue, you will need to help me if it is the root cause. (with my DK, I did not see issues for hours before I had to be away from my desk).

- Vinayak

-----Original Message-----
From: <devel@lists.zephyrproject.org> on behalf of Randy Chou <rchou3@logitech.com>
Date: Wednesday, 7 November 2018 at 11:12 AM
To: "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] #nrf52840 #ble unstable connection




Hi Vinayak,
I did some test today by using the latest master, there is no connection parameter update that means the CI keeps in 7.5ms, the connection keeps alive.
I try to update the CI to 30ms manually the connection can keep around 6.5 mins.
attachment is my .config file.

Thanks,
Randy


__ASSERT - transfer to error handler

kristoffer.skoien@...
 

Current implementation:

The __ASSERT macro is extensively used in the Zephyr code base and in application code for debugging during development.

In case of an ASSERT, the code jumps to __ASSERT_POST which spins the given thread in a while(1).

 

Issue:

During development and debugging, simply looping the thread will mask that the ASSERT has triggered. The only feedback the user gets of an assert is a printout.

This can be missed if e.g.:

- The RTT or Serial debug interface is down or unused

- There is too much logging so that the “ASSERTION FAIL” can be missed

 

Proposed solution:

In __ASSERT_POST provide a function call that will end up a user definable error handler. E.g. _SysFatalErrorHandler()

 

This will let the developer set given SOC pins in case of an ASSERT, ask for a specific LED pattern to be set or print further debug messages.

 

Feedback is appreciated.

 

Kind regards

Kristoffer


Re: #nrf52840 #ble unstable connection #nrf52840 #ble

Randy Chou <rchou3@...>
 

Hi Vinayak,
Thanks for your reply. If you have any idea about this issue I can do the tests from my site.

Regards,
Randy

Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> 於 2018年11月8日 週四 下午6:17寫道:

Your config file looks ok.

I will check if errata 201 will solve your issues. I will try to send you a patch by this weekend.
As I will need to reproduce the issue, you will need to help me if it is the root cause. (with my DK, I did not see issues for hours before I had to be away from my desk).

- Vinayak

-----Original Message-----
From: <devel@...> on behalf of Randy Chou <rchou3@...>
Date: Wednesday, 7 November 2018 at 11:12 AM
To: "devel@..." <devel@...>
Subject: Re: [Zephyr-devel] #nrf52840 #ble unstable connection




    Hi Vinayak,
    I did some test today by using the latest master, there is no connection parameter update that means the CI keeps in 7.5ms, the connection keeps alive.
    I try to update the CI to 30ms manually the connection can keep around 6.5 mins.
    attachment is my .config file.

    Thanks,
    Randy


Re: NRF52832 - setting up NFFS for the external flash W25QXXDV

Johannes Hutter
 

Hey Faisal,

we recently had trouble with the Winbond driver as well, but in the context of FCB and NVS. Something we found is that the current driver doesn't support writing across write pages. So if you call the write function, but the write would cross one of the write page boundaries, the remaining part on the second page is not written. However, we use a W25QxxFV flash, not the DV, so YMMV. We added PRs for the page layout implementation (https://github.com/zephyrproject-rtos/zephyr/pull/11114) as well as writing across write page boundaries (https://github.com/zephyrproject-rtos/zephyr/pull/11113). Maybe this helps.

Best Regards
Joe


On Wed, Nov 7, 2018 at 10:54 PM <faisal.saleem@...> wrote:
Hi

At the moment I am struggling to mount W25QXXDV external flash as NFFS. We have a custom board with nrf52832 connected to the external spi flash W25QXXDV. So Zephyr provides the driver for W25qxxdv, but without page layout implementation. I modified the driver by adding page layout support, simply copied from the nrf flash layout implementation.. given the size is 2MB, page size kept to 4096.. makes 512 pages... please correct me if I shouldn't be doing it... If I don't do it then I get kernel panic because there is no implementation. I know that PAGE_LAYOUT should be disabled to avoid it but one of the settings is overriding PAGE_LAYOUT to be activated even if I disable it.. 

#if defined(CONFIG_FLASH_PAGE_LAYOUT)
static struct flash_pages_layout dev_layout;
 
static void flash_W25QXXDV_pages_layout(struct device *dev,
     const struct flash_pages_layout **layout,
     size_t *layout_size)
{
dev_layout.pages_count = 512;
dev_layout.pages_size = 4096;
*layout = &dev_layout;
*layout_size = 1;
}
#endif /* CONFIG_FLASH_PAGE_LAYOUT */
 
static const struct flash_driver_api spi_flash_api = {
.read = spi_flash_wb_read,
.write = spi_flash_wb_write,
.erase = spi_flash_wb_erase,
.write_protection = spi_flash_wb_write_protection_set,
#if defined(CONFIG_FLASH_PAGE_LAYOUT)
#if 0
.page_layout = (flash_api_pages_layout)
       flash_page_layout_not_implemented,
#else
.page_layout = flash_W25QXXDV_pages_layout,
#endif
#endif
.write_block_size = 1};

I could also see that the nffs_mount function inside nffs_fs.c has hardcoded the flash id to 0.. does it indicate that NFFS is to be implemented only the internal flash... I have disabled that bit here and I am setting  "flash_desc" before entering the function and passing it through the input argument "mountp"... Please correct if my understanding is wrong.. e.g., 
                flash_desc.id = 1;
flash_desc.sector_count = flash_get_page_count(flash_dev);
flash_desc.area_offset = 0; //1044480;
flash_desc.area_size = 1048576;   //even though it is 2MB, I am only using 1MB for now...

static int nffs_mount(struct fs_mount_t *mountp)
{
struct nffs_flash_desc *flash_desc =
(struct nffs_flash_desc *)mountp->fs_data;
int cnt;
int rc;
 
/* Set flash device */
flash_dev = (struct device *)mountp->storage_dev;
 
/* Set flash descriptor fields */
#if 0
flash_desc->id = 0;
flash_desc->sector_count = flash_get_page_count(flash_dev);
flash_desc->area_offset = FLASH_AREA_STORAGE_OFFSET;
flash_desc->area_size = FLASH_AREA_STORAGE_SIZE;
#endif
rc = nffs_misc_reset();
if (rc) {
return -EIO;
}
 
cnt = CONFIG_NFFS_FILESYSTEM_MAX_AREAS;
rc = nffs_misc_desc_from_flash_area(flash_desc, &cnt, descs);
if (rc) {
return -EIO;
}
 
rc = nffs_restore_full(descs);
switch (rc) {
case 0:
break;
case FS_ECORRUPT:
rc = nffs_format_full(descs);
if (rc) {
return -EIO;
}
break;
default:
return -EIO;
}
 
return 0;}
So I could see that there is no "Lost+Found" directory inside the external flash, and when it tries to create it, it fails while writing.. thus I am getting -5 (EIO) message when I am trying to mount it...
Inside "nffs_restore_full" function, it does nffs_restore_area_contents(..) ... I could see activity on the pins when I probe it.. then it ensures that the file system contains a valid scratch area... then it ensures that the file system contains a valid root directory.. finally when it is trying to confirm, if there is a lost+found directory,.. which is not there, so it tries to create it and in turn writes to it, which fails... and it fails to mount...


my prj.conf looks like


CONFIG_FLASH_HAS_DRIVER_ENABLED=y
CONFIG_FLASH_HAS_PAGE_LAYOUT=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_SOC_FLASH_NRF=y
CONFIG_SOC_FLASH_NRF_RADIO_SYNC=y
CONFIG_SPI_FLASH_W25QXXDV=y
CONFIG_SPI_FLASH_W25QXXDV_SPI_NAME="SPI_1"
CONFIG_SPI_FLASH_W25QXXDV_DRV_NAME="W25QXXDV"
CONFIG_SPI_FLASH_W25QXXDV_INIT_PRIORITY=80
CONFIG_SPI_FLASH_W25QXXDV_SPI_FREQ_0=1000000
CONFIG_SPI_FLASH_W25QXXDV_SPI_SLAVE=1
CONFIG_SPI_FLASH_W25QXXDV_GPIO_SPI_CS=y
CONFIG_SPI_FLASH_W25QXXDV_GPIO_SPI_CS_DRV_NAME="GPIO_0"
CONFIG_SPI_FLASH_W25QXXDV_GPIO_SPI_CS_PIN=29
CONFIG_SPI_FLASH_W25QXXDV_GPIO_CS_WAIT_DELAY=50
CONFIG_SPI_FLASH_W25QXXDV_FLASH_SIZE=2097152
CONFIG_SPI_FLASH_W25QXXDV_DEVICE_ID=0x00ef4015
CONFIG_FS_FLASH_STORAGE_PARTITION=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y
CONFIG_FS_NFFS_FLASH_DEV_NAME="W25QXXDV"
CONFIG_FILE_SYSTEM=y
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_INODES=64
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=64
CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE=128

If there is an example where we are utilizing both internal and external flash as NFFS, that would be useful... 

Below is my dts file... I have modified it and I can easily make the internal flash work correctly as NFFS.. I can easily upload and download a file into the internal flash via mynewt from our mac computer, size around 23k. I had to reduce the maximum data chunk size for file upload and download from 512 to 256 or else it would give me errors and would never finish the transfer... Now I want to store images into the external flash which is why i need to setup NFFS on it..  


/dts-v1/;
#include <nordic/nrf52832.dtsi>
 
/ {
model = "Nordic PCA10040 Dev Kit";
compatible = "nordic,pca10040-dk", "nordic,nrf52832-qfaa",
     "nordic,nrf52832";
 
chosen {
zephyr,console = &uart0;
#ifdef CONFIG_MCUMGR_SMP_UART
zephyr,uart-mcumgr = &uart0;
#endif
zephyr,sram = &sram0;
zephyr,flash = &flash0;
};
};
 
&adc {
status ="ok";
};
 
&gpiote {
status ="ok";
};
 
&gpio0 {
status ="ok";
};
 
&uart0 {
status = "ok";
compatible = "nordic,nrf-uart";
current-speed = <115200>;
};
 
&i2c0 {
status = "ok";
sda-pin = <26>;
scl-pin = <27>;
};
 
&i2c1 {
status = "ok";
sda-pin = <30>;
scl-pin = <31>;
};
 
&flash0 {
/*
* For more information, see:
*/
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
 
boot_partition: partition@0 {
label = "mcuboot";
reg = <0x00000000 0xc000>;
};
slot0_partition: partition@c000 {
label = "image-0";
reg = <0x0000C000 0x32000>;
};
slot1_partition: partition@3e000 {
label = "image-1";
reg = <0x0003E000 0x32000>;
};
scratch_partition: partition@70000 {
label = "image-scratch";
reg = <0x00070000 0xa000>;
};
 
#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
storage_partition: partition@7a000 {
label = "storage";
reg = <0x0007a000 0x00006000>;
};
#endif
};
};


Any help is appreciated, Thanks

Faisal



--

Johannes Hutter
Mail: johannes@... 


Workaround GmbH (ProGlove)  
Friedenstr. 4 | 81671 München

Managing Director: Thomas Kirchner 
HRB: 216605 | AG München 
USt.-IdNr.: DE298859320



Re: #nrf52840 #ble unstable connection #nrf52840 #ble

Chettimada, Vinayak Kariappa
 

Your config file looks ok.

I will check if errata 201 will solve your issues. I will try to send you a patch by this weekend.
As I will need to reproduce the issue, you will need to help me if it is the root cause. (with my DK, I did not see issues for hours before I had to be away from my desk).

- Vinayak

-----Original Message-----
From: <devel@lists.zephyrproject.org> on behalf of Randy Chou <rchou3@logitech.com>
Date: Wednesday, 7 November 2018 at 11:12 AM
To: "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] #nrf52840 #ble unstable connection




Hi Vinayak,
I did some test today by using the latest master, there is no connection parameter update that means the CI keeps in 7.5ms, the connection keeps alive.
I try to update the CI to 30ms manually the connection can keep around 6.5 mins.
attachment is my .config file.

Thanks,
Randy


Re: usb device network on nrf52840 platform

cpmcparland@...
 

Jukka,

Thanks...learn something new everyday!  This is also a reason for NOT renaming the .conf file for
your project to something unique....which, of course, I did on my first project!

Cheers,
Chuck McP


NRF52832 - setting up NFFS for the external flash W25QXXDV

faisal.saleem@...
 

Hi

At the moment I am struggling to mount W25QXXDV external flash as NFFS. We have a custom board with nrf52832 connected to the external spi flash W25QXXDV. So Zephyr provides the driver for W25qxxdv, but without page layout implementation. I modified the driver by adding page layout support, simply copied from the nrf flash layout implementation.. given the size is 2MB, page size kept to 4096.. makes 512 pages... please correct me if I shouldn't be doing it... If I don't do it then I get kernel panic because there is no implementation. I know that PAGE_LAYOUT should be disabled to avoid it but one of the settings is overriding PAGE_LAYOUT to be activated even if I disable it.. 

#if defined(CONFIG_FLASH_PAGE_LAYOUT)
static struct flash_pages_layout dev_layout;
 
static void flash_W25QXXDV_pages_layout(struct device *dev,
     const struct flash_pages_layout **layout,
     size_t *layout_size)
{
dev_layout.pages_count = 512;
dev_layout.pages_size = 4096;
*layout = &dev_layout;
*layout_size = 1;
}
#endif /* CONFIG_FLASH_PAGE_LAYOUT */
 
static const struct flash_driver_api spi_flash_api = {
.read = spi_flash_wb_read,
.write = spi_flash_wb_write,
.erase = spi_flash_wb_erase,
.write_protection = spi_flash_wb_write_protection_set,
#if defined(CONFIG_FLASH_PAGE_LAYOUT)
#if 0
.page_layout = (flash_api_pages_layout)
       flash_page_layout_not_implemented,
#else
.page_layout = flash_W25QXXDV_pages_layout,
#endif
#endif
.write_block_size = 1};

I could also see that the nffs_mount function inside nffs_fs.c has hardcoded the flash id to 0.. does it indicate that NFFS is to be implemented only the internal flash... I have disabled that bit here and I am setting  "flash_desc" before entering the function and passing it through the input argument "mountp"... Please correct if my understanding is wrong.. e.g., 
                flash_desc.id = 1;
flash_desc.sector_count = flash_get_page_count(flash_dev);
flash_desc.area_offset = 0; //1044480;
flash_desc.area_size = 1048576;   //even though it is 2MB, I am only using 1MB for now...

static int nffs_mount(struct fs_mount_t *mountp)
{
struct nffs_flash_desc *flash_desc =
(struct nffs_flash_desc *)mountp->fs_data;
int cnt;
int rc;
 
/* Set flash device */
flash_dev = (struct device *)mountp->storage_dev;
 
/* Set flash descriptor fields */
#if 0
flash_desc->id = 0;
flash_desc->sector_count = flash_get_page_count(flash_dev);
flash_desc->area_offset = FLASH_AREA_STORAGE_OFFSET;
flash_desc->area_size = FLASH_AREA_STORAGE_SIZE;
#endif
rc = nffs_misc_reset();
if (rc) {
return -EIO;
}
 
cnt = CONFIG_NFFS_FILESYSTEM_MAX_AREAS;
rc = nffs_misc_desc_from_flash_area(flash_desc, &cnt, descs);
if (rc) {
return -EIO;
}
 
rc = nffs_restore_full(descs);
switch (rc) {
case 0:
break;
case FS_ECORRUPT:
rc = nffs_format_full(descs);
if (rc) {
return -EIO;
}
break;
default:
return -EIO;
}
 
return 0;}
So I could see that there is no "Lost+Found" directory inside the external flash, and when it tries to create it, it fails while writing.. thus I am getting -5 (EIO) message when I am trying to mount it...
Inside "nffs_restore_full" function, it does nffs_restore_area_contents(..) ... I could see activity on the pins when I probe it.. then it ensures that the file system contains a valid scratch area... then it ensures that the file system contains a valid root directory.. finally when it is trying to confirm, if there is a lost+found directory,.. which is not there, so it tries to create it and in turn writes to it, which fails... and it fails to mount...


my prj.conf looks like


CONFIG_FLASH_HAS_DRIVER_ENABLED=y
CONFIG_FLASH_HAS_PAGE_LAYOUT=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_SOC_FLASH_NRF=y
CONFIG_SOC_FLASH_NRF_RADIO_SYNC=y
CONFIG_SPI_FLASH_W25QXXDV=y
CONFIG_SPI_FLASH_W25QXXDV_SPI_NAME="SPI_1"
CONFIG_SPI_FLASH_W25QXXDV_DRV_NAME="W25QXXDV"
CONFIG_SPI_FLASH_W25QXXDV_INIT_PRIORITY=80
CONFIG_SPI_FLASH_W25QXXDV_SPI_FREQ_0=1000000
CONFIG_SPI_FLASH_W25QXXDV_SPI_SLAVE=1
CONFIG_SPI_FLASH_W25QXXDV_GPIO_SPI_CS=y
CONFIG_SPI_FLASH_W25QXXDV_GPIO_SPI_CS_DRV_NAME="GPIO_0"
CONFIG_SPI_FLASH_W25QXXDV_GPIO_SPI_CS_PIN=29
CONFIG_SPI_FLASH_W25QXXDV_GPIO_CS_WAIT_DELAY=50
CONFIG_SPI_FLASH_W25QXXDV_FLASH_SIZE=2097152
CONFIG_SPI_FLASH_W25QXXDV_DEVICE_ID=0x00ef4015
CONFIG_FS_FLASH_STORAGE_PARTITION=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y
CONFIG_FS_NFFS_FLASH_DEV_NAME="W25QXXDV"
CONFIG_FILE_SYSTEM=y
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_INODES=64
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=64
CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE=128

If there is an example where we are utilizing both internal and external flash as NFFS, that would be useful... 

Below is my dts file... I have modified it and I can easily make the internal flash work correctly as NFFS.. I can easily upload and download a file into the internal flash via mynewt from our mac computer, size around 23k. I had to reduce the maximum data chunk size for file upload and download from 512 to 256 or else it would give me errors and would never finish the transfer... Now I want to store images into the external flash which is why i need to setup NFFS on it..  


/dts-v1/;
#include <nordic/nrf52832.dtsi>
 
/ {
model = "Nordic PCA10040 Dev Kit";
compatible = "nordic,pca10040-dk", "nordic,nrf52832-qfaa",
     "nordic,nrf52832";
 
chosen {
zephyr,console = &uart0;
#ifdef CONFIG_MCUMGR_SMP_UART
zephyr,uart-mcumgr = &uart0;
#endif
zephyr,sram = &sram0;
zephyr,flash = &flash0;
};
};
 
&adc {
status ="ok";
};
 
&gpiote {
status ="ok";
};
 
&gpio0 {
status ="ok";
};
 
&uart0 {
status = "ok";
compatible = "nordic,nrf-uart";
current-speed = <115200>;
};
 
&i2c0 {
status = "ok";
sda-pin = <26>;
scl-pin = <27>;
};
 
&i2c1 {
status = "ok";
sda-pin = <30>;
scl-pin = <31>;
};
 
&flash0 {
/*
* For more information, see:
* http://docs.zephyrproject.org/devices/dts/flash_partitions.html
*/
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
 
boot_partition: partition@0 {
label = "mcuboot";
reg = <0x00000000 0xc000>;
};
slot0_partition: partition@c000 {
label = "image-0";
reg = <0x0000C000 0x32000>;
};
slot1_partition: partition@3e000 {
label = "image-1";
reg = <0x0003E000 0x32000>;
};
scratch_partition: partition@70000 {
label = "image-scratch";
reg = <0x00070000 0xa000>;
};
 
#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
storage_partition: partition@7a000 {
label = "storage";
reg = <0x0007a000 0x00006000>;
};
#endif
};
};


Any help is appreciated, Thanks

Faisal

2361 - 2380 of 7734