|
Re: Zephyr as HCI Host
#uart
#bluetoothmesh
#hci
Hi,
On 13 Nov 2018, at 0.38, abaska@intermatic.com wrote: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:
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 toThe 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
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,
|
|||||||||
|
|
|||||||||
|
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
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,
|
|||||||||
|
|
|||||||||
|
Re: Zephyr Project using Eclipse
Serafin
Fwd: List
On 12/11/18 09:44, Serafin wrote:
|
|||||||||
|
|
|||||||||
|
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: before: 2.) debug from eclipse the open ocd debuger from the gnu mcu pulgin works best
(https://gnu-mcu-eclipse.github.io/debug/openocd/) 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:
|
|||||||||
|
|
|||||||||
|
Randy Chou <rchou3@...>
Hi Vinayak,
I merge the patch, host (nRF Connect) get update connection parameter request. After CI change to 30ms, it can keep connection a bit longer but it still disconnect after few minutes (distance is ~2m). If I move host close to device then the connection can keep more than one hour. I also try to change the CI back to 7.5ms and move host far away from device (~2m), the connection is also stable. Do you have any suggestion that I can help to debug this issue? Thanks, Randy
|
|||||||||
|
|
|||||||||
|
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
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: lwip integration with OpenThread
#nrf52840
#lwip
#openthread
deepa.gopinath@...
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/ Thanks & Regards, Deepa
|
|||||||||
|
|
|||||||||
|
Re: thread permissions issue
Diego Sueiro
On Sat, 10 Nov 2018 at 16:59, Diego Sueiro <diego.sueiro@gmail.com> wrote:
I managed to solve this by calling "k_thread_access_grant(k_current_get(), dev, NULL)" before calling the "Z_SYSCALL_DRIVER_SENSOR" macro. 2 - Even having the CONFIG_USERSAPCE=y set when callingThis question remains open.
|
|||||||||
|
|
|||||||||
|
thread permissions issue
Diego Sueiro
Hello Zephyrs,
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. I have the CONFIG_USERSAPCE=y. After calling "dev = device_get_binding(argv[1])" I call the "Z_SYSCALL_DRIVER_SENSOR(dev, sample_fetch)" and I get the following error message: thread 0x2000064c (1) does not have permission on sensor driver 0x20005ac8 [0000] syscall cmd_get_sensor failed check: access denied Some questions: 1 - How do I grant permission to the running thread to access the sensor driver object? 2 - Even having the CONFIG_USERSAPCE=y set when calling "sensor_sample_fetch" it seems that it is calling the "_impl_sensor_sample_fetch" directly instead of "Z_SYSCALL_HANDLER(sensor_sample_fetch, dev)" defined in the drivers/sensor/sensor_handlers.c file. How can I have the current thread using the userspace syscalls? Regards, -- *dS Diego Sueiro
|
|||||||||
|
|
|||||||||
