Transitioning from Arduino to nRF52840 for IoT Application Development

[frusciante89]

Hello Nordic Community,

I am currently working on a project that involves transitioning from a working Arduino application to a finished IoT application targeting Garmin-style devices to display acceleration and velocity data. I have some background in both software and hardware development and have purchased the Nordic nRF52840 Evaluation Board to facilitate this transition.

I would like to seek your advice on the recommended steps to make this transition smooth and efficient. Specifically, I am interested in:

1. SPI/I2C Communication: Any guidance on setting up SPI communication with accelerometers and other sensors.

2. Data Handling: Best practices for reading and processing acceleration and velocity data from sensors.

3. Bluetooth Communication: How to establish Bluetooth Low Energy (BLE) communication with Garmin-style devices, including any example code or libraries.

4. Power Management: Tips on optimizing power consumption, especially for battery-operated applications.

5. Development Tools: Recommended tools and IDEs for development with the nRF52840, along with any libraries that may help streamline the process.

6. Testing and Validation: Suggestions for testing my application, particularly for ensuring reliable communication and accurate data readings.

Any insights or resources you could share would be greatly appreciated, as I aim to create a robust and efficient application.

Thank you in advance for your help!

AA

[Edvin]

Hello,

I agree that the DevAcademy might be the correct starting place. 

To be specific, I suggest that you run through these courses, in this order:

1: nRF Connect SDK Fundamentals

2: Bluetooth Low Energy Fundamentals

3: nRF Connect SDK Intermediate

The first one to familiarize yourself with the SDK and the tools required to use our chips and Development Kits.

The second one to familiarize yourself with the Bluetooth Low Energy (BLE) libraries, and how BLE works in general.

The third one is mainly if you want to look at how to set up SPI. I2C is covered in the first one, but if you want to communicate with an SPI device, there is a lesson in there showing how to do that. 

Best regards,

Edvin

[frusciante89]

Hi Edvin,

Thank you so much for your help! Over the last few days, I’ve been diving into the SDK fundamentals and wanted to provide some additional details about my project.

Project Overview:

• My goal is to develop a Garmin-compatible device (ATN+) that can measure acceleration, velocity, and force.
• I plan to use an accelerometer/gyroscope (LSM6DSO) and two ADS1220 chips to read data from four strain gauges.
• Since the PCB needs to fit into a small space within the device, minimizing the circuit’s footprint is essential.
• Power will be supplied by a LiPo battery.

Development Progress:

1. Component Selection: After selecting sensors, I chose the nRF52840 as the microcontroller since it offers ATN+ compatibility and seems ideal for this application.
2. Sensor Testing: I tested the sensors using an Arduino and successfully collected the expected data.
3. nRF52840 Development Kit: I sourced the dev kit to transition from Arduino to the nRF ecosystem and am currently getting familiar with Nordic’s SDK.
4. Next Step: Connect all sensors to the board (preferably via SPI) and verify I’m reading meaningful data.
5. Next Step: Develop the Bluetooth/ATN+ communication, ensuring I can transmit and receive data, which will validate the whole stack.
6. Next Step: Design a custom PCB featuring the nRF52840 and the aforementioned sensors, phasing out the dev board.
7. Next Step: Switch from USB power to a LiPo battery and incorporate a battery charging circuit.

Questions:

1. SPI Configuration: I plan to use SPI to connect the accelerometer/gyroscope and both ADS1220 chips, with the nRF52840 acting as the master. Is it feasible to have all three devices on a single SPI bus, or would separate channels be a better option? Are there any examples or resources you can point me to?

2. Logic Levels: It looks like the nRF52840 operates at 3.3V logic, which eliminates the need for level shifters (a necessity in my Arduino prototype). Can you confirm if this applies both in USB mode and when using the LiPo battery in the final design? I want to avoid any electrical mishaps!

3. Advice from the Community: If anyone has gone through a similar process, I’d greatly appreciate any tips or things I should look out for during development.

Thanks in advance for your insights!

[Edvin]

frusciante89 said:

Development Progress:

Sounds reasonable.

You can also test with a battery by powering the nRF via the Li-Po connector. You can also measure the current using the Power Profiler Kit II, to calculate how long the device will last on a battery charge. 

I have not played too much around with it yet, but you can also look into the nPM Fuel Gauge. I believe you can use the nPM1300 for this, but this is not my area of expertise, but we have some development kits for this. 

frusciante89 said:

SPI Configuration:

You can use one bus (as long as they can run on the same SPI frequency). Then you just need one additional GPIO per device (chip select pin). 

frusciante89 said:

Logic Levels: It looks like the nRF52840 operates at 3.3V logic, which eliminates the need for level shifters

The output voltage on the GPIOs is dependent on the REGOUT0 register. So you can set it to values ranging from 1.8V to 3.3V. This is regardless of what the input voltage you have, and what source this is coming from. Please note that on the nRF52840 DK there is some external hardware that sets the output voltage on the GPIOs to be fixed when the "nRF Power Source" switch is set to VDD. So the nRF's output voltage is controlled by the REGOUT0 register, but the voltage on the pin header is scaled up to 3.3V. If you set the nRF Power source" switch to USB or LiPo, then the output voltage on the GPIO headers will follow the REGOUT0 register settings.

Best regards,

Edvin

[frusciante89]

Dear Edvin, 

thanks a lot! 
I've spent last week having a look at the Nordic Developer Academy course, which helped a lot!
I am now able to sample all sensors, only thing missing is the bluetooth connectivity part (I'll start tackling next week) and the battery power config.

In preparation for the next steps, my main question is:

• how do I move from the nRF52840 dev board to my custom PCB? I want the keep the minimum amount of components while obviously being able to program my board and flash the firmware.

Some specific doubts: 

1. in my custom PCB, how can I program with same toolchain (currently using nRF52840DK + VSCode)? Do you have an example of how this can be implemented? Do I just need to include in my PCB a debugging connector through the SWDIO, SWCLK, VDD, and GND pins? 
2. Is it ok/feasible to use a 2 layers PCB for the QIAA package?
3. in the production version of the board, should flashing/debugging be done through a USB or through the debug header?
4. Do I need to add a memory/EEPROM to my PCB? Or can the flash memory of the nRF52840 be enough? I do not need to save anything in particular apart from the program itself that runs on the nRF chip and a couple of register settings for my sensors
5. once I manufacture the PCB, can I use the nRF52840 DK as the debug/flash "master"? Or do I need a JLink device to connect to my PC?
6. When programming an external board with the nRF52840 DK, will the nRF52840 DK provide power to the target and will the target need its power (through the LiPO). Just making sure I have no conflicting power sources 
7. the board power will be supplied by a LiPO battery in the production version. In the hypothesis that all flash/debugging can be done through the debug header, I assume no USB power will be needed, apart from charging the battery?
8. As the USB will be needed to charge the LiPO, can you point me to any reference circuit to be able to do that? I had a look at the Thingy:53 charging circuit, but it looks like you have to manually set the power source. Can this be done automatically without the user having to flip a switch?
9. For reference, it would be ideal to have all GPIOs running at 3V3 High level. I hence assume the power rail of entire PCB should be running at 3V3
10. As I will be using the Bluetooth and ATN connectivity features, is there anything to consider/add apart from the antenna design? Does the power architecture changes when using Bluetooth/ATN? (I will not be using NFC)
11. For my sensors, as I'm using both I2C and SPI, I've selected the following GPIO (I've tried to avoid the low speed ones). Does this mapping look good?
    1. I2C (SCL) - 0.26
    2. I2C (SDA) - 0.04
    3. SPI (DRDY) - 0.13
    4. SPI (CS) - 0.15 
    5. SPI (CLK) - 0.17 
    6. SPI (MOSI) - 0.22 
    7. SPI (MISO) - 0.24  
12. Are pull-up resistors needed for the I2C pins? I remember reading that there are internal pullups already present?

Also, just to confirm my dev flow is correct, I've been using the nRF52840 DK to develop my application, but some doubts arose:

• I've noticed the board has both the nRF52840 and nRF5340 chips (marked as U1 and U2) implemented, I assume the nRF5340 is used as a middle-man in the DK board? I guess I can skip it in my custom PCB? Also, I've been using the USB IF MCU port to work on the nRF52840, is this correct? I've just noticed there's another USB port, named USB nRF52840 - should I use this instead?

Thanks again, I'm learning a lot and sorry if I asked silly question, I really want to make sure I get this right 

Best

AA

[Edvin]

1: Yes. That is the common way to do it, I believe. At least the simpler way. You will have a few connectors that you can use for programming. Basically, using an external programmer (you can use the programmer on the DK to program external devices). What you need is that the external device is powered, and you need to connect SWDIO and SWDCLK, as well as GND and VDD. 

2: I am no pcb layout expert. Follow the reference circuitry for the configuration you want to use. You can submit your layout for review, or ask genereic questions about it, but do so in another ticket, and a HW engineer will have a look at it.

3: You can't flash through USB (the USB peripheral on the nRF). You can perform DFU(device firmware upgrade) via USB if you'd like, but then you will need to flash a USB bootloader using the programming pins. You can also perform DFU using BLE, but likewise, you will need to program a bootloader first. 

4: That is a good question. For simple applications, it may be enough with the internal flash, but you need flash space for: The application, including the Bluetooth controller (all part of your application .hex file). If you intend to do DFU/FOTA (Device Firmware Upgrade / Firmware Over The Air (upgrade)), you will need space for the bootloader itself, in addition to 2x your application. This means that the application can be no more than ((Total flash - Size of bootloader) / 2), because you need to fit the new and old application at once in addition to the bootloader. 

5: You can use the DK and one of the DEBUG OUT ports on the DK. Both the P19 and P20 on the DK can be used as debug out ports.

6: You can provide power from the DK, or externally. E.g. on the DK's P20, if you connect VTG and GND Detect to VDD and GND, respectively, it will use the P20 as the debug out target, instead of the onboard nRF52840. But the VTG and GND Detect themselves doesn't provide GND and VDD, but you can use the VDD nRF on P20, or any of the normal VDD pins on the DK. Or you can power it via e.g. a USB connector on the custom board, or a battery. Up to you. 

NB: The VTG and GND detect are named a bit differently on different DK versions, but show me a picture of your DK's P20, and I can point out which ones to use. 

7: Correct, but it depends on the VDD level on the custom board. They are not rated to work with debug out on VDD lower than 3.0V, but in most cases, it works. So what is VDD when the device is connected to power? And what if you power it from the DK's VDD? If you do that, then it should work. Please see this description. I know it is for the nRF5340DK, but it has the same debugger. And the nRF52840 DK description doesn't have that figure, which is why I sent you the one for the nRF53DK. 

8: I am not sure. Please open a new ticket with this question (since it is more HW related). Someone fitting will have a look at it. 

9: I believe so, but ask in the HW ticket.

10: HW Ticket.

11: Looks good. Please refer to: https://docs.nordicsemi.com/bundle/ps_nrf52840/page/pin.html

Note that some pins are AIN pins, which is OK. But there is a limited set of AIN (Analogue input) pins, so if you would need one, those are the one you can use for it. But if you don't need AIN pins, then you are good. (Perhaps you want to use one for battery measurement?)

Also note that some pins are marked with QSPI. These are intended for QSPI. You can use them for other things, but if you need QSPI for e.g. external flash, then you would want to reserve them for that. Also note that the QSPI pins are not routed out to the pin header on the DK, without shorting some solder bridges and cutting some other on the DK. These are described on the back of the DK. 

12: Internal pullups are configureable in SW. 

frusciante89 said:

I assume the nRF5340 is used as a middle-man in the DK board?

The nRF53 on the nRF52840 DK is actually the debugger for the nRF52840. 

frusciante89 said:

I've just noticed there's another USB port, named USB nRF52840 - should I use this instead?

This USB port is used if your application is using the nRF52840's USB peripheral, e.g. if you are developing a USB stick, a usb dongle for a mouse/keyboard peripheral or any other application that uses the USB peripheral present on the nRF52840. 

Ok, so a lot of information, but unfortunately I couldn't answer everything. I could cooperate with one of my HW specific colleagues, but I think it is faster to split the questions into two tickets. One where we keep the software questions, and one to handle the HW questions. 

So gather up the HW questions in another ticket. It is possible to use the USB peripheral on the nRF for power, but I don't think you can use it directly to charge your battery. I think you need to use a Power Management IC (PMIC) for that, such as the nPM1300. But ask about it in the HW ticket that you can post here on DevZone.

Best regards,

Edvin

[frusciante89]

Thanks a lot Edvin! 

This is extremely useful!

I've opened another ticket for the HW parts:  (Missing Forum Thread) 
Hopefully will get an answer soon

Best,
AA