Thanks a lot for the GCC sample. I work as well with the Bluetooth Developer Studio, where can I find documentation of the native_gecko.h? E.g. to customize the content of the advertising packet?
If you want to modify the example (especially the BLE part), then the best document to start with is probably the BGAPI reference manual. It can be found under BLE SDK installation directory, see:
To customize advertising packet content, see following functions:
In a nutshell: use the first function to set the advertising data (following the format specified in BT spec) and then start advertising with cmd_le_gap_set_mode(4,2)
The first argument 4 (le_gap_user_data) tells the stack to use your own data instead of automatically generating the content based on what is in the GATT.
Thanks for the fast reply. I would like to have:
1. device name (3 bytes)
2. services (3 16bit-UUIDs == 6 bytes)
in the ADV packet. Actually I have generated with the BGTool the files gatt_db.c/h. These files are already included in the main.c, but the ADV packet still only contains the device name. I am not sure if I got the workflow with the BGTool and the gatt_db right... Thank you very much for the help.
Thank you very much Jaakko, Tiago.
Got the example to work on my mac without issues, also adding a service and characteristic.
Side note, my Mac is from 2015 can comes with pre-installed GNU Make 3.81 (from 2006 !) and still worked fine, at least for this example. Which make version do you use for your tests ? Latest ?
Question: until we have this all moved and integrated w/ Simplicity Studio, any suggestion how to do debugging if I want to keep working with this setup? Made a first attemp integrating SWO Terminal with no success, any idea here?
Do you have an estimation when the GCC support is "production-ready"? Thanks!
Did anyone get characteristic notifications to work? I tried with the default "Health Thermometer" service, but no success. Thanks for help!
Ah, I found my mistake after stepping through the bootloader one instruction at a time and then reading its source.
Looks like the problem was that my merged linker script (merged between my project's linker script and the one included with the GCC example) had failed to include the .AAT section, which meant that the bootloader couldn't find the application address table, which it needs to boot the app. Once I included that (and made sure that my main.c also had a #include "aat.h"), everything worked fine and I'm able to at least send simple iBeacons. Moving forward!
So with the extremely large chunks of opaque, arbitrary memory taken up by the BT stack/heap above and beyond the heap that is already passed in through gecko_init(), there's a lot less memory available. For example, with the old stack, I was able to allocate 12K to my FreeRTOS heap without trouble; now I can barely get 4K.
Here's what seems to be taken up by the new stack as far as RAM goes:
- 0x3400 bytes (13K) taken up in the linker script by the RAM region definition (the custom linker script declares the range as starting at 0x20003000 and being 0x4C00 - 4 bytes long)
- 0xb00 bytes (2.75K) taken up by the .heap section (how is this different from the heap passed in at init time and the region already reserved in the linker, and why isn't it passed in at init time?)
- 0x1400 bytes taken up by the .stack section (how is this different from the 0x400 of top memory already reserved at link time?)
I've experimented with different variations of allocating and not allocating these things, and sometimes they crash, but it's not easy to tell whether I'm doing something Very Bad or not, because there's no visibility into how this memory is getting used. This all seems like rather a lot of RAM, especially considering that it only leaves about 4K of a 32K part free, and the previous stack left at least 8K more.
Is there any way I can reliably shrink the RAM consumption of the stack? 4K isn't a lot for our application.
By the way, the new stack still claims the PendSV interrupt, which is not documented behavior. I've made it coexist with FreeRTOS by writing a shim routine to determine who "owns" PendSV and execute the correct handler (the performance hit is fairly minor). If anyone is interested, I'll be glad to share (we plan to contribute it back to FreeRTOS when it's a little more settled).
Further: are there plans for a non-autonomous version of the stack (i.e. one that is more amenable to being run within an RTOS that exposes the polling routine instead of executing it itself)? That would be very helpful for larger projects where things like threading are required.
I got the following error Using Mingw . Please let me know.
../../../../../protocol/bluetooth_2.0/bin/bgbuild -gn -c ../../../../../../../..
Directory ../../../../../../../../toolchains/gnu_arm/4.9_2015q3/bin/ does not ex
ist. Trying to use compilers from system PATH.
../../../../../../../../toolchains/gnu_arm/4.9_2015q3/bin/arm-none-eabi-gcc -c -
mcpu=cortex-m4 -march=armv7e-m -mthumb -fno-short-enums -D__NO_SYSTEM_INIT -DEFR
32BG1B232F256GM48 -Os -I../../../../../protocol/bluetooth_2.0/ble_stack/inc/ -I
tocol/bluetooth_2.0/ble_stack/inc/soc/ -I../../../../../platform/emlib/inc/ -I..
R32BG1B/Include/ -I../../../../../platform/CMSIS/Include/ -I../bgbuild/ ../src/m
ain.c -o main.o
process_begin: CreateProcess(NULL, ../../../../../../../../toolchains/gnu_arm/4.
9_2015q3/bin/arm-none-eabi-gcc -c -mcpu=cortex-m4 -march=armv7e-m -mthumb -fno-s
hort-enums -D__NO_SYSTEM_INIT -DEFR32BG1B232F256GM48 -Os -I../../../../../protoc
k/inc/common/ -I../../../../../protocol/bluetooth_2.0/ble_stack/inc/soc/ -I../..
/../../../platform/emlib/inc/ -I../../../../../platform/emlib/src/ -I../../../..
IS/Include/ -I../bgbuild/ ../src/main.c -o main.o, ...) failed.
make (e=2): The system cannot find the file specified.
Makefile:33: recipe for target 'main.o' failed
mingw32-make: *** [main.o] Error 2