Low-Level interfacing of BTLC1000

Log in or register to post comments
Go To Last Post
4 posts / 0 new
Author
Message
C_squared
C_squared's picture
Level: New Member
Joined: Mon. Jul 25, 2016
Posts: 1 View posts
#1
Posted by C_squared: Mon. Jul 25, 2016 - 12:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi @ all,
because of the low TX current, I want to use the BTLC1000 in an existing project. Basically I want to replace a Nordic nRF8001, which is a BLE link controller that requires an external MCU and is interfaced via SPI. According to the datasheet the BTLC1000 can also be used as link controller (without its internal M0) controlled by an external MCU.

 

I am missing documentation about the low level interfacing of the BTLC1000 and an external MCU. When going through Atmel's API, the interesting functions seem to end up in precompiled libraries.

I need to know about the low-level configuration, to be able to use the existing project's MCU without Atmel's API. (I only need broadcasting and to alter advertise data, no callbacks or event calls).

 

I discovered the simple broadcaster example, and monitored all wires of the BTLC1000-Xplained with a logic analyzer to get more insights.

 

 

@ 1: UART_RX and _TX (115200Bd) seem to show the same data (around 40 bytes on TX), even when parameters like device name were changed.

@ 2: On MISO line (SPI_MISO according to data sheet) an UART protocol signal transfers a huge amount of data with 115200Bd.

@ 3: On CS (SPI_SSN according to data sheet) and MISO some bytes are exchanged (UART 115200Bd). Here parameters like ADV_UUID_DATA, ADV_DATA_APPEARANCE_DATA, ADV_DATA_NAME_DATA and ADV_DATA_MANUFACTURER_DATA seem to be exchanged.

 

Does anyone know, if the M0 of the BTLC1000 is used in the Atmel examples, or is the SAM on the Xplained board used to program it (i.e. in step 2)?

In the example, UART is set as BLE link controller interface, so I expected all the configuration data to appear on UART line. Or is MISO and CS used as UART between M0 and BLE link controller? In this case, controlling and programming the M0 of the BTLE1000 is implicitely done by the Atmel API....

 

Is it possible to generally send some configuration bytes to the BTLC1000 to make it start broadcasting without the huge data transfers shown above?

 

Thanks in advance for help:-)

Bare Metal Rock'n'Roll!

Tags:

Wireless, Bluetooth
Top
meeko_percii
meeko_percii's picture
Level: New Member
Joined: Tue. Mar 15, 2016
Posts: 19 View posts
Posted by meeko_percii: Fri. Jul 29, 2016 - 08:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTLC1000 is connected to the host MCU through UART's. There are 2 UART modes possible.

a. 4-Wire mode : UART with flow control enabled. RX,TX,RTS,CTS lines are used.
b. 6-Wire mode : 2UART's used. 1UART with flow control enabled and another without flow control.
c. Firmware Patch: In case of bug fixes or feature enhancement is being done on BTLC1000, and that being transferred from the Host to BTLC1000 via this UART. Since ROM is one time programmable, the firmware change can not be flashed on BTLC1000 ROM right away. Hence, its being sent from the Host on every power-on and being run from the RAM of BTLC1000. This is done at the beginning of the communication between host and BTLC1000.
d, In 6Wire Mode this firmware patch is sent through the UART without flow control. After the patch download the regular communication between Host and BTLC1000 will happen through another UART with flow control.
e. In 4Wire mode both patch download and regular communication happens through the same UART

Top
uracolix
uracolix's picture
Level: Resident
Joined: Tue. Jun 17, 2008
Posts: 563 View posts
Location: Meissen, Germany
Posted by uracolix: Wed. Oct 12, 2016 - 06:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTLC1000 has some odd behaviour in its way of its initial communication. It starts in 2wire UART mode (hardly fused with the efuses of the BTLC1000). Because this 2wire communication is not stable (a.k.a. data loss for larger amounts of data) the chip is switched right after boot to another UART which has handshake lines enabled to transfer the startup patch (see LA snapshot at #1). This mechanism is called 6wire mode, because 2 UARTs are involved (2+4). After the patch download (LA #2) it still communicates on the 4wire UART. What the toggles that still occur on UART1 (RX/TX_UART) after LA#3 mean, I've never really found out. I think I saw that the BTLC1000 is slightly ahead of the mircrocontroller, so it might be that BTLC1000 is challenging the MCU (like a watchdog) ... but I'm not completely sure. There was a way to "re"-fuse the BTLC1000 that it initially starts in 4 wire UART mode ... therefore you need to ask Microchip/Atmel for the respective documents  ...  "re"-fusing can be done in 2 or 4 wire UART mode but it is irreversible (it is an OTP fuse). Also a hint is to change/update Atmel Studio - the BTLC1000 drivers change from time to time and you might see different (better) behaviour after an update :-) 

Top
uracolix
uracolix's picture
Level: Resident
Joined: Tue. Jun 17, 2008
Posts: 563 View posts
Location: Meissen, Germany
Posted by uracolix: Wed. Oct 12, 2016 - 06:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

>Is it possible to generally send some configuration bytes to the BTLC1000 to make it start broadcasting without the huge data >transfers shown above?

 

To my last available knowledge: "NO", the patch was always required. Things may change if new silicon revisions were available but this questions needs to go to the Atmel-Support.

Last Edited: Wed. Oct 12, 2016 - 06:27 AM
Top