BGLib Arduino library for Bluegiga BLE112 Bluetooth Low Energy module

Just heard back from BlueGiga support:

"Hello,

BGAPI is not supported over SPI at the moment, you can use this over UART and USB at this time. SPI can support things like sensors and displays for now.

Best regards,

Sam Pullen"

It would help if the BlueGiga docs were consistent - Various diagrams etc show BGAPI being connected to a microcontroller via SPI.

I haven't tried that method (BGAPI over SPI) personally yet, though from a hardware standpoint, the CC2540 should technically be able to do it. Maybe the BLE112's custom stack just doesn't support it. Where in the docs have you seen the diagram that suggests otherwise?

Hi Jeff,

I was wondering what kind of "hardware flow control issues" you are having with the BLE112? I am working with this device on the MSP430 and I am also seeing some hardware flow control problems. Specifically the BLE does not ever assert the CTS line to throttle the MSP430 and the buffer overflows almost immediately. I am transmitting at 115200 baud. Also I have seen DMA recommended for the CC2540 at these baud rates, but there does not appear to be any way to explicitly enable this using the Bluegiga API (unless it occurs automatically in the Bluegiga SW for this setting).

With regard to SPI connectivity, I also tried to implement this based on the documentation from Bluegiga, but got very odd responses on the scope. I eventually contacted Bluegiga and received the same response as TheBarrelShifter, above i.e. it is not implemented yet. The diagrams in the API_53 guide (pg 8), BLE_Stack_API_reference_v1.3 (also pg 8.), BLE_getting_started_v1.3 (pg 15), etc all show an SPI interface between the host and the BGAPI protocol.

Keano16:
I was wondering what kind of "hardware flow control issues" you are having with the BLE112? I am working with this device on the MSP430 and I am also seeing some hardware flow control problems. Specifically the BLE does not ever assert the CTS line to throttle the MSP430 and the buffer overflows almost immediately. I am transmitting at 115200 baud. Also I have seen DMA recommended for the CC2540 at these baud rates, but there does not appear to be any way to explicitly enable this using the Bluegiga API (unless it occurs automatically in the Bluegiga SW for this setting).

This "packet mode" setting must be enabled by adding ' mode="packet" ' to the tag in hardware.xml. In my test setup with an Arduino, I've actually not had that particular problem. My errors seem to be more like UART timing errors than flow control errors; the very first byte is a spurious 0xFE or 0xFF, and/or the last byte is the same. I am using SoftwareSerial though, and I suspect that is the problem. I have not yet tried sending large amounts of data to the module from the Arduino yet though. My demo sketch receives a lot of data, but that's it. I do also have the CTS pin on the BLE tied to ground, but this is not likely to affect your issue.

SPI as implemented on the module doesn't have any flow control or DMA buffering; using SPI for generic bidirectional data transfer is not easy even without using BGAPI. I guess they may add support for it later.

Hi Jeff,

Thanks for the reply and the additional details. I obtained a software update for the stack from Blugiga and now the hardware flow control works as expected. I am transmitting 20 byte packets every ~20ms and as far as I can tell initially, this is reliable.

Hi Jeff,

I'm experiencing some odd behaviour, specifically when the binary size of my application gets about about 17,000 bytes - Under this size BGLib and BGAPI over serial using SoftwareSerial work very reliably, but above this kind of size strange things begin to happen such as the BLE112 not responding to commands, or either the BLE112 or Arduino spontaneously resetting.

In trying to get the bottom of this problem I've rebuilt my application from the base up, and repeated my observation that the odd behaviour begins at around the 17,000 byte binary size.

I wonder whether you've exercised BGLib more than running your test application? Or whether you've used it within the context of a larger application?

To give you some idea of the functions and callbacks I'm making use of, these are:

ble112.ble_rsp_system_hello
ble112.ble_rsp_gap_set_scan_parameters
ble112.ble_rsp_gap_discover
ble112.ble_rsp_gap_end_procedure
ble112.ble_rsp_sm_set_bondable_mode
ble112.ble_rsp_gap_set_mode
ble112.ble_rsp_attributes_write
ble112.ble_rsp_sm_set_parameters
ble112.ble_rsp_sm_encrypt_start
ble112.ble_rsp_sm_passkey_entry
ble112.ble_rsp_sm_get_bonds
ble112.ble_evt_system_boot
ble112.ble_evt_gap_scan_response
ble112.ble_evt_attributes_value
ble112.ble_evt_connection_status
ble112.ble_evt_sm_passkey_request
ble112.ble_evt_sm_passkey_display
ble112.ble_evt_sm_bonding_fail
ble112.ble_evt_sm_bond_status
ble112.ble_evt_connection_version_ind
ble112.ble_evt_connection_disconnected
ble_cmd_system_reset

Hi Jeff,

I'm experiencing some odd behaviour, specifically when the binary size of my application gets about about 17,000 bytes - Under this size BGLib and BGAPI over serial using SoftwareSerial work very reliably, but above this kind of size strange things begin to happen such as the BLE112 not responding to commands, or either the BLE112 or Arduino spontaneously resetting.

In trying to get the bottom of this problem I've rebuilt my application from the base up, and repeated my observation that the odd behaviour begins at around the 17,000 byte binary size.

I wonder whether you've exercised BGLib more than running your test application? Or whether you've used it within the context of a larger application?

To give you some idea of the functions and callbacks I'm making use of, these are:

ble112.ble_rsp_system_hello
ble112.ble_rsp_gap_set_scan_parameters
ble112.ble_rsp_gap_discover
ble112.ble_rsp_gap_end_procedure
ble112.ble_rsp_sm_set_bondable_mode
ble112.ble_rsp_gap_set_mode
ble112.ble_rsp_attributes_write
ble112.ble_rsp_sm_set_parameters
ble112.ble_rsp_sm_encrypt_start
ble112.ble_rsp_sm_passkey_entry
ble112.ble_rsp_sm_get_bonds
ble112.ble_evt_system_boot
ble112.ble_evt_gap_scan_response
ble112.ble_evt_attributes_value
ble112.ble_evt_connection_status
ble112.ble_evt_sm_passkey_request
ble112.ble_evt_sm_passkey_display
ble112.ble_evt_sm_bonding_fail
ble112.ble_evt_sm_bond_status
ble112.ble_evt_connection_version_ind
ble112.ble_evt_connection_disconnected
ble_cmd_system_reset
ble_cmd_system_hello
ble_cmd_sm_set_parameters
ble_cmd_gap_set_mode
ble_cmd_sm_set_bondable_mode
ble_cmd_sm_encrypt_start
ble_cmd_sm_passkey_entry
ble_cmd_connection_disconnect
ble_cmd_sm_set_bondable_mode
ble_cmd_attributes_write

Thanks in advance for any ideas you may have about this odd behaviour,

Toby

I've boiled the problem down to a simple addition of a large array to your original test program (attached).

With a single byte array, the program runs as expected, increase the array size to 2048 or similar and the program no longer runs correctly.

Any ideas?

Toby

BGLib_scanner.ino.zip (3.04 KB)

TheBarrelShifter:
With a single byte array, the program runs as expected, increase the array size to 2048 or similar and the program no longer runs correctly.

The behavior you describe is consistent with an AVR chip running out of memory--it does all sorts of weird things. The ATMEGA328P datasheet says that the chip only has 2KBytes of internal SRAM, and if you declare a variable like that--especially since I think "int" is a 16-bit integer and therefore a 1024-position array is 2048 bytes--you're basically eating up the entire memory pool right from the start. Is there a reason you need a whole lot of data to be loaded into RAM? If it's constant, I would use PROGMEM or something to keep the data in the program flash space, to keep the SRAM available for other things.

Either that, or you're stuck with using an MCU with more RAM. For example, the ATmega1280/2560 has 8KBytes of internal SRAM, so it should work fine assuming the same project code.

Hi. What kind of firmware have I to load in BLE112 in order to use your BGLib porting?

Thank you very much

giamby3000:
Hi. What kind of firmware have I to load in BLE112 in order to use your BGLib porting?

You can use the example projects here, just updated:

One has a non-sleeping UART1/Alt1 API connection (USB enabled), and the other (wakeup16) disables USB and enables sleep modes, with the P1_6 pin used for an active-high wake-up pin. In this arrangement, the wake-up pin needs be driven high before sending API commands over UART so that the module will receive them. It can be dropped low again as soon as you are finished sending the command; the module will wake itself up as needed to send its own data back to the connected host.

Hi Jeff,

Do you have a link to the bluegiga reference manual?

Thanks!

khankuan:
Do you have a link to the bluegiga reference manual?

The latest API Reference Guide can be found on the BLE112 product page of Bluegiga's Tech Forum:

https://techforum.bluegiga.com/ble112?downloads

You'll need to create a free account if you don't already have one, but that's simple enough.

So I am trying to use the PJRC Teensy 3 with the BGLib Arduino library but unfortunately not having any luck... (Commands like system_hello to BLE112 timeout, though I do receive notification when the BLE112 boots...)

I have tried the BGLib_U1A1P_38400_noflow and BGLib_U1A1P_38400_noflow_wake16 firmwares (programmed using the TI CC Debugger) w/ both sample Arduino programs (Scanner & Stub Slave) The only change I made to the sketchs was altering the SoftwareSerial pins to 0,1 from 2,3. The reason for this is the Teensy 3 pinout has the first Serial port on these pins (See: Teensy and Teensy++ Pinouts, for C language and Arduino Software)

As for the hardware connections I have:
Teensy 1 (RX) <==> BLE P04 (TX)
Teensy 2 (TX) <==> BLE P05 (RX)
Teensy 5 <==> BLE P16 (Wakeup)
Teensy 6 <==> BLE !RESET

Any troubleshooting suggestions? Is the Teensy 3 in someway incompatible w/ BGLib as written? (I see it was originally intended for the Uno)

I solved my own problem, here is the answer for posterity:

I had never used the physical reset button on the BLE-112 breakout board. After pressing that the scanner sketch worked immediately! (I assumed using the BLE-Update tool to reflash firmware would be the same as the reset button but in this specific case it seemed I needed to use the reset button for whatever reason)

Unfortunately I then had problems w/ the stub_slave sketch. For this, my problem turned out to be these lines of code at the very end of setup:

digitalWrite(BLE_RESET_PIN, LOW);
delay(5); // wait 5ms
digitalWrite(BLE_RESET_PIN, HIGH);

I'm not 100% clear on why the reset caused a problem, but it appeared that an extra 0x00 byte was added to the front of the packet. Hence, it went from:

80 0C 00 00 01 00 01 00 01 00 47 00 03 00 01 01
to
00 80 0C 00 00 01 00 01 00 01 00 47 00 03 00 01 01

As we can see from the BG-API binary packet description:

BGAPI packet structure (as of 2012-11-07):
Byte 0:
[7] - 1 bit, Message Type (MT) 0 = Command/Response, 1 = Event
[6:3] - 4 bits, Technology Type (TT) 0000 = Bluetooth 4.0 single mode, 0001 = Wi-Fi
[2:0] - 3 bits, Length High (LH) Payload length (high bits)
Byte 1: 8 bits, Length Low (LL) Payload length (low bits)
Byte 2: 8 bits, Class ID (CID) Command class ID
Byte 3: 8 bits, Command ID (CMD) Command ID
Bytes 4-n: 0 - 2048 Bytes, Payload (PL) Up to 2048 bytes of payload

This completely threw off the meaning of the packet and future packets as well. (Interpreted as a command/response rather than event w/ a packet length of 128 rather than 12!!!

Dear Jeff,

I'm using your firmware for the BLE112 and your arduino APIs (BGLib_U1A1P_38400_noflow and BGLib_stub_slave). I successfully connected to my iPad and received data from the BLE112 by issuing a ble_cmd_attributes_write. However, I can't seem to get it to write 20bytes of data. The most I could write and send to my iPad in a packet is 19bytes. Is this a limitation?

Thanks!

Hello jeff,
if i load your code in arduino than i also programme BLE112 ?
and this code is also running in BLE113?
Thank you

Do you know if this can be used to flash the arduino? If so, do you have a schematic or know where i can find one? thanks!

^^ bump