BL5340 Series - Multi-Core Bluetooth 5.2 + 802.15.4 + NFC Modules

Yes, all BT modules include the needed LC filter components required for DC-DC Converter operation.

Lyra P and Lyra S modules include a 2.2uH inductor on VREGSW output and 4.7uF capacitor to ground.

The nRF528xx used on the BL65x modules use two voltage regulators, REG0 and REG1. In Normal Voltage mode only REG1 is enabled. In High Voltage mode both REG1 and REG0 are enabled. The BL65x modules include 10uH and 15nH inductors on DCC output and 1.0uF capacitor to ground on REG1. REG0 includes a 10uH inductor on DCCH output and 4.7uF cap to ground.

Note: The BL651 module uses the nRF52810 which uses a single voltage regulator. The BL651 includes 10uH and 15nH inductors on DCC output and 1.0uF capacitor to ground.

The nRF5340 used on the BL5340 and BL5340PA modules uses four voltage regulators, Main Voltage Regulator, Radio Voltage Regulator, High Voltage Regulator and a USB Regulator. In Normal Voltage mode the Main Voltage and Radio regulators are enabled while the High Voltage Regulator is disabled. In High Voltage mode the High Voltage regulator is enabled along with the Main Voltage and Radio regulators. The BL5340 module includes a 10uH inductor on the DCC outputs and 1uF capacitor to ground on the Main Voltage and Radio Voltage regulators. The High Voltage regulator includes a 10uH inductor on the DCCH output and 2.2uF capacitor to ground. The USB regulator uses an LDO only an no DC-DC filter components are needed.

As per section 3.7 of the BL5340/BL5340PA datasheets (links provided below) , these modules ship with no firmware loaded. Therefore, there is no Bootloader loaded to enable loading applications via UART and no support for FOTA (Firmware Over-the-Air) updates. It will be necessary to bring out the SWD interface on the PCB to enable programming the module with Nordic's nRF Connect SDK which uses the Zephyr RTOS platform. Once the Bootloader and/or FOTA firmware have been loaded to the module it should be possible to load future firmware updates via the UART or FOTA methods. See the Nordic DevZone for additional information on Bootloader and FOTA firmware options.

Datasheet - BL5340 Series
Datasheet - BL5340PA Series

With nRF Connect SDK v2.0.0 and later only VS Code is made available as an IDE as VS Code provides many features including both Command Line Interface (CLI) and Graphical User Interface (GUI) in one environment.

Prior to nRF Connect SDK, the 32.768KHz source in nRF5 SDK applications defaulted to using the external crystal oscillator. The BL65x DVK’s populate an external 32.768KHz crystal but it is not connected via open solder bridges. Therefore, either the solder bridges need to be shorted to make the external crystal connection or change the clock source to internal RC Oscillator via the sdk_config.h file.

With nRF Connect SDK the correct 32KHz clock source is selected depending on the EVK. For BL654 DVK examples are built using internal RC oscillator. On BL5340 DVK the external crystal oscillator is selected as the DVK does close the solder bridge pads.

If the 32KHz clock source needs to be changed an application can change accordingly in the prj.conf file of the project. The following direct dependencies need to be added to prj.conf to override the default clock configuration.

External Crystal Oscillator and accuracy selection:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_50PPM=y

Internal RC Oscillator and accuracy selection:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

Kconfig dependencies can be found:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.3.0/kconfig/index.html

These instructions are intended for Linux or Macintosh OS. They may work using WSL, Cigwin, or other bash style terminals in Windows although this is untested. 

It may be desired to communicate with a device attached to the USB-SWD without terminal emulation, I.E. Picocom, Screen, Putty.  This can be useful for writing bash scripts, or if you're using Zephyr's "west flash" and would like a quick way to check your output. 

1. Verify you have the program "stty" available using the command "which stty", if this does not return a value you will need to install it.  Fortunately "stty" generally comes standard with Linux and MacOS.  
2. Identify your serial device.  This can be done using the command "dmesg -w" then connecting the USB-SWD.  You will see output like this (In Linux).

3. (Optional) Assign the device name to a variable, for example "DEVICE=/dev/ttyACM0".
4. Configure "stty" to talk with the device "stty -F $DEVICE 115200 -echo -echoe -echok"
5. To see output from the device execute "cat $DEVICE &".  This will send serial communication from the device to Linux's standard output.  The "&" is to run this program in the background.
6. Now press the reset button on the USB-SWD, you should see the output from your device.  In this example the Zephyr "Hello World" example has been flashed to a BT510. 

7. (Optional) if you would like to send commands back to the device you can use "echo" or add an argument to your shell, "foo() { echo -n -e "$1\r" > $DEVICE; }".  Now commands can be issued directly from the command line, for example "foo "my_command"" will send the string "my_command" to the device. 

The NFC track does not need to be routed with a controlled differential impedance. The NFC antenna is different from the BLE antenna as it's differential and not 50 Ohm (each track is 50 Ohm single ended). Also, the frequency is very low, so the exact impedance doesn't matter as much. The inductance in the antenna is what matters for the NFC antenna. Since the antenna is differential, it's better to use a two-pin connection instead of U.FL which is a single ended connection. 

The inductance of the antenna together with the NFC antenna tuning capacitors forms a resonant circuit that is tuned to the NFC frequency, 13.56 MHz. Any change in the connection wires to the antenna can be compensated with the tuning caps.
 

For VQ (voice quality) at 8-bit 24kbps with 3 retransmissions. 4 is possible. Limiting factor is CPU processing of LC3 encode. OTA (over-the-air) bandwidth has room for more channels if you consider an additional CPU for LC3 processing.

Note Laird Connectivity maintains a partnership with Packetcraft for LE Audio SW Solution.

https://www.packetcraft.com/

Yes, every module can handle 4 channels. Additional modules may be used for additional channels. But there are RF interference concerns with the higher number of transmitters from additional modules. Possible to coordinate the modules so they do not interfere but may need to consider something more sophisticated to coordinate the devices to maximize the 2.4GHz spectrum.

Note Laird Connectivity maintains a partnership with Packetcraft for LE Audio SW Solution.

https://www.packetcraft.com/
 

When reset pin is pushed the pin behavior is undefined, it may be output or floating. It is not much that can be done about this other than ensure that the pin reset is pushed for a short period of time as possible, for instance >0.2us is sufficient to ensure a hardware reset.

For example in SmartBasic Interactive mode

ati 4

10    4    01 EFA44957769F
00

BLE devices can have multiple mac addresses and if the mac address begins 01 as above it signifies it is a random static address which is assigned during manufacture. While its random nature means its not unique the number of possible random static addresses is 2^(48-2)-2 a very large number so it is very unlikely you will ever see a duplicate, let alone in the same place at the same time.

Other MAC address types include

• 00 IEEE assigned public address, the same as used by BT classic devices
• 01 Random static, generated at manufacture
• 02 Random private resolvable with IRK. resolvable by other devices already known
• 03 Random private non resolvable

To address privacy concerns, there are four types of Bluetooth addresses in a BLE device which can change as often as required. For example, an iPhone regularly changes its BLE Bluetooth address and it always exposes only its resolvable random address. This feature is known as LE privacy. It allows the Bluetooth address within advertising packets to be replaced with a random value that can change at different time intervals. Malicious devices are not able to track your device as it actually looks like a series of different devices. To manage this, the usual six-octet Bluetooth address is qualified on-air by a single bit which qualifies the Bluetooth address as public or random: ▪ Public – The format is as defined by the IEEE organisation. ▪ Random – The format can be up to three types and this qualification is done using the upper two bits of the most significant byte of the random Bluetooth address.

On Laird Connectivity SmartBasic module, the address type can be set using the function BleSetAddressTypeEx(). On the other hand, Sysinfo$(4) can be used to retrieve the Bluetooth address if it is public or random static. Due to LE privacy 1.2, if the address type is random resolvable or random non-resolvable, it cannot be retrieved by the application layer since it is fully controlled by the baseband layer.

Note: The Bluetooth address portion in smartBASIC is always in big endian format. If you sniff on-air packets, the same six packets appear in little endian format, hence reverse order – and you do not see seven bytes, but a bit in the packet somewhere which specifies it to be public or random.

Yes, but software support should be sought direct from the Nordic Devzone as from Lairds point of view we provide only the hardware not the protocol.

Enhanced Shockburst (ESB) is a proprietary simple packet protocol for use in the Nordic modules. It is simple and easy to use and can give very low latency applications compared to BLE.

However, there is no encryption employed in ESB and ESB operates on a single frequency channel so there is no frequency immunity. You can implement your own encryption in upper layers though.

Also see Gazell (GZLL), which is another proprietary protocol from Nordic that builds on ESB.

You essentially have 2 options to write your application in C using

1. Packetcraft stack and tools Home | Packetcraft
2. Nordic Semiconductor Audio SDK Bluetooth LE Audio - nordicsemi.com

Yes, the Nordic Semoconductor nRFConnect SDK allows for LE Audio integration and provides samples. You could also develop your application using Packetcraft stack and tools.

Bluetooth LE Audio - nordicsemi.com
Home | Packetcraft

No, from Lairds point of view the BL5340 is hardware only. 

You can use the Nordic nRFConnect SDK to write your C application for the BL5340. For LE audio applications you can also use the Packetcraft stack and tools outside of nRFConnect.

nRF5 SDK SoftDevices are incompatible with the nRF5340 and there is no plan for any compatible release. The nRF5340 is designed to be used with the nRF Connect SDK (NCS), with either the Nordic SoftDevice Controller (not to be confused with the nRF5 SDK SoftDevices) or the Zephyr Bluetooth LE Controller (open source) as Bluetooth link layer. 
 
From <https://devzone.nordicsemi.com/f/nordic-q-a/76662/nrf5340-soft-device-backward-compatibility>

LC3 is the mandatory CODEC specified by the BT SIG but it is possible to use other 3rd party codecs if and when they become available. This is similar to how SBC was the mandatory codec for Classic Audio but 3rd party codecs such as APTX and LDAC could also be used.

For a codec to be used, both ends of the connection need to support the 3rd party codec, if not they will fall back to LC3 which must be supported by all devices.

Nordic nRFConnect SDK, also known as NCS is based on the Zephyr RTOS with support for Laird modules based on nRF52 and nRF53

Nordic nRF5 SDK is a legacy bare metal SDK with support for Laird modules based on nRF51 and nRF52

You can choose either SDK but need to know that nRF5 SDK will not be supporting new features going forward. So if starting a new BL65x or BL5340 project then it is recomended to choose nRFConnect SDK.

See nRF Connect SDK and nRF5 SDK statement - Blogs - Nordic Blog - Nordic DevZone (nordicsemi.com) for more details

Matter can be supported on the BL5340 (nRF52840) and the BL654 when using the Nordic nRF Connect SDK. However, due to the memory requirements of Matter it can not be used on the BL653, BL652 nor the BL651 given their flash and RAM memory footprint.The BL653 (nRF52833) has 512K of Flash and 128K of RAM and BL652 and BL651 has less than that.

There are instructions on how to reduce the memory footprint for Matter in the documentation on the nRF Connect SDK Main branch, Memory footprint optimization » Matter, but even using this you will not be able to get it down to a size fitting on the nRF52833. With the steps from the optimization page with the light bulb sample the size was reduced to approximately 730 kB of flash and 170 kB of RAM when building for nRF52840, which is still way too high for the nRF52833. Additionally, there are possibilities that the Matter flash usage will grow more before the official release, as more bug fixes and things from the Matter specification will be added.

Yes, this is possible.

Note: Laird Connectivity maintains a partnership with Packetcraft for LE Audio SW Solution.

https://www.packetcraft.com/

A fast and convenient way to read out the MAC address of each module during a test/production process would be through SWD from FICR (Factory information configuration registers) registers DEVICEADDR[0] and DEVICEADDR[1]. The following command will read the MAC address from our BLE modules:

nrfjprog --memrd 0x100000A4 --w 8 --n 6

Please note that reading the MAC address with nrfjprog will give the raw register content whilst using the SmartBASIC command ATI 4 (or by using sd_ble_gap_address_get() from nRF SDK) will automatically set the highest two bits to '11', since this is a requirement by the BT specification!

Please also note that reading from memory through SWD will halt the CPU. If you need your application firmware to start afterwards (like for performing some test sequence) you would have to run the CPU with

nrfjprog –run

More information on FICR registers are available in the respective data sheets, like this for nRF52840 / BL654.

Check the postion of SW4 and make sure it it is set correctly. For example if powering the DVK from USB set the switch to USB_5V. from the factory it may be set to DC_5V.

The BL5340 out of box demo scans for BT510 and BL654 BME280 sensors and sends the data to the cloud via ethernet with the data visualised on a webpage.

More details can be found here BLE_Gateway_Firmware/readme_aws.md at main · LairdCP/BLE_Gateway_Firmware · GitHub

 

if you would like to download the out of box demo firmware then it can be found at the following link. you might want to do this if you have erased the flash on the BL5340 DVK.

https://github.com/LairdCP/BL5340_Firmware_Manifest/releases

Firmware can be flashed to the BL5340 using different methods including (click for details):

• Command line/automated using nrfjprog
• Command line/automated using J-Link (not documented)
• GUI using SES (Segger Embedded Studio)
• GUI using nRF Connect (not documented)
• GUI using J-Link (not documented)

A selection of sample applications for the BL5340 can be found in our Github repository.

https://github.com/LairdCP/BL5340_Sample_Apps

Unfortunately the BL5340 is not able to run Laird Smartbasic. instead you should use C with the Nordic SDK/Zephyr.

The Edge impulse vibration demo shows how the power of the dual core BL5340 can be used for artificial intelligence applications.

The demo has 3 main parts

• Capture a training dataset
• Train the neural network
• Run the impulse

 The is a video overview of the demo available on Youtube

https://youtu.be/hmrx5gXm-YM

The repository can be found at https://github.com/LairdCP/BL5340_Firmware_Manifest

Board files can be found at

Laird Connectivity BL5340 DVK — Zephyr Project Documentation

The BL5340 Development Kit provides support for the Laird Connectivity BL5340 module which is powered by a dual-core Nordic Semiconductor nRF5340 ARM Cortex-M33F CPU. The nRF5340 inside the BL5340 module is a dual-core SoC based on the Arm® Cortex®-M33 architecture, with:

• a full-featured Arm Cortex-M33F core with DSP instructions, FPU, and Armv8-M Security Extension, running at up to 128 MHz, referred to as the application core

• a secondary Arm Cortex-M33 core, with a reduced feature set, running at a fixed 64 MHz, referred to as the network core.

The bl5340_dvk_cpuapp build target provides support for the application core on the BL5340 module. The bl5340_dvk_cpunet build target provides support for the network core on the BL5340 module. If ARM TrustZone is used then the bl5340_dvk_cpuapp build target provides support for the non-secure partition of the application core on the BL5340 module.

No, the BL5340 and BL653/BL654 are not the same pin mapping or layout, a whole new design is required for a PCB to have a BL5340 fitted. That being said, the reserved pins on the BL653/BL654 are:

• QSPI (BL654 only, no QSPI on BL653)
• SPIM4 (SPIM4 only, this is the high-speed SPI port at 32MHz)
• TRACE
• 32KHz Crystal
• NFC

On the BL5340, the list is similar:

• QSPI
• SPIM4 (SPIM4 only, this is the high-speed SPI port at 32MHz)
• I2C (only if they plan to use 1Mbps I2C which might be known as I3C?)
• TRACE
• 32KHz Crystal
• NFC

When running the BL5340 DVK out of box demo the Pinnacle Connect smartphone app will attempt to pair with the BL5340 DVK. You will be prompted to eneter a pass key, the passkey is 123456 and is also displayed on the BL5340 DVK LCD screen.

Yes. The BL5340 DVK comes with a BT510 BLE sensor for use with the out of box demo. But you can also emulate a BL654 BME280 sensor for use with the BL5340 OOB demo by loading the ESS hex files available at the link below

https://github.com/LairdCP/BL5340_Firmware_Manifest

Once loaded the BL5340 will function as a BL654 BME280 sensor and advertise the same advert format.

This application acts as peripheral environmental sensor allowing central devices to connect and monitor temperature, humidity, pressure and dew point. Please note that this is supplied as a test application for the Pinnacle 100 development kit and is for evaluation use only, it has not been tested through PTS for confirming that it adheres to the ESS service specification.

More information can be found here Common_Sample_Apps/ess_demo at master · LairdCP/Common_Sample_Apps · GitHub

Unlike previous generations of Nordic based Laird BLE modules, the BL5340 does not support out Smartbasic programming language.  Development is therefore done in C using Zephyr RTOS or the Nordic nRF Connect SDK.

For more information on developing for the nRF53 based BL5340 modules see the following links

BL5340 Series - Multi-Core NFC, Bluetooth 5.2 + 802.15.4 WiFi Module (lairdconnect.com)

Welcome to the nRF Connect SDK! — nRF Connect SDK 1.6.99 documentation (nordicsemi.com)

Laird Connectivity BL5340 DVK — Zephyr Project Documentation

 

Nordic Semiconductor needed to adopt a native RTOS for their latest generation of devices such as the nRF53 used in the BL5340. nRFConnect is Nordics first fully RTIOS based SDK and will be their active SDK going forward. Their previous SDK called nRF5 SDK will receive maintenance updates only going forward.

For more information see

nRF Connect SDK and nRF5 SDK statement - Blogs - Nordic Blog - Nordic DevZone (nordicsemi.com)

No. LE audio and classic audio are both subsets of BT audio but are not interoperable. In time it is likely that most BT classic audio use cases will be replaced by LE Audio.

No. The BL5340 is a single mode BLE only module. it does not support BT classic audio profiles such as HSP, HFP or A2DP.

However, LE Audio does support the same use cases and more but with new profiles and services.

No. LE Audio is an optional feature of BT5.2. BT devices can be qualified to BT5.2 and not support LE Audio. It is possible to be qualified to BT5.2 errata only and not have LE Audio support.

LE Audio makes use of a new codec called the Low Complexity Communications Codec.

This new codec provides lower latency then the standard BT Classic Audio coded (SBC).

Encoding time is in the region of 10ms for LC3.

This allows for a BLE Audio link using LC3 to encode, transmit and decode audio in he time sound travels in free space. This opens up application such as hearing aids that are very sensitive to latency.

Classic Bluetooth uses a codec called SBC. Its been used in BT classic devices for a very long time. Its also mandatory for audio applications, providing a common codec that all BT classic audio devices have access to, ensuring interoperability.

Other 3rd party codecs are also available such as aptX and AAC amongst others. These 3rd party codecs often provide improved audio quality or reduce latency but because they are no mandatory in the BT specification not all devices support them. Some are even proprietary to specific silicon vendors.

LE Audio introduces a new codec called LC3. LC3 gives developers options. With LC3 you can get the same or better audio quality at lower bitrates than with SBC or you can use higher bit rates and get even better quality audio.

A lower bit rate will result in less time on air and therefore potentially lower power consumption, which may be important for a battery powered device. Alternatively developers can choose a higher bit rate for maximum quality.

 

LE Audio supports the following topologies

Unicast

• Single peer to peer, which can be multichannel and bidirectional
• Separate left and right (earbuds)
• Multiple pairs of left and right (multiple earbuds)

Broadcast

• Connectionless broadcast with no acknowledgements
• Multiple channels
  • Stereo left and right
  • different language channels

Unicast allows for native stereo earbud type applications, built directly into BT5.2.
Broadcast allows for many new use cases such as public announcements in airports/railway stations. A cinema showing a film but with multiple language channels.

Yes. The BL5340 hardware supports LE audio as part of BT5.2.

The BT5.2 specification defines the building blocks for LE audio including support for the following

• Multi channel
• Audio sharing
• Improved audio quality
• mixed voice and music applications
• Low latency

However, the BL5340 needs to be mated with a suitable BLE audio stack with support for the required profiles and services. Laird Connectivity does not provide the LE Audio stack and relies on 3rd parties. Contact a Laird FAE for more details.

Yes, you need to qualify/list any product that uses BT SIG intellectual property, even if you do not use the logo or require interoperability with other BT devices. see here for more details. Qualify Your Product | Bluetooth® Technology Website

 

The BL5340 Audio Evaluation Kit allows you to test out of the box the following scenarios

1. Stereo Speaker: Stereo audio source to stereo audio sink 
2. True Wireless Stereo: Stereo audio source to seperate left and right audio using LC3, 80kbps, 48hz and 7.5ms frame size

additional scenarios are available in advanced demonstration mode. Contact www.packetcraft.com/support for more details

AIB stands for audio interface board. Three of which are supplied with the BL5340 Audio Evaluation kit and provide standard 3.5mm stero audio jack input/output for the evaluation kit.

The BL5340 audio evaluation kit comes with three BL5340 EVK and 3 Audio interface boards with 3.5mm stereo audio jacks. The only additional hardware required is audio source with a suitable 3.5mm socket, such as an MP3 player or Smartphone and an audio sink(s) with suitable 3.5mm socket, such as a  (active) speaker.

Theoretically as long as whoever 3rd party BLE stack is used is tested and supported on Nordic nRF5340 or nRF528xx used on BL65x modules.

Laird would not have tested anything other than Zepher/nRF SDK.

A 3^rd party CODEC could be used as well as long as it is targeted for nRF5340. However, licensing would need to be considered.

In general, cleaning the populated modules is strongly discouraged. Residuals under the module cannot be easily removed with any cleaning process. 

• Cleaning with water can lead to capillary effects where water is absorbed into the gap between the host board and the module. The combination of soldering flux residuals and encapsulated water could lead to short circuits between neighboring pads. Water could also damage any stickers or labels.
• Cleaning with alcohol or a similar organic solvent will likely flood soldering flux residuals into the RF shield, which is not accessible for post-washing inspection. The solvent could also damage any stickers or labels.
• Ultrasonic cleaning could damage the module permanently.

However, if water washing is required you will need to use deionized water. We do not recommend chemical cleaning and cannot guarantee it will not damage the modules. If you MUST clean PCB with chemicals it is recommended that you test on one board and then confirm the module still works after the process, prior to adding it to production, while understanding the above affects washing the populated PCBs can have on the module.

Laird Connectivity is committed to the long-term supply of all its standard embedded wireless modules and packaged products. Laird Connectivity’s products are specifically designed to meet the needs of the industrial and medical markets, which typically require 7 – 10 years product lifecycle. Although Laird Connectivity can’t guarantee that a component used in our products will not be obsoleted and cannot be reasonably substituted, Laird Connectivity can assure customers we will continue to sell our product when we have customer demand and can obtain the necessary components to build our products.

View our full policy here.