Help using STM32duinoBLE with sensortile box - default example LED controller/peripheral does not work

[gemelko]

Help, I'm completely stuck! I can't seem to get the STM32duinoBLE library to be useful on the sensortile box: it works but seems to only set up a basic BLE device with generic interface that can't be used to move data from or to the device, and adding services seems to be non-functional.

So to make things extremely simple, I reduced my testing to two sensortile.box devices and compiled the examples from the STM32duinoBLE library "LED" and "LedControl" - control on one device, peripheral on the other device, and monitored the serial ports on both devices. They both initialize the BLE and report that they are functioning, but they never connect to each other. Here are the results:

With the default firmware loaded onto the SPBTLE-1S module: While the BLE device does start on both, they never make a connection: the BLE.available() call always returns false, thus the scanner on the control side doesn't find the peripheral device. This is true whether I use the code as-is which calls BLE.scanForUuid("19B10000-E8F2-537E-4F6C-D104768A1214") or if I change the code to use BLE.scanForName("LED") - in both instances, BLE.available() within the loop never returns true, and the control device never attempts to connect to the peripheral.

With the DTM_LLOnly.bin firmware loaded onto the SPBTLE-1S module: The BLE.begin() call always fails, and thus nothing else works.

Some additional information: When I use the default firmware on the SPBTLE-1S module and run the LED example above, I only see two generic services:
00001801-0000-1000-8000-00805f9b34fb (Handle: 1): Generic Attribute Profile
00001800-0000-1000-8000-00805f9b34fb (Handle: 5): Generic Access Profile
...and even using an Android device to connect to them, I can't seem to attach to the services Uuid's for the LED using a BT tool such as LightBlue, ST BLE ToolBox-1.3.5, or BLE Tester. The LED service should be 19B10000-E8F2-537E-4F6C-D104768A1214 however I can't connect to its characteristic 19B10001-E8F2-537E-4F6C-D104768A1214 even though I can see this service with LightBlue (for example) as an "Advertised service UUID."

But back to basics, I would hope that the out-of-the-library examples for Control and Peripheral would work, but they do not.

I read a note about using DTM_LLOnly.bin however as I said, flashing that into the boards completely breaks things as far as I can tell.

Upon further investigation, I loaded the Keil ARM compiler and the BlueNRG-1_2_DK_3.2.3 from ST and found that the default pinout for the SPBTLE-1S module in the DTM project has the SPBTLE-1S Chip Select (CS) on GPIO11 and IRQ on GPIO7 however the sensortile box definitions have CS on GPIO1 and IRQ on GPIO14, so I changed those and re-built the module firmware DTM_SPI.bin and flashed that using the ST-LinkV2 into the SPTBLE-1S module (10-pin header soldered to the board). With that, the BLE.begin() function call executes successfully, however the device does not appear to initialize properly: I can see a MAC address for the device, but it doesn't get a name or any services and it is not connectable using LightBlue or ST BLE ToolBox... but I think I'm on the right track with this.

Help, anyone?!?! Am I going down the wrong path trying to flash the SPTBLE-1S module and thus should I put it back to default? I'm struggling here, and I've been pounding my head against this for several weeks now. Is it something obvious that I just missed, or is this really a problem with the sensortilebox using STM32duinoBLE?

Thank you in advance, anyone, for any assistance you can give me!!
Glenn

[cparata]

Hello @gemelko ,
could you please check if the BLE module of your board looks like this one:

or this one:

The main difference is a metallic bump on the top right of the BLE module.
Best Regards,
Carlo

[gemelko]

Yes that's it exactly: the first picture with the only-rectangular shield (no dog-leg). I also figured out that the SPI mode was mismatched: mode0 in the firmware, mode1 in the Arduino project, but that doesn't fix it either.

Here is the initialization that's being called from the default example:

SPIClass SpiHCI(PC3, PD3, PD1);
HCISpiTransportClass HCISpiTransport(SpiHCI, SPBTLE_1S, PD0, PD4, PA8, 1000000, SPI_MODE1);

BLELocalDevice BLEObj(&HCISpiTransport);
BLELocalDevice& BLE = BLEObj;

In the schematic, I can see the following:
PC3 is connected to module GPIO3 (pin 17)
PD3 is connected to module GPIO2 (pin 16)
PA5 is connected to module GPIO0 (pin 15)
PD0 is connected to module GPIO1 (pin 18)
PD4 is connected to module ANATEST0/GPIO14 (pin 6)
PA8 is connected to module /RESET (pin 19)

[gemelko]

Also included the following compile-time definitions (set up in Keil) for the SPI target:

-D__UVISION_VERSION="538"
-DSPI_INTERFACE
-DWATCHDOG -DWATCHDOG_TIME="1"
-DBLE_STACK_CONFIGURATION="BLE_STACK_FULL_CONFIGURATION"
-DBLUENRG1_DEVICE
-DHS_SPEED_XTAL="HS_SPEED_XTAL_32MHZ"
-DLS_SOURCE="LS_SOURCE_EXTERNAL_32KHZ"
-DSMPS_INDUCTOR="SMPS_INDUCTOR_10uH"

Although I think the above are correct, I've tried some other configurations, without success, such as BLE_STACK_BASIC_CONFIGURATION and HS_SPEED_XTAL_16MHZ and LS_SOURCE_INTERNAL_RO

Still no luck.

[cparata]

Hello @gemelko ,
I did again all the procedure with the SensorTile.Box that I have in my hands and it worked on my side. Flashing the DTM_LLOnly firmware on the BLE module and then flashing the LED example from STM32duinoBLE v1.2.4 on the main MCU, I'm able to control the board with my smartphone. You should also have the same hardware release of mine, so it is really strange the behavior that you see. I just used the RF-Flasher Utility instead of the STSW-BNRGFLASHER because the latter is not available anymore on st.com. I asked about the shape of the BLE module of your boards because I know that the new samples of the SensorTile.Box are released with BlueNRG-M2 chip instead of SPBTLE-1S chip and the firmwares that you can find in the guide are for the SPBTLE-1S version of the board. But it seems that you have the same version of my board, so I don't know why it does not work on your side.
Best Regards,
Carlo

[cparata]

Hello @gemelko ,
take into account that to use the SensorTile.Box with STM32duinoBLE you must flash the DTM_LLOnly firmware that enables only the Link Layer mode in the BLE chip. In fact with STM32duinoBLE we want to use the BLE stack (GATT, GAP services) provided by this library and so we need a dedicated firmware for the BLE module. The DTM_Full firmware is the one used in the Cube environment where the BLE stack is managed directly by the BLE chip.
I hope that it clarify the reason why we have the two firmwares.
Best Regards,
Carlo

[gemelko]

To verify:

I have downloaded en.fp-ind-predmnt1 from st.com, and I am using the file C:\ST\en.fp-ind-predmnt1\STM32CubeFunctionPack_PREDMNT1_V2.4.1\Utilities\BlueNRG-1_2_Flasher\DTM_LLOnly.bin which has the md5 checksum of 1A96D88E8EB475121B465E2E9C3D8ED4 (using HxD for the checksum) or a CRC-32 of 3C920DAD (ZIP archive properties).

I am using the BlueNRG-1_2 Flasher - Utility v3.1.0.

I am plugged into the 10 pin header on the same side as the MicroSD card. I had to solder on the header.

I am using the STLink V2-1 programming module.

I start the flasher tool. I choose SWD mode. I select the above image, with Flash from Address set to 0x10040000, then "Tools/Mass Erase" which successfully erases the flash, then "Flash" which successfully flashes the new image. Messages:
MASS ERASE OPERATION
06:45:35.595: Waiting device to Mass Erase -> Connected
06:45:35.834: Device Identification -> BlueNRG-1
06:45:35.959: Mass Erase Operation -> SUCCESS

FLASH OPERATION
06:45:38.391: Waiting device to flash -> Device connected
06:45:38.520: Device Identification -> BlueNRG-1
06:45:38.648: Device Flash Programming -> SUCCESS
06:45:40.035: Flash Programmed in 1.387000 sec.
06:45:40.035: Flash Verify Operation -> SUCCESS

06:45:40.957: Flash operation finished!

Load the LED example from the STM32duinoBLE project (File/Examples/STM32duinoBLE/Peripheral/LED) and compile it and upload it to the board through the usb connection: board is in DFU mode. , and watch the output in serial monitor.
Message: starting BLE failed!

Did I miss anything?

Glenn

[gemelko]

Picture of the module on one of the boards I have. I peeled up the stickers and put them on the micro so that I could see if there are any markings on the shield - none that I see.

[cparata]

Hello @gemelko ,
the correct DTM_LLOnly firmware to be used should be this one. Have you already tried it? This one was created by me according the schematics of SensorTile.Box. I'm not sure that the one in the STM32CubeFunctionPack_PREDMNT1_V2.4.1 works for STM32duinoBLE.
Best Regards,
Carlo

[gemelko]

That worked! Argh. So much effort to get to here. Thank you thank you, Carlo! Grazie mille!!!! You made my day.

[cparata]

Great!

[cparata]

Anyway, here you can find the guide that I wrote to update the firmware of the BLE module of SensorTile.Box to use the board with STM32duinoBLE with the link to the firmware needed for the update.
Best Regards,
Carlo

[gemelko]

Carlo,

Thank you again. My own code using the BLE stack is also now working perfectly. By the way, did you just repair those links to the .bin files in the wiki? I thought I tried them and found them to be broken, and that's why I went searching and eventually found the files in the repository I mentioned above. No matter, things are working as expected now.

Kind regards,
Glenn

[cparata]

Hello Glenn,
indeed today I realized that those links were broken and I repaired them. I'm sorry for that. Next time, I suggest you to submit an issue if you find something wrong also in the wiki pages. You can avoid to waste your time. ;-)
Best Regards,
Carlo