Date   

Re: USB fails to enumerate on nrf52840_pca10056 board

Johann Fischer
 

Can not confirm, woks fine on the latest master and on 77006e896.

Johann

On Wed, 27 Nov 2019 16:50:02 +0000
"Cufi, Carles" <carles.cufi@nordicsemi.no> wrote:

Hi Steve,

Is this a regression? Have you tested this with an earlier Zephyr version/revision that worked?
We use this board routinely to test the USB stack and haven't run into this problem.

Can you please also share more details about the USB Host (Linux I assume) and the way you build the samples?

Thanks,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Steve Brown via Lists.Zephyrproject.Org
Sent: 27 November 2019 17:37
To: devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] USB fails to enumerate on nrf52840_pca10056
board

All the USB samples and tests fail to enumerate.
git HEAD 77006e896

Output from the desc_sections test is below:

Nov 27 09:11:57 nm-ws kernel: [520538.130145] usb 7-2: USB disconnect,
device number 65 Nov 27 09:12:00 nm-ws kernel: [520542.088211] usb 7-2:
new full-speed USB device number 66 using ohci-pci Nov 27 09:12:06 nm-ws
kernel: [520547.360327] usb 7-2: device descriptor read/all, error -110
Nov 27 09:12:06 nm-ws kernel: [520547.516218] usb 7-2: new full-speed
USB device number 67 using ohci-pci

And the relevant nrf console output:

D: ep 0, status 0
D: ** 0 **
D: bRequest 0x6, wIndex 0x0
D: REQ_GET_DESCRIPTOR


The Nordic usbd_cdc_acm_pca10056.hex works on the same board:

Nov 27 09:09:32 nm-ws kernel: [520393.141205] usb 7-2: USB disconnect,
device number 64 Nov 27 09:09:32 nm-ws kernel: [520393.735742] usb 7-2:
new full-speed USB device number 65 using ohci-pci Nov 27 09:09:32 nm-ws
kernel: [520393.938828] usb 7-2: New USB device found, idVendor=1915,
idProduct=520f, bcdDevice= 1.00 Nov 27 09:09:32 nm-ws kernel:
[520393.938834] usb 7-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3 Nov 27 09:09:32 nm-ws kernel: [520393.938838] usb 7-2:
Product: nRF52 USB CDC Demo Nov 27 09:09:32 nm-ws kernel:
[520393.938841] usb 7-2: Manufacturer: Nordic Semiconductor Nov 27
09:09:32 nm-ws kernel: [520393.938843] usb 7-2: SerialNumber:
796cadf8f13bbb37 Nov 27 09:09:32 nm-ws kernel: [520393.940987] cdc_acm
7-2:1.0: ttyACM1: USB ACM device

Steve





Re: USB fails to enumerate on nrf52840_pca10056 board

Carles Cufi
 

Hi Steve,

Is this a regression? Have you tested this with an earlier Zephyr version/revision that worked?
We use this board routinely to test the USB stack and haven't run into this problem.

Can you please also share more details about the USB Host (Linux I assume) and the way you build the samples?

Thanks,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Steve Brown via Lists.Zephyrproject.Org
Sent: 27 November 2019 17:37
To: devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] USB fails to enumerate on nrf52840_pca10056
board

All the USB samples and tests fail to enumerate.
git HEAD 77006e896

Output from the desc_sections test is below:

Nov 27 09:11:57 nm-ws kernel: [520538.130145] usb 7-2: USB disconnect,
device number 65 Nov 27 09:12:00 nm-ws kernel: [520542.088211] usb 7-2:
new full-speed USB device number 66 using ohci-pci Nov 27 09:12:06 nm-ws
kernel: [520547.360327] usb 7-2: device descriptor read/all, error -110
Nov 27 09:12:06 nm-ws kernel: [520547.516218] usb 7-2: new full-speed
USB device number 67 using ohci-pci

And the relevant nrf console output:

D: ep 0, status 0
D: ** 0 **
D: bRequest 0x6, wIndex 0x0
D: REQ_GET_DESCRIPTOR


The Nordic usbd_cdc_acm_pca10056.hex works on the same board:

Nov 27 09:09:32 nm-ws kernel: [520393.141205] usb 7-2: USB disconnect,
device number 64 Nov 27 09:09:32 nm-ws kernel: [520393.735742] usb 7-2:
new full-speed USB device number 65 using ohci-pci Nov 27 09:09:32 nm-ws
kernel: [520393.938828] usb 7-2: New USB device found, idVendor=1915,
idProduct=520f, bcdDevice= 1.00 Nov 27 09:09:32 nm-ws kernel:
[520393.938834] usb 7-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3 Nov 27 09:09:32 nm-ws kernel: [520393.938838] usb 7-2:
Product: nRF52 USB CDC Demo Nov 27 09:09:32 nm-ws kernel:
[520393.938841] usb 7-2: Manufacturer: Nordic Semiconductor Nov 27
09:09:32 nm-ws kernel: [520393.938843] usb 7-2: SerialNumber:
796cadf8f13bbb37 Nov 27 09:09:32 nm-ws kernel: [520393.940987] cdc_acm
7-2:1.0: ttyACM1: USB ACM device

Steve



USB fails to enumerate on nrf52840_pca10056 board

Steve Brown
 

All the USB samples and tests fail to enumerate.
git HEAD 77006e896

Output from the desc_sections test is below:

Nov 27 09:11:57 nm-ws kernel: [520538.130145] usb 7-2: USB disconnect, device number 65
Nov 27 09:12:00 nm-ws kernel: [520542.088211] usb 7-2: new full-speed USB device number 66 using ohci-pci
Nov 27 09:12:06 nm-ws kernel: [520547.360327] usb 7-2: device descriptor read/all, error -110
Nov 27 09:12:06 nm-ws kernel: [520547.516218] usb 7-2: new full-speed USB device number 67 using ohci-pci

And the relevant nrf console output:

D: ep 0, status 0
D: ** 0 **
D: bRequest 0x6, wIndex 0x0
D: REQ_GET_DESCRIPTOR


The Nordic usbd_cdc_acm_pca10056.hex works on the same board:

Nov 27 09:09:32 nm-ws kernel: [520393.141205] usb 7-2: USB disconnect, device number 64
Nov 27 09:09:32 nm-ws kernel: [520393.735742] usb 7-2: new full-speed USB device number 65 using ohci-pci
Nov 27 09:09:32 nm-ws kernel: [520393.938828] usb 7-2: New USB device found, idVendor=1915, idProduct=520f, bcdDevice= 1.00
Nov 27 09:09:32 nm-ws kernel: [520393.938834] usb 7-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 27 09:09:32 nm-ws kernel: [520393.938838] usb 7-2: Product: nRF52 USB CDC Demo
Nov 27 09:09:32 nm-ws kernel: [520393.938841] usb 7-2: Manufacturer: Nordic Semiconductor
Nov 27 09:09:32 nm-ws kernel: [520393.938843] usb 7-2: SerialNumber: 796cadf8f13bbb37
Nov 27 09:09:32 nm-ws kernel: [520393.940987] cdc_acm 7-2:1.0: ttyACM1: USB ACM device

Steve


Upcoming Event: Zephyr Project: APIs - Tue, 11/26/2019 9:00am-10:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 26 November 2019, 9:00am to 10:00am, (GMT-08:00) America/Los Angeles

Where:https://zoom.us/j/177647878

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY


 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing


API meeting: agenda

Carles Cufi
 

Hi all,

This week we will look at:

- PWM, USB and clock_control APIs in the context of stable APIs
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/20657
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/20375
- PR: https://github.com/zephyrproject-rtos/zephyr/issues/20806
- Doc for stable APIs: https://docs.zephyrproject.org/latest/development_process/api_lifecycle.html#stable

- GPIO: Update on progress
- Look at the PRs with driver conversion (https://github.com/zephyrproject-rtos/zephyr/issues/18530)
- Check users of GPIO APIs: https://github.com/zephyrproject-rtos/zephyr/issues/20017
- Tips for converting users can be found here: https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497 (thanks Peter!)
- Any additional outstanding PRs to topic-gpio

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: Problem with running Zephyr from external flash on STM32xx

Jan Pohanka
 

Finally... problem solved.
I found that stack pointer was getting wrong vaule after context switch. Then I noticed that link register during pendsv interrupt indicates floating point exception. After enabling CONFIG_FP_SHARING option everything works fine.
I'm still a bit confused why this was not an issue while running from internal flash. My bootloader does not explicitly use any float operations...

best regards
Jan


Cancel Nov 28th Dev Review Meeting

Kumar Gala
 

I’ve canceled the Nov 28th Dev Review Meeting due to holiday in the US.

- k


Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 28 November 2019 #cal-cancelled

devel@lists.zephyrproject.org Calendar <devel@...>
 

Cancelled: Zephyr Project: Dev Meeting

This event has been cancelled.

When:
Thursday, 28 November 2019
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/j/993312203

Organizer: devel@...

Description:
Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf


Help with porting to the new GPIO API

Carles Cufi
 

Hi all,

As you might know there is a new GPIO API under development in the topic-gpio branch. All drivers should now be ported but the actual users of the GPIO API, which are spread all over the tree, need porting.

The following issue tracks progress with porting those users:

https://github.com/zephyrproject-rtos/zephyr/issues/20017

Our plan is to make the new GPIO API the default for Zephyr 2.2, but in order to achieve that we need to port all users of the API first.

* If you are already assigned to porting one or more users in the issue above, please consider submitting a PR against topic-gpio as early as you can
* If you know the code for any of the unassigned users, or want to learn more about the new GPIO API, feel free to assign yourself (send me an email and I will update the issue) and work on a PR

You can find useful tips for porting to the new API in this comment:

https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497

Feel free to reply to this email or join the #gpio channel on Slack if you have questions.

Thanks in advance!

Carles


Re: Problem with running Zephyr from external flash on STM32xx

Jan Pohanka
 

I have found interesting thing. _oops event that I'm facing when running from external flash is caused by stack sentinel checking so in fact I'm getting a stack corruption - shell thread is overwriting stack of main_thread.
This situation never happens when running from internal flash.

Strange... Where is the context switching done? I need to check, what is setting SP to wrong value.

BR
Jan


Re: about BLE Rx test

Tommy Lin (林志聰) <Tommy.Lin@...>
 

Hi zephyr,

In case2, we also have tried -40dBm(2Mbps) and -60dBm(2Mbps) , and receive 0 bytes.

 

Thanks

Tommy

From: Tommy Lin (林志聰)
Sent: Monday, November 25, 2019 3:28 PM
To: 'Stephanos Io' <assembler@...>; 'Cufi, Carles' <carles.cufi@...>; 'zephyr-devel@...' <zephyr-devel@...>
Cc: 'devel@...' <devel@...>; 'Chettimada, Vinayak Kariappa' <vinayak.kariappa.chettimada@...>; Isaac Chen (
陳尚航) <Isaac_Chen@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>; Jimmy Lee (李俊儀) <jimmylee@...>; 'Hanyu.Hsu@...' <Hanyu.Hsu@...>
Subject: RE: [Zephyr-devel] about BLE Rx test

 

Hi zephyr,

 

[case 1]

RF equipment send some bytes to DUT with -50dBm 1Mbps , and DUT can receive 0x2E81 bytes

 

 

[case 2] RF equipment send some bytes to DUT with -50dBm 2Mbps , but DUT receive 0 bytes

 

 

In case2 , To receiver bytes successfully in 2Mbps , how can I change zephyr source code?

Could you give us some suggestions?

 

Thanks

Tommy

From: Tommy Lin (林志聰)
Sent: Wednesday, November 13, 2019 5:05 PM
To: 'Stephanos Io' <assembler@...>; Cufi, Carles <carles.cufi@...>; zephyr-devel@...
Cc: devel@...; Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>; Isaac Chen (
陳尚航) <Isaac_Chen@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>; Jimmy Lee (李俊儀) <jimmylee@...>; 'Hanyu.Hsu@...' <Hanyu.Hsu@...>
Subject: RE: [Zephyr-devel] about BLE Rx test

 

Hi Stephanos,

Thanks for your response.

I have following question:

1.     By Default  , What data rate (1M or 2M bps) are set in zephyr code ?  if it is 2Mbps , How can I set it to 1Mbps?

 

PS: Our RF equipment only support in 1Mbps.

 

Thanks

Tommy

From: Stephanos Io <assembler@...>
Sent: Tuesday, November 12, 2019 9:51 PM
To: Cufi, Carles <carles.cufi@...>; Tommy Lin (
林志聰) <Tommy.Lin@...>; zephyr-devel@...
Cc: devel@...; Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Subject: RE: [Zephyr-devel] about BLE Rx test

 

Hi,

 

I suppose you are performing RX sensitivity test.

 

> If RF equipment send a dbm above -86 (ex: -85 , -84 , -83 …..), the error message will disappear.

 

Assuming you are testing with BLE 2Mbps PHY, I think this behaviour is only to be expected given that the max. sensitivity is specified at -85 dBm at 2Mbps for nRF51824 (refer to the datasheet).

 

Stephanos

 

From: devel@... <devel@...> On Behalf Of Cufi, Carles
Sent: Tuesday, November 12, 2019 10:38 PM
To: Tommy.Lin@...; zephyr-devel@...
Cc: devel@...; Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Subject: Re: [Zephyr-devel] about BLE Rx test

 

Adding Vinayak.

 

If this depends on the dBm setting it might be a bug actually. I’ll let Vinayak weigh in.

 

Carles

 

 

From: devel@... <devel@...> On Behalf Of Tommy Lin (???) via Lists.Zephyrproject.Org
Sent: 12 November 2019 13:01
To: zephyr-devel@...
Cc: devel@...
Subject: Re: [Zephyr-devel] about BLE Rx test

 

+ jimmy

 

From: Tommy Lin (林志聰)
Sent: Tuesday, November 12, 2019 7:18 PM
To: 'zephyr-devel@...' <zephyr-devel@...>
Cc: Isaac Chen (
陳尚航) <Isaac_Chen@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>; Brent Tsai (蔡旻其) <Brent.Tsai@...>; 'Hanyu.Hsu@...' <Hanyu.Hsu@...>
Subject: RE: about BLE Rx test

 

Hi ,

Sorry , correction.

 

We have a product using nRF51824 with Zephyr v1.13.0.

Our DUT connect with RF equipment.

 

[Test sequence]

Step1: DUT enter Rx mode with HCI command.

Step2: RF equipment send 1500 bytes with -86dbm.

Step3: DUT end Rx mode

After then , DUT will show “tx time out “ error message.

 

 

PS:

1.     If RF equipment send a dbm above -86 (ex: -85 , -84 , -83 …..), the error message will disappear.

2.     We use Zephyr v1.13.0 and v1.14.0 , and the result is the same.

 

Could you give us some suggestions?

 

Thank You,

Tommy

 


Re: about BLE Rx test

Tommy Lin (林志聰) <Tommy.Lin@...>
 

Hi zephyr,

 

[case 1]

RF equipment send some bytes to DUT with -50dBm 1Mbps , and DUT can receive 0x2E81 bytes

 

 

[case 2] RF equipment send some bytes to DUT with -50dBm 2Mbps , but DUT receive 0 bytes

 

 

In case2 , To receiver bytes successfully in 2Mbps , how can I change zephyr source code?

Could you give us some suggestions?

 

Thanks

Tommy

From: Tommy Lin (林志聰)
Sent: Wednesday, November 13, 2019 5:05 PM
To: 'Stephanos Io' <assembler@...>; Cufi, Carles <carles.cufi@...>; zephyr-devel@...
Cc: devel@...; Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>; Isaac Chen (
陳尚航) <Isaac_Chen@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>; Jimmy Lee (李俊儀) <jimmylee@...>; 'Hanyu.Hsu@...' <Hanyu.Hsu@...>
Subject: RE: [Zephyr-devel] about BLE Rx test

 

Hi Stephanos,

Thanks for your response.

I have following question:

1.     By Default  , What data rate (1M or 2M bps) are set in zephyr code ?  if it is 2Mbps , How can I set it to 1Mbps?

 

PS: Our RF equipment only support in 1Mbps.

 

Thanks

Tommy

From: Stephanos Io <assembler@...>
Sent: Tuesday, November 12, 2019 9:51 PM
To: Cufi, Carles <carles.cufi@...>; Tommy Lin (
林志聰) <Tommy.Lin@...>; zephyr-devel@...
Cc: devel@...; Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Subject: RE: [Zephyr-devel] about BLE Rx test

 

Hi,

 

I suppose you are performing RX sensitivity test.

 

> If RF equipment send a dbm above -86 (ex: -85 , -84 , -83 …..), the error message will disappear.

 

Assuming you are testing with BLE 2Mbps PHY, I think this behaviour is only to be expected given that the max. sensitivity is specified at -85 dBm at 2Mbps for nRF51824 (refer to the datasheet).

 

Stephanos

 

From: devel@... <devel@...> On Behalf Of Cufi, Carles
Sent: Tuesday, November 12, 2019 10:38 PM
To: Tommy.Lin@...; zephyr-devel@...
Cc: devel@...; Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Subject: Re: [Zephyr-devel] about BLE Rx test

 

Adding Vinayak.

 

If this depends on the dBm setting it might be a bug actually. I’ll let Vinayak weigh in.

 

Carles

 

 

From: devel@... <devel@...> On Behalf Of Tommy Lin (???) via Lists.Zephyrproject.Org
Sent: 12 November 2019 13:01
To: zephyr-devel@...
Cc: devel@...
Subject: Re: [Zephyr-devel] about BLE Rx test

 

+ jimmy

 

From: Tommy Lin (林志聰)
Sent: Tuesday, November 12, 2019 7:18 PM
To: 'zephyr-devel@...' <zephyr-devel@...>
Cc: Isaac Chen (
陳尚航) <Isaac_Chen@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>; Brent Tsai (蔡旻其) <Brent.Tsai@...>; 'Hanyu.Hsu@...' <Hanyu.Hsu@...>
Subject: RE: about BLE Rx test

 

Hi ,

Sorry , correction.

 

We have a product using nRF51824 with Zephyr v1.13.0.

Our DUT connect with RF equipment.

 

[Test sequence]

Step1: DUT enter Rx mode with HCI command.

Step2: RF equipment send 1500 bytes with -86dbm.

Step3: DUT end Rx mode

After then , DUT will show “tx time out “ error message.

 

 

PS:

1.     If RF equipment send a dbm above -86 (ex: -85 , -84 , -83 …..), the error message will disappear.

2.     We use Zephyr v1.13.0 and v1.14.0 , and the result is the same.

 

Could you give us some suggestions?

 

Thank You,

Tommy

 


Re: about BLE Rx test

Chettimada, Vinayak Kariappa
 

Hi Tommy,

 

To test 2M Phy please use LE Receiver Test Command [v2] with OCF 0x0033 instead of the v1 command you are using.

 

Regards,

Vinayak

 

From: Tommy Lin (林志聰) <Tommy.Lin@...>
Sent: 25 November 2019 09:07
To: Stephanos Io <assembler@...>; Cufi, Carles <Carles.Cufi@...>; zephyr-devel@...
Cc: devel@...; Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>; Isaac Chen (
陳尚航) <Isaac_Chen@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>; Jimmy Lee (李俊儀) <JimmyLee@...>; 'Hanyu.Hsu@...' <Hanyu.Hsu@...>
Subject: RE: [Zephyr-devel] about BLE Rx test

 

Hi zephyr,

In case2, we also have tried -40dBm(2Mbps) and -60dBm(2Mbps) , and receive 0 bytes.

 

Thanks

Tommy

From: Tommy Lin (林志聰)
Sent: Monday, November 25, 2019 3:28 PM
To: 'Stephanos Io' <assembler@...>; 'Cufi, Carles' <carles.cufi@...>; 'zephyr-devel@...' <zephyr-devel@...>
Cc: 'devel@...' <devel@...>; 'Chettimada, Vinayak Kariappa' <vinayak.kariappa.chettimada@...>; Isaac Chen (
陳尚航) <Isaac_Chen@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>; Jimmy Lee (李俊儀) <jimmylee@...>; 'Hanyu.Hsu@...' <Hanyu.Hsu@...>
Subject: RE: [Zephyr-devel] about BLE Rx test

 

Hi zephyr,

 

[case 1]

RF equipment send some bytes to DUT with -50dBm 1Mbps , and DUT can receive 0x2E81 bytes

 

 

[case 2] RF equipment send some bytes to DUT with -50dBm 2Mbps , but DUT receive 0 bytes

 

 

In case2 , To receiver bytes successfully in 2Mbps , how can I change zephyr source code?

Could you give us some suggestions?

 

Thanks

Tommy

From: Tommy Lin (林志聰)
Sent: Wednesday, November 13, 2019 5:05 PM
To: 'Stephanos Io' <assembler@...>; Cufi, Carles <carles.cufi@...>; zephyr-devel@...
Cc: devel@...; Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>; Isaac Chen (
陳尚航) <Isaac_Chen@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>; Jimmy Lee (李俊儀) <jimmylee@...>; 'Hanyu.Hsu@...' <Hanyu.Hsu@...>
Subject: RE: [Zephyr-devel] about BLE Rx test

 

Hi Stephanos,

Thanks for your response.

I have following question:

  1. By Default  , What data rate (1M or 2M bps) are set in zephyr code ?  if it is 2Mbps , How can I set it to 1Mbps?

 

PS: Our RF equipment only support in 1Mbps.

 

Thanks

Tommy

From: Stephanos Io <assembler@...>
Sent: Tuesday, November 12, 2019 9:51 PM
To: Cufi, Carles <carles.cufi@...>; Tommy Lin (
林志聰) <Tommy.Lin@...>; zephyr-devel@...
Cc: devel@...; Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Subject: RE: [Zephyr-devel] about BLE Rx test

 

Hi,

 

I suppose you are performing RX sensitivity test.

 

> If RF equipment send a dbm above -86 (ex: -85 , -84 , -83 …..), the error message will disappear.

 

Assuming you are testing with BLE 2Mbps PHY, I think this behaviour is only to be expected given that the max. sensitivity is specified at -85 dBm at 2Mbps for nRF51824 (refer to the datasheet).

 

Stephanos

 

From: devel@... <devel@...> On Behalf Of Cufi, Carles
Sent: Tuesday, November 12, 2019 10:38 PM
To: Tommy.Lin@...; zephyr-devel@...
Cc: devel@...; Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Subject: Re: [Zephyr-devel] about BLE Rx test

 

Adding Vinayak.

 

If this depends on the dBm setting it might be a bug actually. I’ll let Vinayak weigh in.

 

Carles

 

 

From: devel@... <devel@...> On Behalf Of Tommy Lin (???) via Lists.Zephyrproject.Org
Sent: 12 November 2019 13:01
To: zephyr-devel@...
Cc: devel@...
Subject: Re: [Zephyr-devel] about BLE Rx test

 

+ jimmy

 

From: Tommy Lin (林志聰)
Sent: Tuesday, November 12, 2019 7:18 PM
To: 'zephyr-devel@...' <zephyr-devel@...>
Cc: Isaac Chen (
陳尚航) <Isaac_Chen@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>; Brent Tsai (蔡旻其) <Brent.Tsai@...>; 'Hanyu.Hsu@...' <Hanyu.Hsu@...>
Subject: RE: about BLE Rx test

 

Hi ,

Sorry , correction.

 

We have a product using nRF51824 with Zephyr v1.13.0.

Our DUT connect with RF equipment.

 

[Test sequence]

Step1: DUT enter Rx mode with HCI command.

Step2: RF equipment send 1500 bytes with -86dbm.

Step3: DUT end Rx mode

After then , DUT will show “tx time out “ error message.

 

 

PS:

  1. If RF equipment send a dbm above -86 (ex: -85 , -84 , -83 …..), the error message will disappear.
  2. We use Zephyr v1.13.0 and v1.14.0 , and the result is the same.

 

Could you give us some suggestions?

 

Thank You,

Tommy

 


Re: Problem with running Zephyr from external flash on STM32xx

Jan Pohanka
 

I'm quite sure that content of the flash is correct. I use openocd (pending commit with stmqspi support) for flash programming and verify is ok. Moreover simple code with blinking led or even Zephyr with just a loop without sleep in main works. It looks like there is some kernel issue, but I do not find the source of the problem yet...


Is there a way to handle BLE hci_event directly in my thread? #hci #nrf52840 #ble

loquat3
 

In the current implementation, BLE HCI_EVENT is processed on a dedicated RX_THREAD and called back in the same context.
I want to handle HCI_EVENT (eg advvertise_report) directly in my thread.
Is there any way?


Re: Problem with running Zephyr from external flash on STM32xx

laczenJMS
 

Hi Jan,

There are many things that can go wrong here. I would start by checking that what is in the qspi flash is equal to what you want. How do you write the program to the flash ?

Kind regards,

Jehudi


Re: about the difference of device tree use method compare with linux?

Marc Herbert
 

On 22 Nov 2019, at 00:25, pawel.dunaj@nordicsemi.no wrote:

Personally I am not convinced DTS should be used in Zephyr due to this limitation. Since it is not a separate system component you cannot embed HW configuration that would stay on the board regardless of the FW. Anyway somebody thought it would be nice to separate things related to HW into DTS. I think however that this splits configuration into two (HW vs FW) without any good use case.

Run-time aspects aside, I (naively?) believe using a different language enforces a much cleaner and maintainable separation between generic code and hardware specific configuration.

The Linux kernel had both - weren't board files messy because mixing up the two? With a lot of duplication? It'd be nice if someone who remembers board files could comment.

Now this doesn't come for free: just google "device tree stable ABI" - which... I think indirectly proves the point about board files.


PS: I doubt anyone would suggest using C code for (K)configuration.


Re: Problem with running Zephyr from external flash on STM32xx

Jan Pohanka
 

On Fri, Nov 22, 2019 at 07:35 AM, Erwan Gouriou wrote:
One point though, are you using same usart peripheral on console and shell ?
If not, this could be strangely similar to https://github.com/zephyrproject-rtos/zephyr/issues/20068
which has been seen on internal flash as well.
Thanks you for suggestion, but this probably is not related. I use the same UART and moreover all works normally when running from internal flash. In fact only change is in linking for internal flash FLASH is located in 0x08000000 for external 0x90000000. The memory mapped QSPI is working fine. I reach the main function

void main(void)
{
while (1) {
printk("Hello World! %s\n", CONFIG_BOARD);
k_sleep(K_MSEC(500));
}
}

but second call to k_sleep ends in fault. The arch_system_halt is called from main thread.... Surprisingly no fault message is prined out even if it is enabled.

br
Jan


Re: Problem with running Zephyr from external flash on STM32xx

Erwan Gouriou
 

Hi Jan,

If you're able to go till the main function, I guess this means QSPI configuration is working correctly.
If issue happens following k_sleep call, I'd check potential syscall check issue, but on that side
a kernel expert might be more helpful than myself.

One point though, are you using same usart peripheral on console and shell ?
If not, this could be strangely similar to https://github.com/zephyrproject-rtos/zephyr/issues/20068
which has been seen on internal flash as well.

Cheers
Erwan

On Fri, 22 Nov 2019 at 15:14, Jan Pohanka <xhpohanka@...> wrote:
Hello,
I'm trying to run zephyr using external QSPI flash on custom board with stm32h750vb cpu. I thought that it should be as easy as just changing FLASH_BASE_ADDRESS to correct value (0x90000000 for stm32x) but unfortunately that is not the case.
I have very simple bootloader sitting in internal flash that just sets up the QSPI peripheral to memory mapped mode, correct stack pointer and jumps to starting address of zephyr in external flash. There is just hello world application with shell and logging enabled. Zephyr unfortunately ends in arch_system_halt very soon - immediately when k_sleep is called from main function. I was not able yet to find the source of the problem. When the same application is linked to internal flash, everything works fine.
Can someone give me any hint, please?
 
best regards
Jan


Re: Is the devicetree in zephyr sdk supports the dynamic running time flow control ?

Christopher Friedt
 



On Wed., Nov. 20, 2019, 6:11 a.m. "曹子龙, <caozilong@...> wrote:
but in zephyr sdk, the dts are commpiled to a intermidate dts script file, whi
is this right?  and is there anyway to get the configuration in runtime in zephyr?

Personally, I think that the build-time / compile-time DeviceTree usage in Zephyr is actually pretty elegant.

However, there is nothing stopping anyone from adding a libfdt to Zephyr for runtime examination of device tree binaries. It's just not as common to do so on a microcontroller platform.

Once you have the .dtb, you can quite easily convert it to a C array using something like xxd.

I would strongly encourage gzip compression to be used for compressing the .dtb though (assuming it was constant data and the dtb was only there for examination). Otherwise it will take up precious code space. At least if memory is dynamically allocated for the uncompressed dtb it can be freed and reused later.

Due to Zephyr's conversion of DTB data to C preprocessor symbols, I do not see live device tree modification being a thing that will be supported in Zephyr anytime soon.

1421 - 1440 of 7934