Can't see my device advertising - what am I doing wrong here?

[Richard von Lehe]

I've been looking at this for the better part of a day and can't seem to pinpoint what I'm doing wrong here. Does anybody want to take a quick peek at this project and tell me what's missing? I'm including two attachments. The first is all the code (basically just look at barebones.c and p5_svc.c. These are the equivalent of main.c for most of the ble_app_xxx examples. The other is the eclipse project and the Makefiles. Any help is greatly appreciated.

The initialization routines for ble get called. The leds are toggling in the mainloop. I don't have any power management or thread-level waiting for sd events in the mainloop, but that isn't required to show up in the master control panel when it's advertising.

Rich

p5_bare.zip

p5_bare_other.zip

[Ole Morten]

Having an empty app_error_handler is pretty optimistic... You should make sure to always catch errors, and try to handle them. For development, an infinite loop is useful, to make sure you see that something happens, while for a release, it may make sense just to do a reset.

Anyway, when running your project with a debugger and putting a breakpoint in app_error_handler, you can see that it's ble_conn_params_init() on line 239 of barebones.c that fails with an error code 8. As given in nrf_error.h, this means NRF_ERROR_INVALID_STATE, and when actually stepping into the init function, you can see that it's app_timer_create() that throws this. When inspecting further, you don't seem to initialize app_timer anywhere, which explains why you get this.

Bottom line: if you want to use ble_conn_params unedited, you have to include app_timer in your build an initialize it before initializing conn_params. Also, make sure to put a loop in the error handler to catch errors while developing. Never run with an empty app_error_handler!

PS: You make it pretty hard to help you, by using a weird build setup (no main Makefile), not including all files needed to build in your zip, and not actually building with debug symbols, even when doing make debug. (I had to copy in all the SDK includes, since you don't set the SDK path, manually remove glcd.a from the build, which apparently wasn't used anyway, redefine LED0 and LED1, since the board header was not included in the zip, and add -g to the link to also link with debug symbols, not just compile each module). For next time, it would be most appreciated if I could just unzip a single zip, open a shell and do make debug and then load the resulting elf in the debugger immediately! :)

[Richard von Lehe]

Thanks once again Ole. I apologize for the lack of understandability and "makeability" of the zipped project. I definitely would have been easier if I had zipped everything in the folder. I tried not to include everything in the folder because there's lots of other files that we consider proprietary and this is a public forum. As an aside, the Makefile structure that is used is one that I inherited and I also somewhat dislike. Basically there are a half dozen projects all sharing Makefile.common.mak and using a separate Makefile.<platform>.mak to specify the sources and specifying a configuration word in flash (the srec_cat recipe). And yes, there were some environment variables that the Makefile expects (SDK path is one). But in any case, I should have gone through the effort to separate the pieces that I was having difficulty with from the rest of the project's shortcomings (i.e. create the minimal project that still had the same problem). Hopefully the pain I'm causing you will be short-lived and I can begin to make most of these discoveries myself.

[Ole Morten]

No problem, I managed to get it working and it wasn't that bad. I just thought I'd let you know, since usually, the easier things are to test, the quicker you'll get an answer. As application engineers, we tend to pick the lowest-hanging fruit first... ;)

Also, if this answer solved your question, I'd be happy if you could accept it!