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 > <andrey.serdt...@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 >>> <andrey.serdt...@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 >>>>> <andrey.serdt...@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 >>>>> >
