1. devel@lists.zephyrproject.org
   Date   
Re: lwip integration with OpenThread #nrf52840 #lwip #openthread

deepa.gopinath@...
 

Hi Paul,

As I saw netif based API's in Zephyr stack, I assumed it as lwip stack.
Thanks for clarifying that Zephyr has its own IP stack which is not lwip.

Thanks & Regards,
Deepa
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

icephyr
 

Thanks a lot Frank, I executed commands advertise on and discoverable on as you mentioned, now I can scan out the device with MAC address I set ! 

Now our problems are the same, I will read the source codes to find out the problem, also hope others can pay attention and solve this problem too. Look forward to your progress and good news!
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

frv
 

Hi,

For advertising I don't use the hcitool cmd, however I think a fast and easy check can also be done by using either the bluetootctl or the btmgmt tool.

So after executing the bluetoothctl you can activate advertising by just typing : advertise on. I would also execute : discoverable on,  otherwise the nRFConnect will not see the BT device that is advertising.

For a more user friendly approach I would recommend to use a C++ implementation (See e.g. QT heart-rate server applic) to approach the Bluez stack.

Best regards,
Frank
Re: lwip integration with OpenThread #nrf52840 #lwip #openthread

Paul Sokolovsky
 

Hello Deepa,

On Sun, 11 Nov 2018 23:43:19 -0800
deepa.gopinath@pathpartnertech.com wrote:

Hi Paul,

I have found it in this link
- https://github.com/zephyrproject-rtos/zephyr/issues/10561 By
referring the config file also we can able to find Echo client and
server example can be built for either OpenThread or third party IP
stack.
https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/echo_client/overlay-ot.conf
Remaining config files will be used to build for other configurations
- https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/echo_client/
None of the links you mention has occurrence of "lwip" (case
insensitive) in any material it points to.

Zephyr doesn't work with lwIP, it has own IP stack. However, I'd be
interesting to hear if someone integrated lwIP with Zephyr
(apparently, bypassing its native IP stack), so if you have any links
substantiating that, please feel free to share them.


Thanks & Regards,
Deepa
--
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
Better crash handling in gdb, was: Re: [Zephyr-devel] __ASSERT - transfer to error handler

Paul Sokolovsky
 

Hello Andrew,


I appreciate the response.

On Fri, 9 Nov 2018 17:57:03 +0000
"Boie, Andrew P" <andrew.p.boie@intel.com> wrote:

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.
Yes, and actually, over the couple of years, I found that information
to become more usable. Like, I remember when I just started with
Zephyr, I regularly hit cases when I couldn't get anything useful from
such a crash dump, while recently I noticed to myself that it was
helpful each time. I don't know whether format of it changed to be more
detailed/clear, or I got more experience with it, I assume both it.

But sure, it's still pretty far in usability from "desktop" debugging.

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.
Well, if I knew how to do it, I'd go trying to do it myself ;-). So
far, I don't even understand how generic GDB stub (as run on real hw
for GDB debugging), qemu's "meta level stub", Zephyr's builtin stub
(which was remove some time ago) should/would interact to make it
possible to achieve that effect. I remember a year or so ago I set up
to read thru google results on "qemu gdb debugging support", but
figured it's too far-fetched from the normal "Zephyr development" of
which we have a lot to do in queue yet.

That said, you nailed it right - the "user feature request" is exactly
to be able to use GDB as used in normal workstation environment, where
if a binary segfaults, I can run it under qemu, and it's stop and allow
me to review the state right at the instruction which crashes.

So again, I appreciate the response here, let's keep at the back of out
minds, maybe we'll get to implement it later.


Andrew


--
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: Zephyr as HCI Host #uart #bluetoothmesh #hci

Johan Hedberg
 

Hi,


On 13 Nov 2018, at 0.38, abaska@intermatic.com wrote:
I am trying to configure Zephyr as a HCI UART host.

My setup:
• nrf52840_pca10056 nordic dev kit running zephyr/samples/bluetooth/hci_uart. This seems pretty straight forward.
• stm32f746g_disco dev kit running zephyr/samples/bluetooth/mesh. When selecting the mesh sample the build environment knows to automatically select BT_HCI_HOST.
• 4 UART lines between the two boards. Rx, Tx, RTS, and CTS.

Is this a valid setup? I really only need zephyr running as the host and then the HCI controller could be any controller that speaks HCI UART, but right now I have both boards running zephyr. I found documentation on zephyr HCI controller, but not much on zephyr being the HCI host.
This is a valid and quite common set up. The most important thing you'll need to enable is the host-side UART HCI driver using CONFIG_BT_H4=y.

Johan
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

icephyr
 

Hi Frank，
    Thanks for your suggestions, The mac address was changed successfully under your instructions, but I still cannot discover the device with nRFConnect smartphone app.
That seems all the difference between us.
After I changed mac address of the controller, I just set advertise data and enabled advertise function:
The advertise data I set was :
hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 06 03 03 aa fe 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00
Then I set advertise function enable:
sudo hcitool -i hci0 cmd 0x08 0x000a 01

would you please tell what commands you executed to make the controller advertise normally ? Thanks
Zephyr as HCI Host #uart #bluetoothmesh #hci

@abaska
 

Hello,

I am trying to configure Zephyr as a HCI UART host.

My setup:
  • nrf52840_pca10056 nordic dev kit running zephyr/samples/bluetooth/hci_uart. This seems pretty straight forward.
  • stm32f746g_disco dev kit running zephyr/samples/bluetooth/mesh. When selecting the mesh sample the build environment knows to automatically select BT_HCI_HOST.
  • 4 UART lines between the two boards. Rx, Tx, RTS, and CTS.

Is this a valid setup? I really only need zephyr running as the host and then the HCI controller could be any controller that speaks HCI UART, but right now I have both boards running zephyr. I found documentation on zephyr HCI controller, but not much on zephyr being the HCI host.

In running this I would expect to see the mesh sample run. IE to be able to see a configurable mesh device and to be able to provision it. What I am seeing is one UART message in either direction (seen via scope) then nothing. I started divining into the hci code but wanted to reach out to see if anyone has ever ran zephyr as a bluetooth HCI host before.
Re: thread permissions issue

Boie, Andrew P
 

I'm developing a shell module for the sensor drivers and I want to
validate if the device name passed from the user is a sensor device.
The userspace infrastructure has facilities for this, but as I commented in your patch, what you are doing is only intended for system call handlers. The Zephyr kernel running in supervisor mode is intended to be very lightweight and doesn't have features like this, it's a garbage-in-garbage-out type of situation.

The proper way to do this is have the shell main loop run in user mode, it's the only way to make robust assertions that malformed user input can't hose the system. I suggest just dropping the checks.

Andrew
Resources Regarding assembly coding on Cortex arm-4

Md Kowsar Hossain <auvikuet@...>
 

Hello,

I was looking for some useful links from where I can learn how to do assembly coding on Cortex arm-4 more specifically calling a c function from an assembly file. Could you please provide me some resources regarding it?


Regards
Auvi  
Re: Calling a function not compiled as part of Zephyr from within Zephyr

Sebastian Boe
 

Could you try turning off CONFIG_USERSPACE and/or provide a minimal test case that demonstrates the failure?

________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of Jamie Mccrae <Jamie.Mccrae@lairdtech.com>
Sent: Monday, November 12, 2018 2:15:11 PM
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Calling a function not compiled as part of Zephyr from within Zephyr

Hi,
I am attempting to run an external function on an nRF52840 which is present on the module's flash at a known address but is not part of the Zephyr environment (consider it external). The function doesn't do much except update some pointers which are provided to it, however when attempting to run the function from Zephyr, it generates a usage fault error, "Illegal use of the EPSR". I assume this is caused by a kernel security feature, so how would one go about calling an external function generated in a different build environment from Zephyr without it causing a fault?
Thanks,
Jamie
Calling a function not compiled as part of Zephyr from within Zephyr

Jamie Mccrae <Jamie.Mccrae@...>
 

Hi,
I am attempting to run an external function on an nRF52840 which is present on the module's flash at a known address but is not part of the Zephyr environment (consider it external). The function doesn't do much except update some pointers which are provided to it, however when attempting to run the function from Zephyr, it generates a usage fault error, "Illegal use of the EPSR". I assume this is caused by a kernel security feature, so how would one go about calling an external function generated in a different build environment from Zephyr without it causing a fault?
Thanks,
Jamie
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

frv
 
Edited

Hi there,

For me using the Nordic's nRFConnect smartphone app is very useful in the debug process.

My experience so far is when the public address of the HCI controller is set as 00:00:00:00:00:00 the client (central) application will detect/discover the peripheral BT device as ANOMYNOUS, thus the advertising is working.
However connecting to it via the nRFConnect makes the client applic crashing when the device is disoverable as ANOMYNOUS. But this is a different kind of issue I'm afraid. 

BTW make also sure you are making your device discoverable. 

I suggest you set the public address of the HCI controller via the cmd hcitool cmd 0x3f 0x006 0x0 0x0 0x1 0x2 0x21 0xAD (you are of course free to chose a different BD address). Make sure the btattach process is running correctly (e.g. btattach -B /dev/tttyACM0 -S 1000000 -P h4) before setting the address.
Stop the btattach process and restart it.  When the cmd is succesfully executed the cmd hcitool dev or hciconfig -a should display the address that was set.

BTW making use of QT example code makes it quite interesting to test out BLE functionality. Also QT DBus viewer can be very helpful in setting and debugging BLE functionality.

Good luck,
Frank
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

icephyr
 

Hi，guys, It seems that I met a similar problem with Frank.
 
I use nRF52832 running HCI_UART sample as a controller. I want to make the controller advertise unconnectable packets outside， so I use bluez （version 5.48）
 
and hcitool to set advertise data :
sudo hcitool -i hci0 cmd 0x08 0x0008 1f 02 01 06 03 03 aa fe 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00
 
and set advertise enable:
sudo hcitool -i hci0 cmd 0x08 0x000a 01
 
I detect the process with btmon, the controller returns success ,like this below:


But I didn't find the packet whose data was what I have set with hcitool command. I wonder if this is normal, and will the whole zero mac-address cause this problem ?
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

frv
 

Hi Carles,

Thanks a lot, I hope soon a proper answer can be given, nevertheless progress is made and it just to know if this is normal behaviour. 

Best regards,
Frank
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 Frank,

 

Right, since this seems to be more about BlueZ and Qt than about Zephyr or nRF, because nRF chipsets do not come with a public address registered and burned into the chip, I have copied a couple of people familiar with BlueZ to see if they can help you.

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of frv
Sent: 12 November 2018 12:14
To: devel@...
Subject: Re: [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

 

[Edited Message Follows]

Hi Carles,

Humm... not quite, I have recently created a QT bug report (See : https://bugreports.qt.io/browse/QTBUG-71727)  although I think different parties are to blame, I'm still not sure who is doing really wrong, or miss interprets the data.

Thus to summarize again:
If no public address is set for the Nordic BT controller, the HCI adapter has by default address 00:00:00:00:00:00.

When Qt creates a QLowEnergyController object it uses the BT random address to find the HCI adapter (hciForAddress member function in the HciManager class), but as the random address is different from the default public address it is not able to create a QT BT socket, and thus all BLE actions will fail (E.g. advertising).

As QT uses the Bluez DBus function for retrieving the address info you could say it is the Bluez stack to blame, as the address is referring to the HCI adapter is the random address and not the public device address (00:00:00:00:00:00) (See attach pic of QDbusViewer).

Thus only after setting the public address different from the zero address (by means of the hcitool cmd) , Qt is able to create a correct LowEnergyController object for starting to advertise. But also in this case you could wonder why is in the DBus topology ("Property: AddressType") the public set address still typed as "random". 

I'm wondering how Qt will reply to the issue. Honestly I love to work with QT as a C++ developer.

Also the Zephyr HCI_UART running on the Nordic HW offers a different solution than using the plain C solution (serialize concept when separating connectivity board from application board) offered by Nordic or the C++ solution based on the Nordic PC BLE driver. Altough the latter also gives a nice solution for integrating BT in our products. 

Best regards,
Frank
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

frv
 
Edited

Hi Carles,

Humm... not quite, I have recently created a QT bug report (See : https://bugreports.qt.io/browse/QTBUG-71727)  although I think different parties are to blame, I'm still not sure who is doing really wrong, or miss interprets the data.

Thus to summarize again:
If no public address is set for the Nordic BT controller, the HCI adapter has by default address 00:00:00:00:00:00.

When Qt creates a QLowEnergyController object it uses the BT random address to find the HCI adapter (hciForAddress member function in the HciManager class), but as the random address is different from the default public address it is not able to create a QT BT socket, and thus all BLE actions will fail (E.g. advertising).

As QT uses the Bluez DBus function for retrieving the address info you could say it is the Bluez stack to blame, as the address is referring to the HCI adapter is the random address and not the public device address (00:00:00:00:00:00) (See attach pic of QDbusViewer).

Thus only after setting the public address different from the zero address (by means of the hcitool cmd) , Qt is able to create a correct LowEnergyController object for starting to advertise. But also in this case you could wonder why is in the DBus topology ("Property: AddressType") the public set address still typed as "random". 

I'm wondering how Qt will reply to the issue. Honestly I love to work with QT as a C++ developer.

Also the Zephyr HCI_UART running on the Nordic HW offers a different solution than using the plain C solution (serialize concept when separating connectivity board from application board) offered by Nordic or the C++ solution based on the Nordic PC BLE driver. Altough the latter also gives a nice solution for integrating BT in our products. 

Best regards,
Frank
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 Frank,

 

I understand, so does that mean that you don’t need a public address? Since Qt seems to be doing the right thing.

 

Carles

 

From: devel@... <devel@...> On Behalf Of frv
Sent: 12 November 2018 09:20
To: devel@...
Subject: Re: [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

 

[Edited Message Follows]

Hi Carles,

Thanks for the feedback.

It seems the Qt QLowerEnergyController object selects the first valid address different from the zero address for addressing the HCI controller/adapter. In my case for Nordic Zephyr BLE Controller this is the random address when the public address is not set first different from the zero address by the hci cmd 0x3f 0x006 "address".

Best regards,
Frank

Re: Zephyr Project using Eclipse

Serafin
 

Fwd: List


On 12/11/18 09:44, Serafin wrote:

Hi


You can let cmake generate a Eclipse project. No cmake integration in eclipse needed: See the documentation https://docs.zephyrproject.org/latest/application/application.html?highlight=eclipse#eclipse-debugging

TLDR: 

cmake -G"Eclipse CDT4 - Ninja" -DBOARD=frdm_k64f %ZEPHYR_BASE%\samples\synchronization
ninja
Serafin


On 12/11/18 09:35, Stefan Jaritz wrote:

Morning,

A bit tricky because Eclipse CDT integration of cmake is only available at the latest release and imho not very good.

1.) build from eclipse

Simplest way:
Use std. C Project. Under "C/C++ build" options >> "Builder Type: external" & "Build command: make"

before:
activate build enviroment & go to your zephyr project. create build dir, run cmake

2.) debug from eclipse

the open ocd debuger from the gnu mcu pulgin works best (https://gnu-mcu-eclipse.github.io/debug/openocd/)

create a new run config & and reset the paths:
openocd binary form the /opt/... dir

openocd.cfg from the board config

run west debugserver and start the eclipse debug config


Good luck

Stefan


On 09/11/2018 19:13, Nicholas Yameen wrote:

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: Zephyr Project using Eclipse

Stefan Jaritz
 

Morning,

A bit tricky because Eclipse CDT integration of cmake is only available at the latest release and imho not very good.

1.) build from eclipse

Simplest way:
Use std. C Project. Under "C/C++ build" options >> "Builder Type: external" & "Build command: make"

before:
activate build enviroment & go to your zephyr project. create build dir, run cmake

2.) debug from eclipse

the open ocd debuger from the gnu mcu pulgin works best (https://gnu-mcu-eclipse.github.io/debug/openocd/)

create a new run config & and reset the paths:
openocd binary form the /opt/... dir

openocd.cfg from the board config

run west debugserver and start the eclipse debug config


Good luck

Stefan


On 09/11/2018 19:13, Nicholas Yameen wrote:

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

 

 
2201 - 2220 of 7600