Hi,
I use the init functions found in porting/nimble and
porting/npl/freertos. There are functions to handle semaphores,
queues,
timers,... Is there any issue with this freertos port, if it's not
official? I did not write any code related to the radio or irq as it
seems to be handled by these functions.
Here is the function I call in my main() to init nimble:
void nimble_port_init(void) {
void os_msys_init(void);
void ble_store_ram_init(void);
ble_npl_eventq_init(&g_eventq_dflt);
os_msys_init();
ble_hs_init();
ble_store_ram_init();
int res;
res = hal_timer_init(5, NULL);
ASSERT(res == 0);
res = os_cputime_init(32768);
ASSERT(res == 0);
ble_ll_init();
ble_hci_ram_init();
nimble_port_freertos_init(BleHost);
}
And BleHost():
void BleHost(void *) {
struct ble_npl_event *ev;
while (1) {
ev = ble_npl_eventq_get(&g_eventq_dflt, BLE_NPL_TIME_FOREVER);
ble_npl_event_run(ev);
}
}
If you want to have a look at the complete code, it's hosted on
Github.
main() is in src/main.cpp, the nimble is in src/libs/mynewt-nimble :
https://github.com/JF002/Pinetime
Is there anything specific I should check?
Thanks,
JF
Le 17/06/2020 10:35, Andrzej Kaczmarek a écrit :
> Hi,
>
> How did you setup interrupts on FreeRTOS (e.g. radio) and critical
> section?
> These kinds of problems are common if you have misconfigured locking,
> interrupt priorities or smth. Since we do not have any official port
> for
> FreeRTOS (there's only NPL but it does not deal with hardware) I assume
> you
> did this on your own so would be good to know more details.
>
> Best,
> Andrzej
>
>
> On Tue, Jun 16, 2020 at 8:29 PM <j...@codingfield.com> wrote:
>
>> Hi,
>>
>> I was able to do more tests using BLE_MONITOR_RTT and btmon.
>> Here are 3 captures from 2 phones (nexus 5 and huawei). The one from
>> the
>> Nexus contains 3 successful connections followed by a failed one. Both
>> from nexus only contain 1 failed attempt. For each test, you'll find
>> the
>> output of btmon and the capture from wireshark.
>> The files are available here :
>> https://seafile.codingfield.com/d/3e17cb3f43da4eedaefd/
>>
>> Note that I observed that the connection is more often successful when
>> BLE_MONITOR_RTT is enabled than when it is disabled. Remember it was
>> the
>> same with Debug/Release : there are more successful connections in
>> Debug
>> than in Release.
>> It makes me think of a timing issue, but it's weird that it works
>> better
>> when the code is supposed to run slower...
>>
>> I hope you'll be able to make sense of these captures!
>>
>> Thanks for your help!
>>
>> JF
>>
>>
>> Le 15/06/2020 22:54, j...@codingfield.com a écrit :
>> > Hi,
>> >
>> > Sorry, I do not mean to spam this mailing list. I just wanted to say I
>> > misread the article, and manage to use the monitor over RTT. I build
>> > the tool rtt2pty, ran it and then launched "btmon -J nrf52" and I see
>> > very detailed logs about BLE communication!
>> >
>> > It's running late, I'll analyze them tomorrow evening.
>> >
>> > Thanks for your help, and sorry for the spam :)
>> >
>> > JF
>> >
>> > Le 15/06/2020 22:25, j...@codingfield.com a écrit :
>> >> Hi again,
>> >>
>> >> Ok, I had a look to BLE_MONITOR_RTT, but I can't figure out how to
>> >> enable it in my code (which does not use mynewt as RTOS) : at first,
>> >> the code did not compile. I tried to fix the compilation errors (for
>> >> example, I had to define struct File_methods and struct File).
>> >> Then, I built the code, but couldn't see any messages coming out of
>> >> JLinkRTTClient.
>> >>
>> >> It is supposed to work with JLinkRTTClient, or do I need to use
>> >> btshell running on another nrf board? (I do not have a nrf52840 on
>> >> hands...).
>> >>
>> >> By the way, I already use the RTT for logging, and manage to enable
>> >> some loggers some nimble. Are the same messages available using the
>> >> logger, or do I really need bt_monitor?
>> >>
>> >> Thx!
>> >>
>> >> JF
>> >>
>> >> Le 15/06/2020 20:38, j...@codingfield.com a écrit :
>> >>> Hi,
>> >>>
>> >>> The ACK you're talking about, are they the "Rcvd Read" listed in the
>> >>> capture?
>> >>>
>> >>> If BLE_MONITOR_RTT means that nimble supports JLink RTT, then yes, I
>> >>> have a console available. I'll try to enable it. I'll also have a
>> >>> look
>> >>> at the stats and how to use them.
>> >>>
>> >>> Thanks for the pointers, I'll report to you as soon as I have more
>> >>> information!
>> >>>
>> >>> JF
>> >>>
>> >>> Le 14/06/2020 23:18, Łukasz Rymanowski a écrit :
>> >>>> Hi,
>> >>>>
>> >>>> so indeed your logs show that after trying to read include services
>> >>>> from
>> >>>> GATT service, something bad happened. Controller was able to ACK 2
>> >>>> following master packets then it stopped to send ACKs.
>> >>>> Do you have a console available? If so, does it show anything
>> >>>> interesting?
>> >>>>
>> >>>> For further debugging I suggest to look at BLE_MONITOR_RTT to grab
>> >>>> hci logs
>> >>>> (https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/)
>> >>>> With this we will know if response is still in the host or is in
the
>> >>>> controller.
>> >>>>
>> >>>> Then we could check some stats e.g. ble_ll_stats - maybe that could
>> >>>> show us
>> >>>> something interesting - but first let us see where it stuck.
>> >>>>
>> >>>> Best
>> >>>> Łukasz
>> >>>>
>> >>>> On Sun, 14 Jun 2020 at 21:06, <j...@codingfield.com> wrote:
>> >>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> It looks like the attachements were dropped somewhere... You can
>> >>>>> download them on my seafile instance :
>> >>>>> https://seafile.codingfield.com/d/64d53a6ca6b44ae6b5d7/
>> >>>>>
>> >>>>> It seems to fail during the discovery of the characteristics on
the
>> >>>>> device. From what I understand, it happens during the discovery of
>> >>>>> Generic Access Profile and Generic Attributes Profile, which are
>> >>>>> handled
>> >>>>> by nimble.
>> >>>>> I may be wrong, I'm a beginner with BLE and nimble!
>> >>>>> Maybe the captures will make more sens to you?
>> >>>>>
>> >>>>> Yeah, it's very strange that it works when the code is supposed to
>> >>>>> run
>> >>>>> slower... It makes me think of a timing or memory issue, but I
>> >>>>> couldn't
>> >>>>> find it...
>> >>>>>
>> >>>>> Thanks,
>> >>>>> JF
>> >>>>>
>> >>>>> Le 14/06/2020 20:46, Łukasz Rymanowski a écrit :
>> >>>>> > Hi,
>> >>>>> >
>> >>>>> > Thanks for the report, however looks like attachments are
missing.
>> >>>>> >
>> >>>>> > First of all you need to understand what read fails i.e check
>> handle
>> >>>>> > and
>> >>>>> > make sure that your application responds correctly.
>> >>>>> > It is very suspicious that read works with -Og, but still I
would
>> focus
>> >>>>> > on
>> >>>>> > that failing read first.
>> >>>>> >
>> >>>>> > Thanks
>> >>>>> > Lukasz
>> >>>>> >
>> >>>>> >
>> >>>>> > On Sun, Jun 14, 2020, 20:25 <j...@codingfield.com> wrote:
>> >>>>> >
>> >>>>> >> Hello,
>> >>>>> >>
>> >>>>> >> I'm working on a firmware for the Pinetime, a smartwatch based
on
>> the
>> >>>>> >> NRF52832. The code is written in C/C++ and uses FreeRTOS.
>> >>>>> >> I've recently switched from the Nordic Softdevice to NimBLE as
BLE
>> >>>>> >> stack. I used the freertos port from the 'porting' folder of
the
>> >>>>> >> source
>> >>>>> >> code of nimble.
>> >>>>> >>
>> >>>>> >> I did many test using my PC on Linux : it can connect and
>> communicate
>> >>>>> >> with the NRF52 without issue.
>> >>>>> >> However, things are not that easy when I try to connect using
>> Android
>> >>>>> >> phone (I tried with a Huawei Psomething and my old Nexus5) :
the
>> >>>>> >> connection fails most of the time.
>> >>>>> >>
>> >>>>> >> I did a lot of debugging, logging, sniffing,.. and I still
cannot
>> >>>>> >> understand why it's not working as expected. Here are some of
my
>> >>>>> >> observations:
>> >>>>> >>
>> >>>>> >> - When Android successfully connects, I receive the following
>> GAP
>> >>>>> >> events : BLE_GAP_EVENT_CONNECT and then
BLE_GAP_EVENT_CONN_UPDATE
>> 2
>> >>>>> >> times. The first update sets the connection interval to 6, the
>> second
>> >>>>> >> one to 40.
>> >>>>> >> - When it fails, I receive only the BLE_GAP_EVENT_CONNECT
event
>> and
>> >>>>> >> the
>> >>>>> >> 1st BLE_GAP_EVENT_CONN_UPDATE.
>> >>>>> >> - Using the sniffer, I noticed that the last packet is a read
>> >>>>> >> request
>> >>>>> >> from the phone. It looks like the NRF52 never respond to this
last
>> >>>>> >> read.
>> >>>>> >> - It fails in the discovery steps (when the android phone
>> discover
>> >>>>> >> all
>> >>>>> >> the services, characteristics and attributes) but not always at
>> the
>> >>>>> >> same
>> >>>>> >> place.
>> >>>>> >> - I noticed that the tasks (ll task and host task are not in
>> >>>>> >> deadlock
>> >>>>> >> BUT it looks like the radio ISR (ble_phy_isr() in ble_phy.c) is
>> not
>> >>>>> >> called anymore.
>> >>>>> >> - When I build the very same code in DEBUG (-Og instead of
>> -O3), it
>> >>>>> >> works perfectly!
>> >>>>> >>
>> >>>>> >> You'll find in attachements 2 captures I did with Wireshark and
>> the
>> >>>>> >> NRF
>> >>>>> >> Sniffer (running on a NRF52-DK), one failed and one successful
>> attempt
>> >>>>> >> to connect.
>> >>>>> >>
>> >>>>> >> I'm running out of idea to debug this further. Is there a
>> >>>>> >> configuration
>> >>>>> >> issue (there are so many parameters in syscfg.h)? What could I
>> try?
>> >>>>> >> Where should I search ? Do you need more info to understand
the
>> >>>>> >> issue?
>> >>>>> >>
>> >>>>> >> Could you help me fix this issue?
>> >>>>> >>
>> >>>>> >> Thanks,
>> >>>>> >>
>> >>>>> >> JF
>> >>>>>
>>
