Date   

Zephyr and LoRaWAN stack

Nikos Karamolegkos <nkaram@...>
 

Hello everyone,

As I can see in the documentation of the zephyr, zephyr supports Dragino LSN50 LoRA Sensor Node. I would like to ask if the code of the LoRaWAN stack is available in the github for this node or should be developed?

Thank you,
Nikos

--
Nikos Karamolegkos
R & D Engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Re: Dragino LSN50 and STLink

Erwan Gouriou
 

Hi Gustavo,

Sorry, I'm not familiar with Dragino, nor J-Link, maybe Endre would know better, as he did the board port.

Erwan



On Wed, 8 May 2019 at 19:35, Gustavo F N <gustavofn@...> wrote:
Awesome, thanks! 

On Wed, May 8, 2019 at 6:55 AM Kumar Gala <kumar.gala@...> wrote:
Adding 2 people who might be able to help.

- k

> On May 7, 2019, at 1:29 PM, Gustavo FN <gustavofn@...> wrote:
>
> Hello everyone,
>
> I noticed the Dragino LSN50 board has been ported to Zephyr and that's pretty cool.
>
> I have one of this board and following the page https://docs.zephyrproject.org/latest/boards/arm/dragino_lsn50/doc/index.html#flashing-an-application-to-dragino-lsn50 they say 'Connect the Dragino LSN50 to a STLinkV2...'.
>
> Since the the board has no dedicated connect to JTAG/SWD, I read the stm32l072cz datasheet and found out the the SWDIO is PA13 and SWCLK is PA14.
>
> I connected these pins at my J-Link Ultra in the following way:
> JTAG -> LSN50
> pin 6 -> pin GND
> pin 7 -> pin PA13 (SWDIO)
> pin 9 -> pin  PA14
> pin 19 -> pin VDD (+3.3V)
>
> And tried to connect the Ozone but it did not work. At Ozone, in J-Link Settings I have the target device: STM32L072CZ, Target Interface: SWD:auto speed and Host Interface: USB.
>
> If someone knows how to connect the LSN50 board and could explain me I'll be very grateful.
>
> All the best,


Re: Dragino LSN50 and STLink

Gustavo FN
 

Awesome, thanks! 

On Wed, May 8, 2019 at 6:55 AM Kumar Gala <kumar.gala@...> wrote:
Adding 2 people who might be able to help.

- k

> On May 7, 2019, at 1:29 PM, Gustavo FN <gustavofn@...> wrote:
>
> Hello everyone,
>
> I noticed the Dragino LSN50 board has been ported to Zephyr and that's pretty cool.
>
> I have one of this board and following the page https://docs.zephyrproject.org/latest/boards/arm/dragino_lsn50/doc/index.html#flashing-an-application-to-dragino-lsn50 they say 'Connect the Dragino LSN50 to a STLinkV2...'.
>
> Since the the board has no dedicated connect to JTAG/SWD, I read the stm32l072cz datasheet and found out the the SWDIO is PA13 and SWCLK is PA14.
>
> I connected these pins at my J-Link Ultra in the following way:
> JTAG -> LSN50
> pin 6 -> pin GND
> pin 7 -> pin PA13 (SWDIO)
> pin 9 -> pin  PA14
> pin 19 -> pin VDD (+3.3V)
>
> And tried to connect the Ozone but it did not work. At Ozone, in J-Link Settings I have the target device: STM32L072CZ, Target Interface: SWD:auto speed and Host Interface: USB.
>
> If someone knows how to connect the LSN50 board and could explain me I'll be very grateful.
>
> All the best,


Re: mcuboot + dfu-util on nRF52840 not able to update firmware

Adam Mooers
 

I am able to replicate this problem with Zephyr v1.14.0 and nrf52840 PCA10056 hardware rev 1.1.0. The same "Error during download get_status" error occurred while flashing to slot 1.

Host Configuration:

    • Ubuntu 16.04 fully updated

Bootloader Configuration:

    Environment:
        • MCUboot 1.2 compiled with Zephyr SDK 0.9.5 and Zephyr OS v1.13.00
  
    Build Steps:
        • cd boot/zephyr
        • mkdir build && cd build
        • cmake -GNinja -DBOARD=nrf52840_pca10056  ..
        • ninja
        • ninja flash

    These instructions mirror https://mcuboot.com/mcuboot/readme-zephyr.html. The source was not modified.

Slot 0 Configuration:

    Environment:
        - Zephyr SDK 0.10.0 and Zephyr OS v1.14.00

    prj.conf:
        CONFIG_LOG=y
        CONFIG_LOG_OVERRIDE_LEVEL=4
        CONFIG_STDOUT_CONSOLE=y

        CONFIG_USB=y
        CONFIG_USB_DEVICE_STACK=y
        CONFIG_USB_DFU_CLASS=y

        CONFIG_BOOTLOADER_MCUBOOT=y
        CONFIG_IMG_MANAGER=y
        CONFIG_MCUBOOT_IMG_MANAGER=y

        CONFIG_USB_DEVICE_VID=0x167f
        CONFIG_USB_DEVICE_PID=0x3001
        CONFIG_USB_DEVICE_MANUFACTURER="Company"
        CONFIG_USB_DEVICE_PRODUCT="Product"
        CONFIG_USB_DEVICE_SN="123abc"

    source:
        #include <zephyr.h>
        #include <misc/printk.h>

        void main(void)
        {
            printk("Hello World!\n");
        }

    Build steps
        • source zephyr/zephyr/zephyr-env.sh
        • mkdir -p build/nrf52840_pca10056 && cd build/nrf52840_pca10056
        • cmake -GNinja -DBOARD=nrf52840_pca10056 -Dapp_VERSION_BUILD=9999 ../..
        • ninja
        • ~/repos/mcuboot/scripts/imgtool.py sign --key ~/repos/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 -S 0x69000 ./zephyr/zephyr.hex signed-hello.hex
        • nrfjprog --family NRF52 --program signed-hello.hex --sectorerase

Procedure for uploading new firmware:

    • The nrf USB cable was connected first followed by the segger USB cable. A reset via the button on the board directly preceded the logs below. The full log is attached.

            ***** Booting Zephyr OS zephyr-v1.13.0 *****
            ***** Booting Zephyr OS zephyr-v1.14.0 *****
            Hello World!
            [00:00:00.005,035] <dbg> usb_descriptor.ascii7_to_utf16le: char g : 67, idx 3 -> 7
            --- 66 messages dropped ---
            [00:00:00.005,096] <dbg> usb_descriptor.ascii7_to_utf16le: char i : 69, idx 0 -> 1
            [00:00:00.005,126] <dbg> usb_descriptor.ascii7_to_utf16le: idx_max 13, ascii_idx_max 6, buf 2000362f
            [00:00:00.005,157] <dbg> usb_descriptor.ascii7_to_utf16le: char 0 : 30, idx 6 -> 13
            [00:00:00.005,157] <dbg> usb_descriptor.ascii7_to_utf16le: char - : 2d, idx 5 -> 11
            [00:00:00.005,187] <dbg> usb_descriptor.ascii7_to_utf16le: char e : 65, idx 4 -> 9
            [00:00:00.005,218] <dbg> usb_descriptor.ascii7_to_utf16le: char g : 67, idx 3 -> 7
            [00:00:00.005,218] <dbg> usb_descriptor.ascii7_to_utf16le: char a : 61, idx 2 -> 5
            [00:00:00.005,249] <dbg> usb_descriptor.ascii7_to_utf16le: char m : 6d, idx 1 -> 3
            [00:00:00.005,279] <dbg> usb_descriptor.ascii7_to_utf16le: char i : 69, idx 0 -> 1
            [00:00:00.005,493] <dbg> usb_nrfx.usbd_work_process_pwr_events: USB detected
            ...

    • ~/repos/mcuboot/scripts/imgtool.py sign --key ~/repos/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 -S 0x69000 ./zephyr/zephyr.bin signed-hello.bin
    • sudo dfu-util --alt 1 --download signed-hello.bin
           

Result:

    • dfu-util detects the monitor and attempts to download firmware but fails after a timeout.

            dfu-util 0.8

            Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
            Copyright 2010-2014 Tormod Volden and Stefan Schmidt
            This program is Free Software and has ABSOLUTELY NO WARRANTY
            Please report bugs to dfu-util@...

            dfu-util: Invalid DFU suffix signature
            dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
            Opening DFU capable USB device...
            ID 167f:3001
            Run-time device DFU version 0110
            Claiming USB DFU Runtime Interface...
            Determining device status: state = appIDLE, status = 0
            Device really in Runtime Mode, send DFU detach request...
            Resetting USB...
            Opening DFU USB Device...
            Claiming USB DFU Interface...
            Setting Alternate Setting #1 ...
            Determining device status: state = dfuIDLE, status = 0
            dfuIDLE, continuing
            DFU mode device DFU version 0110
            Device returned transfer size 64
            Copying data from PC to DFU device
            Download    [                         ]   0%            0 bytesdfu-util: Error during download get_status

    • The nrf52840 shows a hardware exception (the full log is attached):

            [00:07:45.671,081] <dbg> usb_nrfx.usb_dc_ep_write: ep_write: ep 128, len 0
            [00:07:45.671,508] <dbg> usb_nrfx.usbd_work_process_setup: SETUP: r:3 rt:161 v:0 i:0 l:6
            [00:07:45.671,508] <dbg> usb_device.usb_handle_control_transfer: ep 0, status 0
            [00:07:45.671,508] <dbg> usb_nrfx.usb_dc_ep_read: ep_read: ep 0, maxlen 8
            [00:07:45.671,539] <dbg> usb_device.usb_handle_request: ** 1 **
            [00:07:45.671,569] <dbg> usb_dfu.dfu_class_handle_req: DFU_GETSTATUS: status 0, state 4
            [00:07:45.671,569] <dbg> usb_nrfx.usb_dc_ep_write: ep_write: ep 128, len 6
            [00:07:45.671,661] <dbg> usb_nrfx.usbd_event_transfer_ctrl: ctrl write complete
            ***** BUS FAULT *****
              Instruction bus error
            ***** Hardware exception *****
            Current thread ID = 0x20001824
            Faulting instruction address = 0x9f38018
            Fatal fault in thread 0x20001824! Aborting.
            07:45.670,654] <dbg> usb_nrfx.usbd_work_process_setup: SETUP: r:1 rt:33 v:0 i:0 l:64

    • dmesg shows nothing related to the crash. It does detect the USB device initial connect:

            [260966.516923] usb 1-2: new full-speed USB device number 55 using xhci_hcd
            [260966.669260] usb 1-2: New USB device found, idVendor=167f, idProduct=3001
            [260966.669265] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
            [260966.669269] usb 1-2: Product: Product
            [260966.669273] usb 1-2: Manufacturer: Company
            [260966.669276] usb 1-2: SerialNumber: 123abc

Attempted Mitigations:

    • Disabling logging in Zephyr did not affect the crash.
    • Attempting to re-run dfu-util did not succeed:
   
        dfu-util 0.8

        Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
        Copyright 2010-2014 Tormod Volden and Stefan Schmidt
        This program is Free Software and has ABSOLUTELY NO WARRANTY
        Please report bugs to dfu-util@...

        dfu-util: Invalid DFU suffix signature
        dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
        Opening DFU capable USB device...
        ID 167f:3001
        Run-time device DFU version 0110
        Claiming USB DFU Interface...
        Setting Alternate Setting #1 ...
        dfu-util: Cannot set alternate interface


Is DFU supported on the nrf52840 with Zephyr 1.14? Any supporting documentation would be appreciated.


Re: Dragino LSN50 and STLink

Kumar Gala
 

Adding 2 people who might be able to help.

- k

On May 7, 2019, at 1:29 PM, Gustavo FN <gustavofn@...> wrote:

Hello everyone,

I noticed the Dragino LSN50 board has been ported to Zephyr and that's pretty cool.

I have one of this board and following the page https://docs.zephyrproject.org/latest/boards/arm/dragino_lsn50/doc/index.html#flashing-an-application-to-dragino-lsn50 they say 'Connect the Dragino LSN50 to a STLinkV2...'.

Since the the board has no dedicated connect to JTAG/SWD, I read the stm32l072cz datasheet and found out the the SWDIO is PA13 and SWCLK is PA14.

I connected these pins at my J-Link Ultra in the following way:
JTAG -> LSN50
pin 6 -> pin GND
pin 7 -> pin PA13 (SWDIO)
pin 9 -> pin PA14
pin 19 -> pin VDD (+3.3V)

And tried to connect the Ozone but it did not work. At Ozone, in J-Link Settings I have the target device: STM32L072CZ, Target Interface: SWD:auto speed and Host Interface: USB.

If someone knows how to connect the LSN50 board and could explain me I'll be very grateful.

All the best,


Re: Concurrent TLS and Non-TLS TCP Communication

Lubos, Robert
 

Hi Erin,

 

It is be possible to have both, TCP and TLS sockets when CONFIG_NET_SOCKETS_SOCKOPT_TLS option is enabled. Just to be sure, I’ve verified this functionality with current master and echo_server sample; communication over a regular TCP socket even with overlay-tls.conf enabled works fine, same with UDP. Perhaps you could provide some more details or share some code so that we could see what’s happening in your project?

 

Regards,

Robert

 

From: users@... [mailto:users@...] On Behalf Of Erin Beckwith via Lists.Zephyrproject.Org
Sent: Sunday, April 28, 2019 21:52
To: users@...
Cc: users@...
Subject: [Zephyr-users] Concurrent TLS and Non-TLS TCP Communication

 

Hello,

For a research project I have a need to be able to support both TLS and non-TLS communication in the same application. 
Is there any way to do this within Zephyr?  It seems like once I apply the TLS overlay config, I might not be able to do any non-TLS communication.  When I try to open the simple TCP socket it seems to still go down the code path of calling through the mbed libs.

Thanks,
Erin


Dragino LSN50 and STLink

Gustavo FN
 

Hello everyone,

I noticed the Dragino LSN50 board has been ported to Zephyr and that's pretty cool.

I have one of this board and following the page https://docs.zephyrproject.org/latest/boards/arm/dragino_lsn50/doc/index.html#flashing-an-application-to-dragino-lsn50 they say 'Connect the Dragino LSN50 to a STLinkV2...'.

Since the the board has no dedicated connect to JTAG/SWD, I read the stm32l072cz datasheet and found out the the SWDIO is PA13 and SWCLK is PA14.

I connected these pins at my J-Link Ultra in the following way:
JTAG -> LSN50
pin 6 -> pin GND
pin 7 -> pin PA13 (SWDIO)
pin 9 -> pin  PA14 
pin 19 -> pin VDD (+3.3V)

And tried to connect the Ozone but it did not work. At Ozone, in J-Link Settings I have the target device: STM32L072CZ, Target Interface: SWD:auto speed and Host Interface: USB.

If someone knows how to connect the LSN50 board and could explain me I'll be very grateful.

All the best,


Re: Sparkfun Pro nRF52840 Mini support?

Kumar Gala
 

On Apr 24, 2019, at 2:47 PM, Lawrence King <lawrence.king@...> wrote:

Hi Rodrigo:



You asked: “Are you sure that it is not possible to program a new zephyr firmware with the current bootloader?”, the answer is



As I mentioned earlier, my backup plan is to use a J-Link device, It should show up in a day or two, and I am reasonably confident that will work.



I am impressed with the huge number of boards that Zephyr does support, kudos to the Zephyr Project for getting so much running. Hopefully the project team will have a chance to get the various debuggers cleanly integrated and make every board really easy for newbies….
We’d be happy to accept changes for the boards to support both w & w/o the bootloader. I haven’t looked at the submissions for the existing boards, but I’m guessing that for a number of boards the quickest way to get Zephyr going was to ignore the bootloader.

- k


nrf9160 networking

Nick Glencross
 

Hello,

Without doubt this will be a newbie question, but I'm having trouble seeing the wood from the trees.

I've written some code which works really well under both the POSIX and qemu targets, but am unclear how best to get either real or simulated networking working on my new nrf9160 board.

I think I'm in a location where my bundled iBasis SIM card doesn't work, so should I be:
  • Trying to get the modem working with a local SIM card?
  • Trying to get an external network card working
  • Networking via the host computer? I tried enabling SLIP but it seem to make the executable die with a UARTException
    This would actually be my preferred solution at the moment
  • Another option I haven't considered
As a follow up question, if I want to get networking working through the modem, will I need to use the libraries that the asset_tracker depends on, such as modem_info, bsdlib, etc. Are there easier ways to do it?
I will be making simple SSL http requests.

Thanks in advance,

Nick


Re: Incorrect flash_map in Zephyr v1.14.0 #nrf52840

Phil Hipp
 

Fixed by using mcuboot master. v1.3.0 is not compatible with Zephyr v1.14.0.


Immediate preemption / Task switch when return from a ISR

nicolas lantz <nicolas.lantz@...>
 

Hi,

I trying to have a task waiting to put a message in a queue to be immediatly rescheduled when return from an ISR getting this msg.
For now,  the Task is set as Ready (when the ISR get the msg in the queue), but the system return in Idle Task for a long time before the Task is being executed again to prepare another msg.

The consequence is that next msg is not ready on time, while the system spent a long time in IDLE task.
I tried a lot of chosen but nothing that works.

Does somenone have a solution todo that ?


Configuration
CONFIG_PREEMPT_ENABLED=y
CONFIG_MULTITHREADING=y

My_Task as a priority of 2


Simple example code :

K_MSGQ_DEFINE(p_msgq , sizeof(msg_t), 1, 4);

My_Task()
{
    msg_t msg;

    while(1){

        do_something_to_prepare_msg(&msg);
         k_msgq_put(p_msgq, &msg, K_FOREVER);
    }

 }


My_ISR(void)
{
    msg_t msg;

    k_msgq_get(p_msgq, &msg, K_NO_WAIT);
    use_msg(&msg);
}


Thaks.
BR
Nicolas

Nicolas LANTZ
M : +33 (0)6 19 07 43 43
T : +33 (0)9 52 96 81 86
www.ubicore.net


Incorrect flash_map in Zephyr v1.14.0 #nrf52840

Phil Hipp
 

Hi everybody,

it seems I found a bug in v1.14.0. I'm using Zephyr on my nrf52840 based custom board together with mcuboot v1.3.0. Everything worked fine with Zephyr v1.13.0, but after updating to the latest release I'm not able to boot the image in slot 0 via mcuboot. After debugging for a while, I had a look at the array flash_map (pointing to default_flash_map). This array has 5 entries that reflect the partitions defined in the board's dts, except that the entries for slot 0 and 1 are turned around. Because of this mcuboot is pointing to slot 1 when it wants to boot from slot 0 and vice versa. I first thought this is an issue with my custom board, but I have the same problem building for e.g. nrf52840_pca10056.

Did I simply miss something here or is this really an issue?

Best

 

Philipp 


Re: [EXT] [Zephyr-users] Writing to Flash for Settings

Nick Glencross
 

Hello Maureen,

Thank you! That did the trick. I don't think I'd ever have worked that out without your help,

Nick


On Mon, 29 Apr 2019 at 18:37, Maureen Helm <maureen.helm@...> wrote:

Hi Nick,

You need to set:

CONFIG_MPU_ALLOW_FLASH_WRITE=y

 

Maureen

 

From: users@... <users@...> On Behalf Of Nick Glencross via Lists.Zephyrproject.Org
Sent: Monday, April 29, 2019 2:37 AM
To: users@...
Cc: users@...
Subject: [EXT] [Zephyr-users] Writing to Flash for Settings

 

Caution: EXT Email

Hello,

 

I'm having my first experiment with Settings backed by Flash, but not getting very far.

 

I have an nrf9160 Nordic board and my project file is the same as many of the examples:

 

CONFIG_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_FCB=y
CONFIG_SETTINGS_FCB=y

Unfortunately the initial call to settings_subsys_init() is dying.

 

***** MPU FAULT *****
  Data Access Violation
  MMFAR Address: 0xfa000
***** Hardware exception *****
Current thread ID = 0x20020140
Faulting instruction address = 0x41b62
Fatal fault in essential thread! Spinning...

 

I've traced the call through various functions, such as fcb_int, fcb_sector_hdr_init, fcb_flash_write, flash_area_write and finally flash_write.

 

The flash_write call is passed (0xfa000, 0x20020568, 8) which matches the address shown in the crash.

 

I've also experimented with settings_fcb_src, but still get the same exception.

 

Can anymore shed any light on why it is dying (I'm assuming that area isn't writable), and how I get a bit further?

 

Thanks,

 

Nick Glencross


Re: [EXT] [Zephyr-users] Writing to Flash for Settings

Maureen Helm
 

Hi Nick,

You need to set:

CONFIG_MPU_ALLOW_FLASH_WRITE=y

 

Maureen

 

From: users@... <users@...> On Behalf Of Nick Glencross via Lists.Zephyrproject.Org
Sent: Monday, April 29, 2019 2:37 AM
To: users@...
Cc: users@...
Subject: [EXT] [Zephyr-users] Writing to Flash for Settings

 

Caution: EXT Email

Hello,

 

I'm having my first experiment with Settings backed by Flash, but not getting very far.

 

I have an nrf9160 Nordic board and my project file is the same as many of the examples:

 

CONFIG_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_FCB=y
CONFIG_SETTINGS_FCB=y

Unfortunately the initial call to settings_subsys_init() is dying.

 

***** MPU FAULT *****
  Data Access Violation
  MMFAR Address: 0xfa000
***** Hardware exception *****
Current thread ID = 0x20020140
Faulting instruction address = 0x41b62
Fatal fault in essential thread! Spinning...

 

I've traced the call through various functions, such as fcb_int, fcb_sector_hdr_init, fcb_flash_write, flash_area_write and finally flash_write.

 

The flash_write call is passed (0xfa000, 0x20020568, 8) which matches the address shown in the crash.

 

I've also experimented with settings_fcb_src, but still get the same exception.

 

Can anymore shed any light on why it is dying (I'm assuming that area isn't writable), and how I get a bit further?

 

Thanks,

 

Nick Glencross


Writing to Flash for Settings

Nick Glencross
 

Hello,

I'm having my first experiment with Settings backed by Flash, but not getting very far.

I have an nrf9160 Nordic board and my project file is the same as many of the examples:

CONFIG_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_FCB=y
CONFIG_SETTINGS_FCB=y

Unfortunately the initial call to settings_subsys_init() is dying.

***** MPU FAULT *****
  Data Access Violation
  MMFAR Address: 0xfa000
***** Hardware exception *****
Current thread ID = 0x20020140
Faulting instruction address = 0x41b62
Fatal fault in essential thread! Spinning...

I've traced the call through various functions, such as fcb_int, fcb_sector_hdr_init, fcb_flash_write, flash_area_write and finally flash_write.

The flash_write call is passed (0xfa000, 0x20020568, 8) which matches the address shown in the crash.

I've also experimented with settings_fcb_src, but still get the same exception.

Can anymore shed any light on why it is dying (I'm assuming that area isn't writable), and how I get a bit further?

Thanks,

Nick Glencross


Concurrent TLS and Non-TLS TCP Communication

Erin Beckwith
 

Hello,

For a research project I have a need to be able to support both TLS and non-TLS communication in the same application. 
Is there any way to do this within Zephyr?  It seems like once I apply the TLS overlay config, I might not be able to do any non-TLS communication.  When I try to open the simple TCP socket it seems to still go down the code path of calling through the mbed libs.

Thanks,
Erin


Re: Sparkfun Pro nRF52840 Mini support?

Lawrence King
 

Hi Rodrigo:

 

You asked: “Are you sure that it is not possible to program a new zephyr firmware with the current bootloader?”,  the answer is No, I am not sure, but all of the documentation I have read so far, and all of the things I have tried haven’t worked. I was hoping someone on the forum would help me get it running without a J-Link.

 

As I mentioned earlier, my backup plan is to use a J-Link device, It should show up in a day or two, and I am reasonably confident that will work.

 

I am impressed with the huge number of boards that Zephyr does support, kudos to the Zephyr Project for getting so much running. Hopefully the project team will have a chance to get the various debuggers cleanly integrated and make every board really easy for newbies….

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Rodrigo Peixoto <rodrigopex@...>
Sent: Wednesday, April 24, 2019 1:50 PM
To: Lawrence King <lawrence.king@...>
Cc: Zephyr-users@...
Subject: Re: [Zephyr-users] Sparkfun Pro nRF52840 Mini support?

 

Hi Lawrence,

 

I can imagine how frustrated you are. Sorry for hearing that.

 

Sometimes we cannot catch what the developers are doing because the size and complexity of the project. I am very convinced they are trying to do their best to fit every expectation, but sadly sometimes it cannot be possible.

 

Are you sure that it is not possible to program a new zephyr firmware with the current bootloader? I am using the nordic DFU which is not the zephyr's official one to program a nrf52 dongle.

 

You are based on US right? You would buy a generic JLINK if you are not willing to buy a expensive one. I am using a Chinese version of that and it works great. I have bought that for $16.  

 

I hope you can enjoy the system and we can contribute together. 

 

"If you want to go fast, go alone. If you want to go far, go together" someone. (I forgot 😬)

 

 

Best regards,

Rodrigo Peixoto 

 

On Wed, 24 Apr 2019 at 11:02 Lawrence King <lawrence.king@...> wrote:

Hi Rodrigo:

 

I went through the schematics for the SparkFun nrf52840 mini, the Adafruit nrf52840 Feather, and the Nordic pca10059 reference board. All three boards are nearly identical, (other than physical form factors, and the choices of which GPIOs go to the switches, led(s) and I/Os). All three boards use the same boot loader and are fully capable of downloading and running code without the use of an external programming dongle.

 

Unfortunately the Zephyr developers have elected to not use the onboard debug facilities of these boards, and have instead decided that users need to buy and use an external programming device for these boards. This is not the first time I have seen this, I had exactly the same issue with the i.MXMRT1064 board, it too has an onboard debugger, but the only way to use the board is with an external probe.

 

Here is what the Zephyr documentation for the Adafruit feather says https://docs.zephyrproject.org/latest/boards/arm/nrf52_adafruit_feather/doc/nrf52_adafruit_feather.html

 

Flashing

Flashing Zephyr onto the nrf52_adafruit_feather board requires an external J-Link programmer. The programmer is attached to the X1 SWD header.

Other boards such as the MakerDairy nrf52840-mdk do use the onboard debug facilities, and these boards are trivial to bring up with Zephyr, just plug the board into the USB port and type “ninja flash”. If only all of the boards with onboard debug facilities were this easy.

 

Dear Zephyr Developers:

              Please use these boards in exactly the same way a “customer” would use them. Use the onboard debug facilities! It is quick and easy for you to bring the board up with your external debugger, but this should only be used for initial bringup. After that you really should move the debugger dongle off your bench and use the onboard debug facilities.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Rodrigo Peixoto
Sent: Monday, April 22, 2019 11:28 AM
To: Lawrence King <lawrence.king@...>
Cc: Zephyr-users@...
Subject: Re: [Zephyr-users] Sparkfun Pro nRF52840 Mini support?

 

Lawrence,

Do you have the memory footprint detailed when using their bootloader?

I would suggest you change the flash partition to fit the bootloader image size at the bootloader portion and the rest of the image after that. 

 

```c++

...

chosen {

                            zephyr,console = &uart0;

                            zephyr,shell-uart = &uart0;

                            zephyr,uart-mcumgr = &uart0;

                            zephyr,bt-mon-uart = &uart0;

                            zephyr,sram = &sram0;

                            zephyr,flash = &flash0;

                            zephyr,code-partition = &code_partition;

              };

 

...

 

&flash0 {

              /*

              * For more information, see:

              */

              partitions {

                            compatible = "fixed-partitions";

                            #address-cells = <1>;

                            #size-cells = <1>;

 

                            boot_partition: partition@0 {

                                          label = "sparkfun_bootloader";

                                          reg = <0x000000000 0x000XXXX>; // size of that

                            };

                            code_partition: partition@XXXX {

                                          label = "image-0";

                                          reg = <0x0000XXXX 0x0000YYYYYY>; // fit the rest of the memory remember the storage partion

                            };

                            /*

                            * The flash starting at 0x000f8000 and ending at

                            * 0x000fffff is reserved for use by the application.

                            */

 

                            /* Storage partition will be used by FCB/NFFS/NVS if enabled. */

                            storage_partition: partition@f8000 {

                                          label = "storage";

                                          reg = <0x000f8000 0x00008000>;

                            };

              };

};

```

 

Something like that.

 

Answering your question: 

 

Of course my fallback plan is to use an external debugger (J-Link of some kind? Black Majic?). Is there a recommended external debugger I should use for nRF52840?

 

I am using the JLINK with a tag connect plug (TC2030) to flash via SWD pins. west flash always works for me.

I hope it helps. 

 

Best regards,

Rodrigo Peixoto

Co-founder and Technical advisor

 

+55 (82) 98144-8585

http://ayna.tech | Skype: rodrigopex

 

 

 

Em seg, 22 de abr de 2019 às 10:38, Lawrence King <lawrence.king@...> escreveu:

Hi Rodrigo

 

The parts you talked about are the easy parts and I have no problem with these changes. (LDO/DC-DC, crystals, gpio aliases, dts, etc.). I think I already have these set up.

 

The “challenge” with the Sparkfun board is the debugger, and the FLASH space. The Sparkfun board does NOT have an external chip of some kind to do debugging, instead they preload the nRF52840 with a bootloader which presents itself on the native USB interface as a serial port (CDC) and a mass storage device. This way the “usual” tools will work (pyocd) exactly as expected. However the bootloader is “somewhere” in the internal FLASH and it is necessary to change the memory definition in dts to not overwrite the bootloader (and brick the board), also the serial console needs to call the bootloader to output messages on the virtual serial port.

 

Has anyone looked into these portions of the problem for some other chipset? This is the portion of the problem I am not quite sure how to fix.

 

Of course my fallback plan is to use an external debugger (J-Link of some kind? Black Majic?). Is there a recommended external debugger I should use for nRF52840?

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Rodrigo Peixoto <rodrigopex@...>
Sent: Thursday, April 18, 2019 12:49 PM
To: Lawrence King <lawrence.king@...>
Cc: Zephyr-users@...
Subject: Re: [Zephyr-users] Sparkfun Pro nRF52840 Mini support?

 

Hi Lawrence,

 

I am not aware if anyone is bringing up this board, but I can suggest you bring it up yourself. It is not a big deal. The process is copying, pasting, and changing some portion of the files. 

 

How experienced are you on Zephyr?

 

 

1 - Is the Bluetooth module using dc-dc or LDO? 

    YES: Do nothing just copy the board files and rename them;

     NO: You must to disable DCDC by setting the BOARD_ENABLE_DCDC to "default n" at the Kconfig file. 

2 - Is the low-frequency oscillator is present on the Bluetooth module?

    YES: Do nothing

    NO: You have to add the CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y to the "board_name_defconfig" file. 

 

The last step is to change the DTS to adjust the pins used by your board. 

 

If you need further help let us know.

 

 

Best regards,

Rodrigo Peixoto

Co-founder and Technical advisor

 

+55 (82) 98144-8585

http://ayna.tech | Skype: rodrigopex

 

 

 

Em qui, 18 de abr de 2019 às 11:09, Lawrence King <lawrence.king@...> escreveu:

I just received some Sparkfun nRF52840 boards and I was hoping to bring up Zephyr on the boards.

 

There is a Sparkfun nRF52832 board listed in the supported boards, but this board needs an external debugger. Now that Sparkfun has two different nRF52 boards I think that the existing board in the tree nrf52_sparkfun needs to be renamed to nrf52832_sparkfun, and the new board should be added as nrf52840_sparkfun.

 

The nrf52840_sparkfun board has an onboard bootloader which presents as a tty and a usb drive when I plug it in so I expect that pyOCD should work for loading code and debugging, however I think that the ROM layout may need to be changed to not overwrite the bootlopader.

 

Is anyone working on bringing up this board?

 

https://www.sparkfun.com/products/15025

 

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 

--

Rodrigo Peixoto

Co-founder and Technical advisor

 

+55 (82) 98144-8585

http://ayna.tech | Skype: rodrigopex

 


Re: Sparkfun Pro nRF52840 Mini support?

Rodrigo Peixoto <rodrigopex@...>
 

Hi Lawrence,

I can imagine how frustrated you are. Sorry for hearing that.

Sometimes we cannot catch what the developers are doing because the size and complexity of the project. I am very convinced they are trying to do their best to fit every expectation, but sadly sometimes it cannot be possible.

Are you sure that it is not possible to program a new zephyr firmware with the current bootloader? I am using the nordic DFU which is not the zephyr's official one to program a nrf52 dongle.

You are based on US right? You would buy a generic JLINK if you are not willing to buy a expensive one. I am using a Chinese version of that and it works great. I have bought that for $16.  

I hope you can enjoy the system and we can contribute together. 

"If you want to go fast, go alone. If you want to go far, go together" someone. (I forgot 😬)


Best regards,
Rodrigo Peixoto 

On Wed, 24 Apr 2019 at 11:02 Lawrence King <lawrence.king@...> wrote:

Hi Rodrigo:

 

I went through the schematics for the SparkFun nrf52840 mini, the Adafruit nrf52840 Feather, and the Nordic pca10059 reference board. All three boards are nearly identical, (other than physical form factors, and the choices of which GPIOs go to the switches, led(s) and I/Os). All three boards use the same boot loader and are fully capable of downloading and running code without the use of an external programming dongle.

 

Unfortunately the Zephyr developers have elected to not use the onboard debug facilities of these boards, and have instead decided that users need to buy and use an external programming device for these boards. This is not the first time I have seen this, I had exactly the same issue with the i.MXMRT1064 board, it too has an onboard debugger, but the only way to use the board is with an external probe.

 

Here is what the Zephyr documentation for the Adafruit feather says https://docs.zephyrproject.org/latest/boards/arm/nrf52_adafruit_feather/doc/nrf52_adafruit_feather.html

 

Flashing

Flashing Zephyr onto the nrf52_adafruit_feather board requires an external J-Link programmer. The programmer is attached to the X1 SWD header.

Other boards such as the MakerDairy nrf52840-mdk do use the onboard debug facilities, and these boards are trivial to bring up with Zephyr, just plug the board into the USB port and type “ninja flash”. If only all of the boards with onboard debug facilities were this easy.

 

Dear Zephyr Developers:

              Please use these boards in exactly the same way a “customer” would use them. Use the onboard debug facilities! It is quick and easy for you to bring the board up with your external debugger, but this should only be used for initial bringup. After that you really should move the debugger dongle off your bench and use the onboard debug facilities.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Rodrigo Peixoto
Sent: Monday, April 22, 2019 11:28 AM
To: Lawrence King <lawrence.king@...>
Cc: Zephyr-users@...
Subject: Re: [Zephyr-users] Sparkfun Pro nRF52840 Mini support?

 

Lawrence,

Do you have the memory footprint detailed when using their bootloader?

I would suggest you change the flash partition to fit the bootloader image size at the bootloader portion and the rest of the image after that. 

 

```c++

...

chosen {

                            zephyr,console = &uart0;

                            zephyr,shell-uart = &uart0;

                            zephyr,uart-mcumgr = &uart0;

                            zephyr,bt-mon-uart = &uart0;

                            zephyr,sram = &sram0;

                            zephyr,flash = &flash0;

                            zephyr,code-partition = &code_partition;

              };

 

...

 

&flash0 {

              /*

              * For more information, see:

              */

              partitions {

                            compatible = "fixed-partitions";

                            #address-cells = <1>;

                            #size-cells = <1>;

 

                            boot_partition: partition@0 {

                                          label = "sparkfun_bootloader";

                                          reg = <0x000000000 0x000XXXX>; // size of that

                            };

                            code_partition: partition@XXXX {

                                          label = "image-0";

                                          reg = <0x0000XXXX 0x0000YYYYYY>; // fit the rest of the memory remember the storage partion

                            };

                            /*

                            * The flash starting at 0x000f8000 and ending at

                            * 0x000fffff is reserved for use by the application.

                            */

 

                            /* Storage partition will be used by FCB/NFFS/NVS if enabled. */

                            storage_partition: partition@f8000 {

                                          label = "storage";

                                          reg = <0x000f8000 0x00008000>;

                            };

              };

};

```

 

Something like that.

 

Answering your question: 

 

Of course my fallback plan is to use an external debugger (J-Link of some kind? Black Majic?). Is there a recommended external debugger I should use for nRF52840?

 

I am using the JLINK with a tag connect plug (TC2030) to flash via SWD pins. west flash always works for me.

I hope it helps. 

 

Best regards,

Rodrigo Peixoto

Co-founder and Technical advisor

 

+55 (82) 98144-8585

http://ayna.tech | Skype: rodrigopex

 

 

 

Em seg, 22 de abr de 2019 às 10:38, Lawrence King <lawrence.king@...> escreveu:

Hi Rodrigo

 

The parts you talked about are the easy parts and I have no problem with these changes. (LDO/DC-DC, crystals, gpio aliases, dts, etc.). I think I already have these set up.

 

The “challenge” with the Sparkfun board is the debugger, and the FLASH space. The Sparkfun board does NOT have an external chip of some kind to do debugging, instead they preload the nRF52840 with a bootloader which presents itself on the native USB interface as a serial port (CDC) and a mass storage device. This way the “usual” tools will work (pyocd) exactly as expected. However the bootloader is “somewhere” in the internal FLASH and it is necessary to change the memory definition in dts to not overwrite the bootloader (and brick the board), also the serial console needs to call the bootloader to output messages on the virtual serial port.

 

Has anyone looked into these portions of the problem for some other chipset? This is the portion of the problem I am not quite sure how to fix.

 

Of course my fallback plan is to use an external debugger (J-Link of some kind? Black Majic?). Is there a recommended external debugger I should use for nRF52840?

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Rodrigo Peixoto <rodrigopex@...>
Sent: Thursday, April 18, 2019 12:49 PM
To: Lawrence King <lawrence.king@...>
Cc: Zephyr-users@...
Subject: Re: [Zephyr-users] Sparkfun Pro nRF52840 Mini support?

 

Hi Lawrence,

 

I am not aware if anyone is bringing up this board, but I can suggest you bring it up yourself. It is not a big deal. The process is copying, pasting, and changing some portion of the files. 

 

How experienced are you on Zephyr?

 

 

1 - Is the Bluetooth module using dc-dc or LDO? 

    YES: Do nothing just copy the board files and rename them;

     NO: You must to disable DCDC by setting the BOARD_ENABLE_DCDC to "default n" at the Kconfig file. 

2 - Is the low-frequency oscillator is present on the Bluetooth module?

    YES: Do nothing

    NO: You have to add the CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y to the "board_name_defconfig" file. 

 

The last step is to change the DTS to adjust the pins used by your board. 

 

If you need further help let us know.

 

 

Best regards,

Rodrigo Peixoto

Co-founder and Technical advisor

 

+55 (82) 98144-8585

http://ayna.tech | Skype: rodrigopex

 

 

 

Em qui, 18 de abr de 2019 às 11:09, Lawrence King <lawrence.king@...> escreveu:

I just received some Sparkfun nRF52840 boards and I was hoping to bring up Zephyr on the boards.

 

There is a Sparkfun nRF52832 board listed in the supported boards, but this board needs an external debugger. Now that Sparkfun has two different nRF52 boards I think that the existing board in the tree nrf52_sparkfun needs to be renamed to nrf52832_sparkfun, and the new board should be added as nrf52840_sparkfun.

 

The nrf52840_sparkfun board has an onboard bootloader which presents as a tty and a usb drive when I plug it in so I expect that pyOCD should work for loading code and debugging, however I think that the ROM layout may need to be changed to not overwrite the bootlopader.

 

Is anyone working on bringing up this board?

 

https://www.sparkfun.com/products/15025

 

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 

--
Rodrigo Peixoto
Co-founder and Technical advisor

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex



Re: Sparkfun Pro nRF52840 Mini support?

Lawrence King
 

Hi Rodrigo:

 

I went through the schematics for the SparkFun nrf52840 mini, the Adafruit nrf52840 Feather, and the Nordic pca10059 reference board. All three boards are nearly identical, (other than physical form factors, and the choices of which GPIOs go to the switches, led(s) and I/Os). All three boards use the same boot loader and are fully capable of downloading and running code without the use of an external programming dongle.

 

Unfortunately the Zephyr developers have elected to not use the onboard debug facilities of these boards, and have instead decided that users need to buy and use an external programming device for these boards. This is not the first time I have seen this, I had exactly the same issue with the i.MXMRT1064 board, it too has an onboard debugger, but the only way to use the board is with an external probe.

 

Here is what the Zephyr documentation for the Adafruit feather says https://docs.zephyrproject.org/latest/boards/arm/nrf52_adafruit_feather/doc/nrf52_adafruit_feather.html

 

Flashing

Flashing Zephyr onto the nrf52_adafruit_feather board requires an external J-Link programmer. The programmer is attached to the X1 SWD header.

Other boards such as the MakerDairy nrf52840-mdk do use the onboard debug facilities, and these boards are trivial to bring up with Zephyr, just plug the board into the USB port and type “ninja flash”. If only all of the boards with onboard debug facilities were this easy.

 

Dear Zephyr Developers:

              Please use these boards in exactly the same way a “customer” would use them. Use the onboard debug facilities! It is quick and easy for you to bring the board up with your external debugger, but this should only be used for initial bringup. After that you really should move the debugger dongle off your bench and use the onboard debug facilities.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Rodrigo Peixoto
Sent: Monday, April 22, 2019 11:28 AM
To: Lawrence King <lawrence.king@...>
Cc: Zephyr-users@...
Subject: Re: [Zephyr-users] Sparkfun Pro nRF52840 Mini support?

 

Lawrence,

Do you have the memory footprint detailed when using their bootloader?

I would suggest you change the flash partition to fit the bootloader image size at the bootloader portion and the rest of the image after that. 

 

```c++

...

chosen {

                            zephyr,console = &uart0;

                            zephyr,shell-uart = &uart0;

                            zephyr,uart-mcumgr = &uart0;

                            zephyr,bt-mon-uart = &uart0;

                            zephyr,sram = &sram0;

                            zephyr,flash = &flash0;

                            zephyr,code-partition = &code_partition;

              };

 

...

 

&flash0 {

              /*

              * For more information, see:

              */

              partitions {

                            compatible = "fixed-partitions";

                            #address-cells = <1>;

                            #size-cells = <1>;

 

                            boot_partition: partition@0 {

                                          label = "sparkfun_bootloader";

                                          reg = <0x000000000 0x000XXXX>; // size of that

                            };

                            code_partition: partition@XXXX {

                                          label = "image-0";

                                          reg = <0x0000XXXX 0x0000YYYYYY>; // fit the rest of the memory remember the storage partion

                            };

                            /*

                            * The flash starting at 0x000f8000 and ending at

                            * 0x000fffff is reserved for use by the application.

                            */

 

                            /* Storage partition will be used by FCB/NFFS/NVS if enabled. */

                            storage_partition: partition@f8000 {

                                          label = "storage";

                                          reg = <0x000f8000 0x00008000>;

                            };

              };

};

```

 

Something like that.

 

Answering your question: 

 

Of course my fallback plan is to use an external debugger (J-Link of some kind? Black Majic?). Is there a recommended external debugger I should use for nRF52840?

 

I am using the JLINK with a tag connect plug (TC2030) to flash via SWD pins. west flash always works for me.

I hope it helps. 

 

Best regards,

Rodrigo Peixoto

Co-founder and Technical advisor

 

+55 (82) 98144-8585

http://ayna.tech | Skype: rodrigopex

 

 

 

Em seg, 22 de abr de 2019 às 10:38, Lawrence King <lawrence.king@...> escreveu:

Hi Rodrigo

 

The parts you talked about are the easy parts and I have no problem with these changes. (LDO/DC-DC, crystals, gpio aliases, dts, etc.). I think I already have these set up.

 

The “challenge” with the Sparkfun board is the debugger, and the FLASH space. The Sparkfun board does NOT have an external chip of some kind to do debugging, instead they preload the nRF52840 with a bootloader which presents itself on the native USB interface as a serial port (CDC) and a mass storage device. This way the “usual” tools will work (pyocd) exactly as expected. However the bootloader is “somewhere” in the internal FLASH and it is necessary to change the memory definition in dts to not overwrite the bootloader (and brick the board), also the serial console needs to call the bootloader to output messages on the virtual serial port.

 

Has anyone looked into these portions of the problem for some other chipset? This is the portion of the problem I am not quite sure how to fix.

 

Of course my fallback plan is to use an external debugger (J-Link of some kind? Black Majic?). Is there a recommended external debugger I should use for nRF52840?

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Rodrigo Peixoto <rodrigopex@...>
Sent: Thursday, April 18, 2019 12:49 PM
To: Lawrence King <lawrence.king@...>
Cc: Zephyr-users@...
Subject: Re: [Zephyr-users] Sparkfun Pro nRF52840 Mini support?

 

Hi Lawrence,

 

I am not aware if anyone is bringing up this board, but I can suggest you bring it up yourself. It is not a big deal. The process is copying, pasting, and changing some portion of the files. 

 

How experienced are you on Zephyr?

 

 

1 - Is the Bluetooth module using dc-dc or LDO? 

    YES: Do nothing just copy the board files and rename them;

     NO: You must to disable DCDC by setting the BOARD_ENABLE_DCDC to "default n" at the Kconfig file. 

2 - Is the low-frequency oscillator is present on the Bluetooth module?

    YES: Do nothing

    NO: You have to add the CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y to the "board_name_defconfig" file. 

 

The last step is to change the DTS to adjust the pins used by your board. 

 

If you need further help let us know.

 

 

Best regards,

Rodrigo Peixoto

Co-founder and Technical advisor

 

+55 (82) 98144-8585

http://ayna.tech | Skype: rodrigopex

 

 

 

Em qui, 18 de abr de 2019 às 11:09, Lawrence King <lawrence.king@...> escreveu:

I just received some Sparkfun nRF52840 boards and I was hoping to bring up Zephyr on the boards.

 

There is a Sparkfun nRF52832 board listed in the supported boards, but this board needs an external debugger. Now that Sparkfun has two different nRF52 boards I think that the existing board in the tree nrf52_sparkfun needs to be renamed to nrf52832_sparkfun, and the new board should be added as nrf52840_sparkfun.

 

The nrf52840_sparkfun board has an onboard bootloader which presents as a tty and a usb drive when I plug it in so I expect that pyOCD should work for loading code and debugging, however I think that the ROM layout may need to be changed to not overwrite the bootlopader.

 

Is anyone working on bringing up this board?

 

https://www.sparkfun.com/products/15025

 

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 


Re: Client certificates

Jukka Rissanen
 

Hi Nick,

see for example samples/net/sockets/echo_client how it is handling the
certificates. Also if you want to create certs yourself, there is some
guidance in net-tools project README.md file for that.


Cheers,
Jukka

On Wed, 2019-04-17 at 16:46 +0400, Nick Glencross wrote:
Hello,

I've been doing some Zephyr development, and it's looking really
slick.

I started writing a lengthy email with some code fragment of my
attempt to get Client certificates working, but I've just been
getting various errors from deep in mbedtls, suggesting I'm not
passing in the right certificates credentials etc.

Has anyone got client TLS certificates working, and can share a
working example?

I'd be really grateful if someone could point me in the right
direction,

Thank,

Nick Glencross


1661 - 1680 of 3111