Some fixes for Bosch XDK110 implementation

[mr-sven]

I make the OPCODE macro global available and modified the commands in em9301 chipset.
Fixed some prototype errors.
Modified some HAL includes in FreeRTOS -> should be checked.

[mringwal]

Thanks for the fixes. The main idea is to make OPCODE public and use it for the EM930x chipset, right?
I didn't find much documentation on the Bluetooth in the Bosch XDK 110, do you have a link for that?

[mr-sven]

Yes, the OPCODE should be used everywhere it has to. For my understanding it's a basic BT functionality.

The XDK uses a EM9301 Chipset, the original SDK implements the Alpwise BT Stack, but there was no easy way to use it as Central BLE device, here is a API link: https://developer.bosch.com/web/xdk/bluetooth-low-energy-ble-
They put the whole source for the intercom with the Alpwiese stack in a precombiled lib and provide only peripheral functions.

Due the fact of precompiled binary libs in the SDK and so on, I have no idea how to implement this in the btstack base so I created a separate repo for this https://github.com/mr-sven/xdk-btstack

[mringwal]

Hi Sven.

Yes, OPCODE is generic, so it could be moved to bluetooth.h. I'd prefer to call it HCI_CMD_OPCODE then. (But I can do this later as well). I'm busy this week, but will get to it.

I had a quick look at your repo. Pulling in BTstack as a submodule is a valid strategy.

You're implementing the HCI Transport in the port. There's a hci_transport_em9304_spi.c. Did you see that one by chance? Would it be possible to use that, or, is there anything missing?

Thanks, Matthias

[mr-sven]

Oh yes, I don't know if it's possible to use it, because the XDK uses the UART interface. I'll take a look if I can uses this.

At second I detect some errors with the L2CAP. If the stack receives a CONNECTION_PARAMETER_UPDATE_REQUEST it responses with CONNECTION_PARAMETER_UPDATE_RESPONSE that's ok, but in addition it sends a LE_CONNECTION_UPDATE which results in my constellation in a connection drop.
I don't know if this is the right communication flow, update a connection which is already updated.

[mringwal]

Hi. You've confused me :) In your BTstackAdapter.c, you've used hci_transport_em9301_spi_low_bytes_to_read which somehow got me thinking that it is using the SPI transport.

If they are using UART, you could use src/hci_transport_h4.c with platform/freertos/btstack_uart_block_embedded.c. You then only have to implement platform/hal_uart_dma.c. If you have RTS/CTS, you don't even need a ring buffer. This should reduce your platform specific code some more.

as for the l2cap conn param updates. could you post a .pklg (attach as .zip) for this? Just call hci_dump_open( NULL, HCI_DUMP_STDOUT ); after hci_init and then use tool/create_packet_log.py to create .pklg, which can be analysed with Wireshark.

[mr-sven]

Ok, the spi was a C&P error from the SPI state machine. I changed the OPCODE.
I switched now to the uart_block_freertos. I still have some issues, I come back with more details.

[mr-sven]

Here Attached the failure.
xdk_scan.pklg.zip
I can step over if I change l2cap.c line 1838:

- connection->le_con_parameter_update_state = CON_PARAMETER_UPDATE_CHANGE_HCI_CON_PARAMETERS;
+ connection->le_con_parameter_update_state = CON_PARAMETER_UPDATE_NONE;

[mringwal]

Hi Sven. Thanks for the log. In the log, the L2CAP Con Param Request is answered and the Con Params are updated by sending an HCI command. Then the connection breaks. That looks like a bug in the link layer of the EM9301.

For the EM9304, we initially had similar issues that got fixed by EM via the patches. Did you see any patches for the EM9301?

If not, you can try to set the acceptable params to something invalid, using gap_set_connection_parameter_range, to have BTstack reject any the update request - avoids patches to l2cap.c at least.

[mr-sven]

I found two patch files V0x0A in the XDK SDK 2.0.1 and V0x08 in the current SDK 3.6.0 but in the current SDK it will not be loaded because it is only in a sample folder of the Alpwise stack.
Is the patch volatile?

[mr-sven]

I've seen in the firmware app note is a Hexfile attached: http://www.emmicroelectronic.com/sites/default/files/products/datasheets/an609019.pdf

[mr-sven]

I'm adding the Patch file currently and implementing the update routine.

[mr-sven]

Ok, now I need you help, in the app note is written, in entering ISP mode, the device responses on a Reset with a hardware error code 0x80. That happens:

 INFO | XDK DEVICE 1: [00:00:01.348] LOG -- btstack_run_loop_freertos.c.257: RL: wait with timeout 4294967295
 INFO | XDK DEVICE 1: [00:00:01.349] LOG -- hci.c.2382: Hardware Error: 0x80

I registered also a hci_set_hardware_error_callback but the stack freezes and I don't know how to continue.

[mringwal]

hi. looking at the hci code to handle the hardware error, if you register the hardware error callback, BTstack calls you back but doesn't do anything else. So, you should get the callback and start loading the patch.

Sending HCI Reset as part of the patch update might be a problem. Also, there's no Command Complete event for the HCI Reset. Ah! I think that's causing the freeze. hci_stack->num_cmd_packets is still set to zero.

Could you try to add

hci_stack->num_cmd_packets = 1

into the case HCI_EVENT_HARDWARE_ERROR: (line 2389 on develop)?

[mr-sven]

Ok, I think I got it. The question is still, is the Patch on powercycle volatile or not, if not I have to implement a stack reset after upload.

[mr-sven]

Ok, I patched now Version 0x0A, but the error is still there, do you have any option to get in touch with EM?

[mringwal]

I would assume that the patch goes away on power cycle, so another HCI Reset is necessary. BTstack could take care of that, there's already code for a CSR_WARMSTART

Where did you get the patches from? Did you test without power cycle?
Yes, we have contact to EM - although the EM9401 has been replaced by the EM9304 and that one is probably also due to some 2M PHY enabled successor.

[mr-sven]

Ok, I can now patch an reset the device, the error still there, here the current packet log.
xdk_log_0x0A.pklg.zip

[mr-sven]

The Patch 0x0A is attached at the Upgrade App Note. The 0x08 file was found in the current XDK SDK.

[mringwal]

I'm clueless. The upgrade app note is this: http://www.emmicroelectronic.com/sites/default/files/products/datasheets/an609019.pdf
It's a PDF. How can a file be attached to a PDF? If I download on mac, I can read it.

[mringwal]

Other idea. What's the remote device? Could you try with a different device, too?

[mr-sven]

At first I was also confused about PDF Attachments but they exists, in Acrobat is a button for Attachments and here a Screenshot of Firefox PDF Viewer:

The device is a Etekcity Weight Scale, at the moment I don't have any other device. In the HCI log of my Mobile phone the device stays connected on Con Parm Update.

[mringwal]

Thanks for the info on pdf attachments. Never seen/heard about that, but yes, Firefox shows it, while Safari, Chrome, Preview on Mac don't.

As an alternative to the weight scale, you could run BTstack with an USB Bluetooth dongle and the libusb/windows-winusb port.

I've asked EM for the latest version of the patch but didn't get a reply yet.

[mringwal]

Hi Sven. I was told that patch 0A is the latest and that there are no known issues with updating the connection params in master role on EM9301.

Two options:
a) get an air trace of the failing connection, e.g. with our Raccoon BLE Sniffer on an Nordic nRF5x
b) test with a different device, e.g. bstack + USB dongle, to see if it that works, which might indicate an issue with your weight scale (which is also a bit unlikely as the conn param is requested by the scale).

[mr-sven]

I'll try the btstack + usb dongle becaus I don't have a nordic device.

[mringwal]

Hi @mr-sven Are you interested in finishing this?