You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Andrey Serdtsev <an...@yotadevices.com> on 2017/04/11 14:36:58 UTC
NRF_RADIO->TXEN on nRF51 is never changed
Hi there.
Would like to know if someone ever test nimble on nRF51? There is a
mynewt port for nRF51DK but I fail to make it work.
It looks like that nRF51 BLE Tx code is broken. I tried to add gdb
watchpoint to address 0x40001000 (where NRF_RADIO->TASKS_TXEN mapped):
it never hits, i.e, Tx is never started and I can't see my advertising
packets.
I use code from master branch, starting from here:
commit a7b80beee894584c6b32d90e925518784f375504
Author: Marko Kiiskila <ma...@runtime.io>
Date: Wed Mar 22 11:40:39 2017 -0700
repository.yml; add 1.0.0 tag
I don't see similar problems in mailing list. Either nobody tried nRF51
before or I'm doing something wrong. Any suggestions?
Many thanks.
BR,
Andrey
Re: NRF_RADIO->TXEN on nRF51 is never changed
Posted by Andrey Serdtsev <an...@yotadevices.com>.
Hi, Will
Yes, with optimization it works even with 100us delay. And it looks like
no more BLE controller's LL task stack corruption too.
Well, look forward for 1.1.0 release, where
https://issues.apache.org/jira/browse/MYNEWT-400 will be implemented. It
would be much easier to integrate mynewt.
Thank you for your help.
BR,
Andrey
On 19.04.2017 21:03, will sanfilippo wrote:
> Andrey:
>
> As you have noticed, the timing on the nrf51 is extremely tight. If you use a different compiler with different optimzations I could see where we would not have enough time to perform certain operations. The statistics should point in the right direction when there are timing issues although there is no documentation on the stats to tell you what is going wrong so you need to dig through the code.
>
> BTW: in our nrf51 builds we do not see many (occasional) tx lates. You could change XCVR_PROC_DELAY_USECS but that affects more than just advertising.
>
> We build our optimized builds with -Os btw, so you should as well.
>
> Does -Os fix your late advertising issue as well? If you keep the processing delay at 100usecs and build with -Os do you see late transmits?
>
> BTW: we construct the advertising PDU just prior to transmitting it (it occurs during that PROC delay). We could modify the code such that we build the advertising PDU ahead of time. There were reasons it was done the way it was done but in retrospect this could be changed. For now, doing what you did should work but I would hope that -Os would fix things.
>
>> On Apr 19, 2017, at 10:22 AM, Andrey Serdtsev <an...@yotadevices.com> wrote:
>>
>> Hi, Will
>>
>> It looks like I stepped on every possible rake while migrating to mynewt.
>>
>> Here is what I have for now:
>>
>> 1. After enabling ble_phy_stats & ble_ll_stats I saw big values of tx_late counters. This was the cause of "invisible" advertising packets: just not tx'ed. As a workaround I increase XCVR_PROC_DELAY_USECS value from 100 to 150. After this advertising comes to life, hcitool lescan list my device.
>> Is approach with XCVR_PROC_DELAY_USECS is correct or there is a better way exist?
>>
>> 2. Then my device wasn't listed by Android apps. At the same time bt_snoop log shows that advertising packets were successfully received. I.e., Android stack drops my packets and doesn't pass them to upper levels. Investigation shows that my device doesn't send SCAN_RSP.
>> Again, I checked stats and saw big value of srx_scan_reqs counter and zero value of sscan_rsp_txg. After some digging I realize that ble_phy_tx() call in the end of ble_ll_adv_rx_req() always return 1 (BLE_PHY_ERR_RADIO_STATE).
>> After reviewing of ble_phy driver it becomes clear that LL work too slow to be in time with disabled->txen shortcut, which is is installed by rx prepare procedure. When LL calls ble_phy_tx() this shortcut is already switches radio to Tx state. And this state is considered as wrong by ble_phy_tx().
>> Common suggestion is that some delay required between "disabled" event and "txen" task to allow for LL to prepare scan response. At the moment I have no idea how to implement this:(
>> Good workaround is to use GCC optimization. -Ofast doesn't change anything. But -Os works great: my device was listed by Android app, i.e., SCAN_RSP comes to ble_phy in time.
>>
>>
>> On 11.04.2017 19:46, will sanfilippo wrote:
>>> No need to apologize; but even the kick in the right direction should not address your issue. I just built a test program (bletest) which does advertising and it is advertising fine on the nrf51. If you cannot share your target, what app are you building?
>>>
>>> Assuming you have statistics enabled you can take a look at the phy stats and LL stats. You can use the console to display them (if you are building with that) or you can halt in the debugger and look at the following variables:
>>>
>>> p ble_phy_stats
>>> p ble_ll_stats
>>>
>>> If they are hard to interpret, paste them and send them to us and we will decipher.
>>>
>>> PS: I will say this though (just my opinion): the newt tool and build and package management system simply blows away a makefile any day of the week, and twice on Sunday!
>>>
>>>> On Apr 11, 2017, at 8:17 AM, Andrey Serdtsev <an...@yotadevices.com> wrote:
>>>>
>>>> Will,
>>>>
>>>> Thank you for the kick in the right direction. I miss that disabled->txen shortcut exists, will dig it tomorrow (my day is finished, I need to go).
>>>> Can't show you 'newt target' output since we use GNUmake instead of newt build. Go is too exotic for our embedded team) Even python-based SCons is more comfortable than Go. Sorry.
>>>>
>>>> Thank you for your help.
>>>>
>>>> BR,
>>>> Andrey
>>>>
>>>>
>>>> On 11.04.2017 17:46, will sanfilippo wrote:
>>>>> Andrey:
>>>>>
>>>>> The PHY code does not write directly to TASKS_TXEN; it uses shortcuts to automatically start transmissions.
>>>>>
>>>>> Can you show me the target you are using? Just paste the output of: newt target show <your_target_name>
>>>>>
>>>>> We test regularly with the nrf51 but that does not mean that a particular commit in time may have issues. I will give it a try in a bit (well, I just woke up so it might be an hour or so) :-)
>>>>>
>>>>>
>>>>>> On Apr 11, 2017, at 7:36 AM, Andrey Serdtsev <an...@yotadevices.com> wrote:
>>>>>>
>>>>>> Hi there.
>>>>>>
>>>>>> Would like to know if someone ever test nimble on nRF51? There is a mynewt port for nRF51DK but I fail to make it work.
>>>>>> It looks like that nRF51 BLE Tx code is broken. I tried to add gdb watchpoint to address 0x40001000 (where NRF_RADIO->TASKS_TXEN mapped): it never hits, i.e, Tx is never started and I can't see my advertising packets.
>>>>>> I use code from master branch, starting from here:
>>>>>> commit a7b80beee894584c6b32d90e925518784f375504
>>>>>> Author: Marko Kiiskila <ma...@runtime.io>
>>>>>> Date: Wed Mar 22 11:40:39 2017 -0700
>>>>>> repository.yml; add 1.0.0 tag
>>>>>>
>>>>>> I don't see similar problems in mailing list. Either nobody tried nRF51 before or I'm doing something wrong. Any suggestions?
>>>>>>
>>>>>> Many thanks.
>>>>>>
>>>>>> BR,
>>>>>> Andrey
>>>>>>
Re: NRF_RADIO->TXEN on nRF51 is never changed
Posted by will sanfilippo <wi...@runtime.io>.
Andrey:
As you have noticed, the timing on the nrf51 is extremely tight. If you use a different compiler with different optimzations I could see where we would not have enough time to perform certain operations. The statistics should point in the right direction when there are timing issues although there is no documentation on the stats to tell you what is going wrong so you need to dig through the code.
BTW: in our nrf51 builds we do not see many (occasional) tx lates. You could change XCVR_PROC_DELAY_USECS but that affects more than just advertising.
We build our optimized builds with -Os btw, so you should as well.
Does -Os fix your late advertising issue as well? If you keep the processing delay at 100usecs and build with -Os do you see late transmits?
BTW: we construct the advertising PDU just prior to transmitting it (it occurs during that PROC delay). We could modify the code such that we build the advertising PDU ahead of time. There were reasons it was done the way it was done but in retrospect this could be changed. For now, doing what you did should work but I would hope that -Os would fix things.
> On Apr 19, 2017, at 10:22 AM, Andrey Serdtsev <an...@yotadevices.com> wrote:
>
> Hi, Will
>
> It looks like I stepped on every possible rake while migrating to mynewt.
>
> Here is what I have for now:
>
> 1. After enabling ble_phy_stats & ble_ll_stats I saw big values of tx_late counters. This was the cause of "invisible" advertising packets: just not tx'ed. As a workaround I increase XCVR_PROC_DELAY_USECS value from 100 to 150. After this advertising comes to life, hcitool lescan list my device.
> Is approach with XCVR_PROC_DELAY_USECS is correct or there is a better way exist?
>
> 2. Then my device wasn't listed by Android apps. At the same time bt_snoop log shows that advertising packets were successfully received. I.e., Android stack drops my packets and doesn't pass them to upper levels. Investigation shows that my device doesn't send SCAN_RSP.
> Again, I checked stats and saw big value of srx_scan_reqs counter and zero value of sscan_rsp_txg. After some digging I realize that ble_phy_tx() call in the end of ble_ll_adv_rx_req() always return 1 (BLE_PHY_ERR_RADIO_STATE).
> After reviewing of ble_phy driver it becomes clear that LL work too slow to be in time with disabled->txen shortcut, which is is installed by rx prepare procedure. When LL calls ble_phy_tx() this shortcut is already switches radio to Tx state. And this state is considered as wrong by ble_phy_tx().
> Common suggestion is that some delay required between "disabled" event and "txen" task to allow for LL to prepare scan response. At the moment I have no idea how to implement this:(
> Good workaround is to use GCC optimization. -Ofast doesn't change anything. But -Os works great: my device was listed by Android app, i.e., SCAN_RSP comes to ble_phy in time.
>
>
> On 11.04.2017 19:46, will sanfilippo wrote:
>> No need to apologize; but even the kick in the right direction should not address your issue. I just built a test program (bletest) which does advertising and it is advertising fine on the nrf51. If you cannot share your target, what app are you building?
>>
>> Assuming you have statistics enabled you can take a look at the phy stats and LL stats. You can use the console to display them (if you are building with that) or you can halt in the debugger and look at the following variables:
>>
>> p ble_phy_stats
>> p ble_ll_stats
>>
>> If they are hard to interpret, paste them and send them to us and we will decipher.
>>
>> PS: I will say this though (just my opinion): the newt tool and build and package management system simply blows away a makefile any day of the week, and twice on Sunday!
>>
>>> On Apr 11, 2017, at 8:17 AM, Andrey Serdtsev <an...@yotadevices.com> wrote:
>>>
>>> Will,
>>>
>>> Thank you for the kick in the right direction. I miss that disabled->txen shortcut exists, will dig it tomorrow (my day is finished, I need to go).
>>> Can't show you 'newt target' output since we use GNUmake instead of newt build. Go is too exotic for our embedded team) Even python-based SCons is more comfortable than Go. Sorry.
>>>
>>> Thank you for your help.
>>>
>>> BR,
>>> Andrey
>>>
>>>
>>> On 11.04.2017 17:46, will sanfilippo wrote:
>>>> Andrey:
>>>>
>>>> The PHY code does not write directly to TASKS_TXEN; it uses shortcuts to automatically start transmissions.
>>>>
>>>> Can you show me the target you are using? Just paste the output of: newt target show <your_target_name>
>>>>
>>>> We test regularly with the nrf51 but that does not mean that a particular commit in time may have issues. I will give it a try in a bit (well, I just woke up so it might be an hour or so) :-)
>>>>
>>>>
>>>>> On Apr 11, 2017, at 7:36 AM, Andrey Serdtsev <an...@yotadevices.com> wrote:
>>>>>
>>>>> Hi there.
>>>>>
>>>>> Would like to know if someone ever test nimble on nRF51? There is a mynewt port for nRF51DK but I fail to make it work.
>>>>> It looks like that nRF51 BLE Tx code is broken. I tried to add gdb watchpoint to address 0x40001000 (where NRF_RADIO->TASKS_TXEN mapped): it never hits, i.e, Tx is never started and I can't see my advertising packets.
>>>>> I use code from master branch, starting from here:
>>>>> commit a7b80beee894584c6b32d90e925518784f375504
>>>>> Author: Marko Kiiskila <ma...@runtime.io>
>>>>> Date: Wed Mar 22 11:40:39 2017 -0700
>>>>> repository.yml; add 1.0.0 tag
>>>>>
>>>>> I don't see similar problems in mailing list. Either nobody tried nRF51 before or I'm doing something wrong. Any suggestions?
>>>>>
>>>>> Many thanks.
>>>>>
>>>>> BR,
>>>>> Andrey
>>>>>
>
Re: NRF_RADIO->TXEN on nRF51 is never changed
Posted by Andrey Serdtsev <an...@yotadevices.com>.
Hi, Will
It looks like I stepped on every possible rake while migrating to mynewt.
Here is what I have for now:
1. After enabling ble_phy_stats & ble_ll_stats I saw big values of
tx_late counters. This was the cause of "invisible" advertising packets:
just not tx'ed. As a workaround I increase XCVR_PROC_DELAY_USECS value
from 100 to 150. After this advertising comes to life, hcitool lescan
list my device.
Is approach with XCVR_PROC_DELAY_USECS is correct or there is a better
way exist?
2. Then my device wasn't listed by Android apps. At the same time
bt_snoop log shows that advertising packets were successfully received.
I.e., Android stack drops my packets and doesn't pass them to upper
levels. Investigation shows that my device doesn't send SCAN_RSP.
Again, I checked stats and saw big value of srx_scan_reqs counter and
zero value of sscan_rsp_txg. After some digging I realize that
ble_phy_tx() call in the end of ble_ll_adv_rx_req() always return 1
(BLE_PHY_ERR_RADIO_STATE).
After reviewing of ble_phy driver it becomes clear that LL work too slow
to be in time with disabled->txen shortcut, which is is installed by rx
prepare procedure. When LL calls ble_phy_tx() this shortcut is already
switches radio to Tx state. And this state is considered as wrong by
ble_phy_tx().
Common suggestion is that some delay required between "disabled" event
and "txen" task to allow for LL to prepare scan response. At the moment
I have no idea how to implement this:(
Good workaround is to use GCC optimization. -Ofast doesn't change
anything. But -Os works great: my device was listed by Android app,
i.e., SCAN_RSP comes to ble_phy in time.
On 11.04.2017 19:46, will sanfilippo wrote:
> No need to apologize; but even the kick in the right direction should not address your issue. I just built a test program (bletest) which does advertising and it is advertising fine on the nrf51. If you cannot share your target, what app are you building?
>
> Assuming you have statistics enabled you can take a look at the phy stats and LL stats. You can use the console to display them (if you are building with that) or you can halt in the debugger and look at the following variables:
>
> p ble_phy_stats
> p ble_ll_stats
>
> If they are hard to interpret, paste them and send them to us and we will decipher.
>
> PS: I will say this though (just my opinion): the newt tool and build and package management system simply blows away a makefile any day of the week, and twice on Sunday!
>
>> On Apr 11, 2017, at 8:17 AM, Andrey Serdtsev <an...@yotadevices.com> wrote:
>>
>> Will,
>>
>> Thank you for the kick in the right direction. I miss that disabled->txen shortcut exists, will dig it tomorrow (my day is finished, I need to go).
>> Can't show you 'newt target' output since we use GNUmake instead of newt build. Go is too exotic for our embedded team) Even python-based SCons is more comfortable than Go. Sorry.
>>
>> Thank you for your help.
>>
>> BR,
>> Andrey
>>
>>
>> On 11.04.2017 17:46, will sanfilippo wrote:
>>> Andrey:
>>>
>>> The PHY code does not write directly to TASKS_TXEN; it uses shortcuts to automatically start transmissions.
>>>
>>> Can you show me the target you are using? Just paste the output of: newt target show <your_target_name>
>>>
>>> We test regularly with the nrf51 but that does not mean that a particular commit in time may have issues. I will give it a try in a bit (well, I just woke up so it might be an hour or so) :-)
>>>
>>>
>>>> On Apr 11, 2017, at 7:36 AM, Andrey Serdtsev <an...@yotadevices.com> wrote:
>>>>
>>>> Hi there.
>>>>
>>>> Would like to know if someone ever test nimble on nRF51? There is a mynewt port for nRF51DK but I fail to make it work.
>>>> It looks like that nRF51 BLE Tx code is broken. I tried to add gdb watchpoint to address 0x40001000 (where NRF_RADIO->TASKS_TXEN mapped): it never hits, i.e, Tx is never started and I can't see my advertising packets.
>>>> I use code from master branch, starting from here:
>>>> commit a7b80beee894584c6b32d90e925518784f375504
>>>> Author: Marko Kiiskila <ma...@runtime.io>
>>>> Date: Wed Mar 22 11:40:39 2017 -0700
>>>> repository.yml; add 1.0.0 tag
>>>>
>>>> I don't see similar problems in mailing list. Either nobody tried nRF51 before or I'm doing something wrong. Any suggestions?
>>>>
>>>> Many thanks.
>>>>
>>>> BR,
>>>> Andrey
>>>>
Re: NRF_RADIO->TXEN on nRF51 is never changed
Posted by will sanfilippo <wi...@runtime.io>.
No need to apologize; but even the kick in the right direction should not address your issue. I just built a test program (bletest) which does advertising and it is advertising fine on the nrf51. If you cannot share your target, what app are you building?
Assuming you have statistics enabled you can take a look at the phy stats and LL stats. You can use the console to display them (if you are building with that) or you can halt in the debugger and look at the following variables:
p ble_phy_stats
p ble_ll_stats
If they are hard to interpret, paste them and send them to us and we will decipher.
PS: I will say this though (just my opinion): the newt tool and build and package management system simply blows away a makefile any day of the week, and twice on Sunday!
> On Apr 11, 2017, at 8:17 AM, Andrey Serdtsev <an...@yotadevices.com> wrote:
>
> Will,
>
> Thank you for the kick in the right direction. I miss that disabled->txen shortcut exists, will dig it tomorrow (my day is finished, I need to go).
> Can't show you 'newt target' output since we use GNUmake instead of newt build. Go is too exotic for our embedded team) Even python-based SCons is more comfortable than Go. Sorry.
>
> Thank you for your help.
>
> BR,
> Andrey
>
>
> On 11.04.2017 17:46, will sanfilippo wrote:
>> Andrey:
>>
>> The PHY code does not write directly to TASKS_TXEN; it uses shortcuts to automatically start transmissions.
>>
>> Can you show me the target you are using? Just paste the output of: newt target show <your_target_name>
>>
>> We test regularly with the nrf51 but that does not mean that a particular commit in time may have issues. I will give it a try in a bit (well, I just woke up so it might be an hour or so) :-)
>>
>>
>>> On Apr 11, 2017, at 7:36 AM, Andrey Serdtsev <an...@yotadevices.com> wrote:
>>>
>>> Hi there.
>>>
>>> Would like to know if someone ever test nimble on nRF51? There is a mynewt port for nRF51DK but I fail to make it work.
>>> It looks like that nRF51 BLE Tx code is broken. I tried to add gdb watchpoint to address 0x40001000 (where NRF_RADIO->TASKS_TXEN mapped): it never hits, i.e, Tx is never started and I can't see my advertising packets.
>>> I use code from master branch, starting from here:
>>> commit a7b80beee894584c6b32d90e925518784f375504
>>> Author: Marko Kiiskila <ma...@runtime.io>
>>> Date: Wed Mar 22 11:40:39 2017 -0700
>>> repository.yml; add 1.0.0 tag
>>>
>>> I don't see similar problems in mailing list. Either nobody tried nRF51 before or I'm doing something wrong. Any suggestions?
>>>
>>> Many thanks.
>>>
>>> BR,
>>> Andrey
>>>
>
Re: NRF_RADIO->TXEN on nRF51 is never changed
Posted by Andrey Serdtsev <an...@yotadevices.com>.
Will,
Thank you for the kick in the right direction. I miss that
disabled->txen shortcut exists, will dig it tomorrow (my day is
finished, I need to go).
Can't show you 'newt target' output since we use GNUmake instead of newt
build. Go is too exotic for our embedded team) Even python-based SCons
is more comfortable than Go. Sorry.
Thank you for your help.
BR,
Andrey
On 11.04.2017 17:46, will sanfilippo wrote:
> Andrey:
>
> The PHY code does not write directly to TASKS_TXEN; it uses shortcuts to automatically start transmissions.
>
> Can you show me the target you are using? Just paste the output of: newt target show <your_target_name>
>
> We test regularly with the nrf51 but that does not mean that a particular commit in time may have issues. I will give it a try in a bit (well, I just woke up so it might be an hour or so) :-)
>
>
>> On Apr 11, 2017, at 7:36 AM, Andrey Serdtsev <an...@yotadevices.com> wrote:
>>
>> Hi there.
>>
>> Would like to know if someone ever test nimble on nRF51? There is a mynewt port for nRF51DK but I fail to make it work.
>> It looks like that nRF51 BLE Tx code is broken. I tried to add gdb watchpoint to address 0x40001000 (where NRF_RADIO->TASKS_TXEN mapped): it never hits, i.e, Tx is never started and I can't see my advertising packets.
>> I use code from master branch, starting from here:
>> commit a7b80beee894584c6b32d90e925518784f375504
>> Author: Marko Kiiskila <ma...@runtime.io>
>> Date: Wed Mar 22 11:40:39 2017 -0700
>> repository.yml; add 1.0.0 tag
>>
>> I don't see similar problems in mailing list. Either nobody tried nRF51 before or I'm doing something wrong. Any suggestions?
>>
>> Many thanks.
>>
>> BR,
>> Andrey
>>
Re: NRF_RADIO->TXEN on nRF51 is never changed
Posted by will sanfilippo <wi...@runtime.io>.
Andrey:
The PHY code does not write directly to TASKS_TXEN; it uses shortcuts to automatically start transmissions.
Can you show me the target you are using? Just paste the output of: newt target show <your_target_name>
We test regularly with the nrf51 but that does not mean that a particular commit in time may have issues. I will give it a try in a bit (well, I just woke up so it might be an hour or so) :-)
> On Apr 11, 2017, at 7:36 AM, Andrey Serdtsev <an...@yotadevices.com> wrote:
>
> Hi there.
>
> Would like to know if someone ever test nimble on nRF51? There is a mynewt port for nRF51DK but I fail to make it work.
> It looks like that nRF51 BLE Tx code is broken. I tried to add gdb watchpoint to address 0x40001000 (where NRF_RADIO->TASKS_TXEN mapped): it never hits, i.e, Tx is never started and I can't see my advertising packets.
> I use code from master branch, starting from here:
> commit a7b80beee894584c6b32d90e925518784f375504
> Author: Marko Kiiskila <ma...@runtime.io>
> Date: Wed Mar 22 11:40:39 2017 -0700
> repository.yml; add 1.0.0 tag
>
> I don't see similar problems in mailing list. Either nobody tried nRF51 before or I'm doing something wrong. Any suggestions?
>
> Many thanks.
>
> BR,
> Andrey
>