Starting point for building OpenThread applications using the nRF52840 - nrf52

I'm new to the nRF52840 and OpenThread platform and I'm looking for example code building a sensor application with an nRF52840 Micro Dev Kit USB Dongle.
I managed to set up a Raspberry Pi as border router, to build and flash the ot-cli-ftd, and to set up an OpenThread network with the NCP and two other nodes.
What I did not find on the OpenThread or nRF web sites is a "maker-friendly" example application, e.g. combining the OpenThread-CLI and some custom code for reading sensor data via I2C or SPI and sending data via MQTT (or MQTT-SN).
Is there an example how to build such an application for an nRF52840 Dongle?
I understand that I have to be careful to add USB and boot loader support in my firmware images to avoid "bricking" the dongles (they have no JLink interface, so AFAIK the only way to flash them is via the DFU boot loader), so I would prefer to start with some working example.

Thank you for your interest in Nordic nRF52840 and OpenThread.
Generally, there are many examples provided in the nRF5 SDK for Thread and Zigbee.
nRF52840 Dongle is also known as PCA10059, SDK provides examples that are running on it. I think that the Full Thread Device, Commandline Interface is a good starting point (examples/thread/cli/ftd/usb/).
There are quite many other examples, even with MQTT-SN.
They do not support the Dongle with the bootloader but having information that I will try to pass below you will be able to achieve such configuration.
You are right that there is a difference in the memory layout.
Dongle with the MBR and the Bootloader - PCA10059 variant: thread_cli_ftd_usb_gcc_nrf52.ld
MEMORY
{
FLASH (rx) : ORIGIN = 0x1000, LENGTH = 0xdb000
RAM (rwx) : ORIGIN = 0x20000008, LENGTH = 0x3fff8
ot_flash_data (r) : ORIGIN = 0xdc000, LENGTH = 0x4000
}
Development Kit without the MBR and the Bootloader - PCA10056 variant: thread_cli_ftd_usb_gcc_nrf52.ld:
MEMORY
{
FLASH (rx) : ORIGIN = 0x0, LENGTH = 0xfc000
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x40000
ot_flash_data (r) : ORIGIN = 0xfc000, LENGTH = 0x4000
}
You can find details in the Memory layout section.
Please note that the Multiprotocol examples use Softdevice while the Thread-only do not need it and use that space for the application.
There is a way to unbrick the dongle, actually even two of them.
One is a cable with a needle connector - TC2050-IDC-NL.
The second option is soldering a 10-pin connector at the back of the dongle and using a ribbon cable.
Having any of them enables you to connect the programmer and flash the MBR and the Bootloader which are available with the SDK mentioned above.
For future nRF related questions I highly recommend Nordic Devzone where you can get help from engineers working with Nordic Semiconductor.

Related

How to send data from STM32 USB port to Raspberry PI USB port?

I want to send data through USB between STM32 and Raspberry Pi. I don't want to use USB to Serial convertor, but instead have a actual USB Connection (maybe CDC class). I have to send data at high rate (Full speed). Please guide on how to achieve this?
A USB-serial connector is simply a microcontroller implementing a USB CDC/ACM virtual COM port and bridging to a UART which you would connect to a microcontroller's UART interface.
In your case you can simply implement the CDC/ACM directly on the STM32 using either of its USB device controller peripherals (USB support varies depending on the specific device https://www.st.com/resource/en/application_note/dm00296349-usb-hardware-and-pcb-guidelines-using-stm32-mcus-stmicroelectronics.pdf).
How you actually implement that will depend on what specific part, and what library or framework ecosystem you are using (e.g. SPL, CubeMX, Mbed). There are reference implementations, examples, drivers and libraries for all of these.
Your milage may vary, but I have measured ST's own USB library and example CDC/ACM virtual COM for STM32F1xx on a 72MHz MCU achieving 700kbits/s. Note that the performance is independent of the baud rate you might set on the host when you open the he VCP. Setting the baud rate simply sends a control packet to the device that can be used to set the baud rate of a UART in bridging applications. In your case such control packets can be ignored. There are similar packets for modem control signals such as DTR, RTS, CTS and RI, which you might choose to us for flow control or other signalling.

How to flash without STLINK

My STLINKV2 is not working anymore, not detected by Linux, it failed after the first successful flash. I ordered a new one but it will take 60+ days to arrive. Meanwhile I have heard on Youtube you can program Bluepills directly by connecting cut open USB cable to certain pins and then using a jumper. But I cannot get any precie information on this, is this really possible and how?
You should use the embedded bootloader. You can flash it through several interfaces. Look at AN2606, maybe you can find an already written flasher. Good luck STM32CubeProgrammer handle it.
If you intend to program it through usb, look also at AN3156 all protocols document are referred in chapter 2 of AN2606
THOSE AREN'T CUT OPEN USB CABLES they are USB to serial adapters for arduino's bootloader
They connect them like this:
The problem is that this requires the Arduino STM32 bootloader to be flashed in it.
Another option will be to use STM32CubeProg this program allows you to program your stm over
Serial
SPI
I2C
USB
You'll need to set the BOOT0 and BOOT1 pins to the correct value (HIGH slash LOW) to allow it to go in flash mode during boot.
Here is semi outdated tutorial which tells most of the steps to program a STM using serial. (the Flash Loader Demonstrator is outdated and you should use STM32CubeProg)

Activating DFU (USB programming) on STM32F303

I am building a board based on the STM32F303RET6.
The Processor Datasheet, page 17/section 3.5, mentions programming can be done "using USART1 (PA9/PA10), USART2 (PA2/PA3) or USB (PA11/PA12) through DFU (device firmware upgrade)"
I am using a NUCLEO board with this processor.
I have connected the Vdd, Gnd, D+ and D- pins of USB to a NUCLEO board and disabled the power from the add-on programmer board.
However whenever I reboot it with BOOT0 HIGH the USB never enumerates any device.
I am connecting the pins directly to the USB plug without any external resistor. The datasheet seems to suggest these are not needed.
To make things a bit trickier, this processor has the additional particularity of not having a BOOT1 pin; it is a software bit.
My question is, does the processor actually support DFU by using the built in bootloader?
If so, how should one go about starting it and programming via USB?
Thank you very much,
Pedro.
PS: ST has actually got conflicting information about support for USB programming on this processor. While the Datasheet says it's supported, Application Note AN2606, page 81 (section 19) only mentions support for programming via USART1, USART 2 and I2C. It references the USARTs but it's unclear how they can be used.
I have connected the Vdd, Gnd, D+ and D- pins of USB to a NUCLEO board
and disabled the power from the add-on programmer board.
Check the actual voltage and current on Vdd. The host might limit the current, or shut the port down when the consumption exceeds 100mA before enumeration. Try it with an external power supply.
I am connecting the pins directly to the USB plug without any external
resistor.
You need an 1.5k pullup on D+ (full speed) or D- (low speed). This is from the STM32F3 Discovery schematics (that's an OTG socket, ignore the ID line for regular 4-wire ports)
When there is no pullup, the host can't detect when the device is plugged in, and therefore won't enumerate it.
ST has actually got conflicting information about support for USB programming on this processor. While the Datasheet says it's supported, Application Note AN2606, page 81 (section 19) only mentions support for programming via USART1, USART 2 and I2C.
There is no conflicting information there. Section 19 on page 81 refers to some other controllers.
The capabilities of your STM32F303RET6 are listed in table 36, section 18.1 on page 77. (As I've already pointed it out.) See also table 3 on page 23, line STM32F302xD(E)/303xD(E).

Interfacing socket code with a Linux PCI driver

I have two devices that are interfaced with PCI. I also have code for both devices that uses generic socket code. (The devices were originally connected by MII/Ethernet.)
Now, I need to write a PCI device driver to transport packets back and forth between the two devices.
How do I access the file descriptors opened by the socket code? Is this the same as accessing a character device file?
The PCI driver has to somehow capture packets from read() and write() in the code.
Thanks!
The answers to your questions are: (1) You don't, and (2) no.
File descriptors are a user-space concept, and kernel drivers don't interact with user-space concepts. (Yes, they're implemented by the kernel, but other device drivers don't get to play with them directly, and shouldn't play with them even indirectly.)
What you do is implement methods that will receive data that is buffered in a kernel-accessible memory space, and send that to your hardware, and then receive data from your hardware and write it (when asked) to a buffer in kernel-accessible memory.
You'll do this by implementing the character device driver APIs as well as the PCI device driver APIs and then registering your driver as a PCI device, and then a character device. While some of these methods may refer to file structures, they will not be the user-land structures that you know and love.
For devices that implement the Ethernet protocols, life is easier because you implement the Net Device Interface instead. This way all you have to write is the parts necessary to get data to and from your hardware.
What you'll need is specifications for the device hardware, how you control the hardware using PCI registers and regions.
The good news is, you don't have to do this alone -- there's a large community of kernel developers, and several good (and current) books on developing for the Linux kernel (see below).
References
Understanding the Linux Kernel
Linux Device Drivers
Essential Linux Device Drivers

Wireless communication: AVR based embedded system and iPhone

What is the best way to realize wireless communication between an embedded system (based on an AVR controller) and the iPhone? I think there are only two options: either WiFi or BlueTooth. The range is not really a problem, since both devices should stay in the same room.
I have no idea, if there are any useful WiFi boards that can be connected to an AVR based microcontroller system (or any small microcontroller), any hints would be highly welcome.
I guess the better solution would be BlueTooth, but there is also the problem: which BlueTooth board is best suited for attachment to an AVR system, and is it possible to use the iPhone BlueTooth stack for (serial) communication over BlueTooth with the AVR device.
I hope that somebody already realized such a system and can give some helpful tips...
You can get modules for both WiFi and Bluetooth that will connect to an embedded system through a UART interface, however a WiFi module will have far more processing power than your AVR microcontroller, often with spare capacity and I/O to execute additional user code, so connecting one to an AVR maybe somewhat redundant in many cases.
Bluetooth modules are simpler, less expensive, and the data-rate is better matched to the AVR's capabilities. For example these Parani modules. I have used them between an embedded system and a Laptop PC's Bluetooth, so given appropriate communications software, there is no technical reason why it could not be used with an iPhone I think. However this may be the flaw, on the PC the device was recognised as a virtual serial port, I don't know whether iPhone supports 'legacy' communications in quite the same way.
For comparison, a WiFi solution
From what I know, BlueTooth is very limited on the iPhone: There is only very few BlueTooth-Profiles implemented, and - even if they can be extended with a jailbroken iPhone - I doubt this is easy to use from the application layer.
On the other side, transferring via WiFi requires a lot of processing power and memory since much more things have to be implemented before you can even start transferring data: 802.11, cdma/ca, arp, tcp. That's a big task.
Is it an option to build a hardware extension to the iPhone ? You might be able to get the serial connection and power out of the dock connector. Then even ZigBee could be very helpful.
Here's an article you might find helpful. I would lean toward a WiFi solution just because of the added flexibility available.
http://www.embedded.com/design/networking/215801088
-t
Some of the other people at the office have done AVR <- Bluetooth -> Symbian and AVR <- Bluetooth -> PC solutions without trouble. There is lots of info, reference designs and source available. I have no idea of how hard it would be to use Bluetooth on Iphone.
The exact module is probability also not important as long as it got some type of serial interface (I2C,SPI) to interface to the AVR and some source code show how to use the module.
Is it an 8-bit or 32-bit AVR? For the AVR32 processors there's support
for WiFi in the Atmel 1.5.0 Software Framework using SD-card-mounted
WiFi modules from HD Wireless (http://www.hd-wireless.se), including
an IP stack (lwIP). Be aware that you need Ad-Hoc (IBSS) support to
connect directly to the iPhone.
There is WiSnap kit. It can connect directly to a standard RS232 interface or through the TTL UART interface to embedded processors. We are planning to use it in our project. It also has Ad-Hoc support.
There are some usage examples and an iPhone application for connection setup.
http://serialio.com/products/mobile/wifi/WiSnapKit1.php
What are you trying to communicate between your AVR and the Iphone? The Iphone is made for the web along with everything apple (which AVR's are decidedly not). So what works well is an embedded device that exposes a web-interface. Like the Transmission bittorrent client on Linux. Also nowadays many low-power small form-factor linux platforms exist that will allow you to do this.
For instance Gumstix has an ARM based platform that runs linux and includes WiFi (Overo Fire).