Support for Arduino Nano 33 BLE (Sense)

[manuelbl]

Now that the Arduino Nano 33 BLE and Arduino Nano 33 BLE Sense have been released and introduce:

• First genuine Arduino board based on Nordic nRF52840
• Arduino core based on Mbed OS framework

Are there any plans to bring them to PlatformIO? What will be needed? How can it be supported?

[clwillingham]

What would be needed to add support and close this issue? We're designing a nano 33 shield, and I would love to add PlatformIO support to the library.
Is it a matter of adding a configuration file to the boards folder? or are there other changes that need to be made?
If there is any way we can help add the nano 33 BLE boards to the PlatformIO system we'd be happy to help.

[charly37]

Should it rely on the ArduinoCore running on MBEDos or directly on MBEDos ?

[manuelbl]

I would prefer if priority was given to the Arduino core based on Mbed OS framework. This is likely the better solution for most users and in particular for users coming from the Arduino IDE.

[manuelbl]

In case anyone starts to work on this: the Arduino guys managed to build the nRF52 Arduino core upon an untagged branch of the Arduino Core API, namely the arduino_namespace branch. Those sources are needed and not part of the Arduino core based on Mbed OS framework.

[j0rd]

This have anything to do with anything?
https://github.com/arduino/ArduinoCore-nRF528x-mbedos

[manuelbl]

Yes, that's one piece. Many more are needed...

[luke-shields]

I would also love to see these boards supported

[valeros]

We've added support for this board, but we didn't try it on real hardware, so it would be great if someone could try to compile and upload a basic example.

Thanks!

[ivankravets]

Thanks, @valeros! Please note that you will need to use development version of platform:

[env:myenv]
platform = https://github.com/platformio/platform-nordicnrf52.git
framework = arduino
board = nano33ble

[bertrik]

I just happened to play with a NANO33BLE board this evening and ran into this thread. Using the platformio config above, it compiles for me.

Uploading didn't work for me yet.
The first problem is that ~/.platformio/platforms/nordicnrf52/builder/main.py has an unresolved symbol basename (line 48). I fixed that by changing a line from
from os.path import isdir, join
to
from os.path import isdir, join, basename

The second problem is some kind of uploading problem:

Building in release mode
Compiling .pio/build/default/src/BatteryMonitor.ino.cpp.o
Checking size .pio/build/default/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
DATA:    [===       ]  25.1% (used 65752 bytes from 262144 bytes)
PROGRAM: [===       ]  29.0% (used 285036 bytes from 983040 bytes)
Configuring upload protocol...
AVAILABLE: cmsis-dap, jlink, nrfjprog, nrfutil, sam-ba
CURRENT: upload_protocol = sam-ba
Looking for upload port...
Auto-detected: /dev/ttyACM0
Uploading .pio/build/default/firmware.bin
No device found on ttyACM0
*** [upload] Error 1

[vaetas]

I do have the same problem as @bertrik. Importing basename from os.path fixed initial Python Error, but now I am getting No device found on ... error. I have manually selected upload_port in ini file but the problem remains. Building seems alright.

EDIT: Added log

Verbose Upload Log

CONFIGURATION: https://docs.platformio.org/page/boards/nordicnrf52/nano33ble.html
PLATFORM: Nordic nRF52 3.8.0 #8ca39f0 (git+https://github.com/platformio/platform-nordicnrf52.git) > Arduino Nano 33 BLE
HARDWARE: NRF52840 64MHz, 256KB RAM, 960KB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, jlink)
PACKAGES: toolchain-gccarmnoneeabi 1.80201.181220 (8.2.1), framework-arduino-nrf52-mbedos 1.1.3, tool-sreccat 1.164.0 (1.64), tool-openocd 2.1000.190707 (10.0), tool-bossac-nordicnrf52 1.10866.191129 (1.8.66)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Framework incompatible library /home/vojtech/.platformio/packages/framework-arduino-nrf52-mbedos/libraries/mbed-memory-status
Found 5 compatible libraries
More details about "Library Compatibility Mode": https://docs.platformio.org/page/librarymanager/ldf.html#ldf-compat-mode
Scanning dependencies...
No dependencies
Building in release mode
MethodWrapper(["checkprogsize"], [".pio/build/nano33ble/firmware.elf"])
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [==        ]  16.1% (used 42168 bytes from 262144 bytes)
Flash: [=         ]   7.7% (used 76052 bytes from 983040 bytes)
.pio/build/nano33ble/firmware.elf  :
section              size        addr
.text               74636       65536
.ARM.exidx              8      140172
.data                1408   536871424
.nvictable            256   536870912
.crash_data_ram       256   536871168
.bss                40760   536872832
.heap              217416   536913592
.stack               2048   537131008
.ARM.attributes        46           0
.comment              146           0
.debug_info        162719           0
.debug_abbrev       35457           0
.debug_aranges      27440           0
.debug_ranges       44280           0
.debug_line        193310           0
.debug_str         539403           0
.debug_frame        82984           0
.stab                  60           0
.stabstr              118           0
Total             1422751
<lambda>(["upload"], [".pio/build/nano33ble/firmware.bin"])
AVAILABLE: cmsis-dap, jlink, nrfjprog, nrfutil, sam-ba
CURRENT: upload_protocol = sam-ba
BeforeUpload(["upload"], [".pio/build/nano33ble/firmware.bin"])
Use manually specified: /dev/ttyACM0
bossac --info --debug --port "ttyACM0" --write --reset -U --reset .pio/build/nano33ble/firmware.bin
No device found on ttyACM0
Set binary mode
Send auto-baud
Set binary mode
*** [upload] Error 1

[valeros]

Thanks @bertrik @vaetas. I fixed missing basename import and also added some modifications to the upload process. Could you please pull the latest changes and try again? Simple pio update command should be enough if there is no conflicts with your changes.

[manuelbl]

Thanks for the work on the Arduino Nano 33. I've tested it and it looks quite good already. The project compiles and compilation times are much faster than in Arduino IDE (where it's extremly slow).

There are a number of issues though:

1. Upload

Same problem as @bertrik and @vaetas. The path to the USB port is correct. And upload works from the Arduino IDE.

The output from pio run -v -t upload is:

<lambda>(["upload"], [".pio/build/nano33ble/firmware.bin"])
AVAILABLE: cmsis-dap, jlink, nrfjprog, nrfutil, sam-ba
CURRENT: upload_protocol = sam-ba
BeforeUpload(["upload"], [".pio/build/nano33ble/firmware.bin"])
Auto-detected: /dev/cu.usbmodem144401
bossac --info --debug --port "cu.usbmodem144401" --write --reset -U --reset .pio/build/nano33ble/firmware.bin
No device found on cu.usbmodem144401
Set binary mode
Send auto-baud
Set binary mode
*** [upload] Error 1

As a comparison, the Arudino IDE uses the below command:

/Users/me/Library/Arduino15/packages/arduino/tools/bossac/1.9.1-arduino1/bossac --port=cu.usbmodem144401 -U -i -e -w /var/folders/z2/t5tl6v7d2k95p70t98gd_wqw0000gn/T/arduino_build_635165/BatteryMonitor.ino.bin -R

I tried a similar command using the PlatformIO's bossac, and it worked once and then stopped to work (No device found...).

But PlatformIO's upload task works if I double click the board's reset button first. The LED then goes in a fade in / fade out mode.

2. Intellisense

In a simple Blink sketch, #include <Arduino.h> has squiggly red lines and the error message is

#include errors detected. Please update your includePath. Squiggles are disabled for this translation unit (/Users/me/Documents/PlatformIO/Projects/Nano-33-BLE/src/main.cpp).
cannot open source file "USBDescriptor.h" (dependency of "Arduino.h")

The missing file changed over time. It was mbed.h earlier.

In c_cpp_properties.json, the following include paths are listed:

"/Users/me/Documents/PlatformIO/Projects/Nano-33-BLE/include",
"/Users/me/Documents/PlatformIO/Projects/Nano-33-BLE/src",
"/Users/me/.platformio/packages/framework-arduino-nrf52-mbedos/cores/arduino",
"/Users/me/.platformio/packages/framework-arduino-nrf52-mbedos/cores/arduino/api/deprecated",
"/Users/me/.platformio/packages/framework-arduino-nrf52-mbedos/variants/ARDUINO_NANO33BLE",
"/Users/me/.platformio/packages/framework-arduino-nrf52-mbedos/libraries/PDM/src",
"/Users/me/.platformio/packages/framework-arduino-nrf52-mbedos/libraries/SPI",
"/Users/me/.platformio/packages/framework-arduino-nrf52-mbedos/libraries/USBHID",
"/Users/me/.platformio/packages/framework-arduino-nrf52-mbedos/libraries/USBMSD",
"/Users/me/.platformio/packages/framework-arduino-nrf52-mbedos/libraries/Wire",
 "/Users/me/.platformio/packages/tool-unity",
 ""

Possibly, directories are missing such as cores/arduino/mbed and cores/arduino/mebed/drivers/internal.

3. Create a new project

Creating a new project with the nano33ble board from PIO Home fails. The project is successfully created. But instead of opening it, an error message is displayed:

Could not initialize project

PIO Core Call Error: "The current working directory /Users/me/Documents/PlatformIO/Projects/Nano-33-Test2 will be used for the project.\n\nThe next files/directories have been created in /Users/me/Documents/PlatformIO/Projects/Nano-33-Test2\ninclude - Put project header files here\nlib - Put here project specific (private) libraries\nsrc - Put project source files here\nplatformio.ini - Project Configuration File\n\n\nError: Unknown board ID 'nano33ble'"

More or is likely to come... I will continue to test.

[vaetas]

Thanks for your help @valeros. I have pulled your changed but the error persisted.

<lambda>(["upload"], [".pio/build/nano33ble/firmware.bin"])
AVAILABLE: cmsis-dap, jlink, nrfjprog, nrfutil, sam-ba
CURRENT: upload_protocol = sam-ba
BeforeUpload(["upload"], [".pio/build/nano33ble/firmware.bin"])
Use manually specified: /dev/ttyACM0
Forcing reset using 1200bps open/close on port /dev/ttyACM0
bossac --info --debug --port "ttyACM0" --write --erase -U --reset .pio/build/nano33ble/firmware.bin
No device found on ttyACM0
*** [upload] Error 1

[bertrik]

I have the upload working now. I uploaded the BatteryMonitor example from the ArduinoBLE library and I can see a "BatteryMonitor" device now in a BLE scanner on my Android phone.

[vaetas]

What have you changed @bertrik. The Arduino gets into bootloader mode when I press Upload (led starts slowly blinking) but immediately fails.

[vaetas]

OK, I am not sure what happened but I tried to upload it again and it worked!

[valeros]

@bertrik @vaetas Thanks!

Thanks @manuelbl, good points!

1. The uploading should be fixed in the latest version.
2. I think that's fixable, this Arduino core has quite unusual form of include flags and that requires some modifications to VSCode project template.
3. That's strange, I cannot reproduce it, maybe you have two nordicnrf52 platforms and the stable one is used instead of the latest one from the repository?

[vaetas]

Thanks a lot for making this work @valeros!

However, I have one weird problem. When I try to upload binary, Nano will switch to bootloader mode (not sure the correct name) and upload from PIO will then fail with No device found on ttyACM0 error. But when I press Upload again, it will successfully upload. Third upload will again fail and so on.

I have tested this on two different Nano 33 BLEs and the bug appears on both of them. It seems like a problem with Arduino because it apparently closes connection when switching modes before upload. Does this happen to anybody else or is it only my problem? I am currently on Arch Linux.

[bertrik]

On my system (debian bullseye/sid) I noticed that I had modemmanager installed. I don't really trust it in the sense that I'm really sure it's not messing with anything that looks like a serial port (/dev/ttyUSBx or /dev/ttyACMx), so I made sure it was not running and uninstalled it. Perhaps this is something you can try too and see if it has an effect on upload success.

[manuelbl]

Thanks @valeros for the quick response. Regarding my issues:

1. Uploading: It's better now but in only works every other time (same as for @vaetas). I think I know why... see below.
2. Intellisense: I'm looking forward to a fix.
3. Opening project: Yes, I had two platforms (the productive one and the one declared in platformio.ini according to Ivan's instructions). So it won't be an issue anymore once it's officially released?

In the mean time I have also tested it on Windows. It behaves the same (same things working, same open issues). I've also tested J-Link upload and debugging and it works.

Upload

In the Arduino IDE, it works. So what's the difference? It's not the command line arguments for bossac. It seems that the Arduino IDE first resets the board before it starts bossac.

The clue is if the serial port is busy. Then you don't get an error message from bossac but from the Arduino IDE:

processing.app.debug.RunnerException
	at cc.arduino.packages.uploaders.SerialUploader.uploadUsingPreferences(SerialUploader.java:152)
	at cc.arduino.UploaderUtils.upload(UploaderUtils.java:77)
	at processing.app.SketchController.upload(SketchController.java:732)
	at processing.app.SketchController.exportApplet(SketchController.java:703)
	at processing.app.Editor$UploadHandler.run(Editor.java:2075)
	at java.lang.Thread.run(Thread.java:748)
Caused by: processing.app.SerialException: Error touching serial port '/dev/cu.usbmodem144301'.
	at processing.app.Serial.touchForCDCReset(Serial.java:107)
	at cc.arduino.packages.uploaders.SerialUploader.uploadUsingPreferences(SerialUploader.java:136)
	... 5 more
Caused by: jssc.SerialPortException: Port name - /dev/cu.usbmodem144301; Method name - openPort(); Exception type - Port busy.
	at jssc.SerialPort.openPort(SerialPort.java:164)
	at processing.app.Serial.touchForCDCReset(Serial.java:101)
	... 6 more

The exception is thrown on this line: https://github.com/arduino/Arduino/blob/master/arduino-core/src/processing/app/Serial.java#L107

It's the code for the board reset. It is run if the Arduino board definition contains:

upload.use_1200bps_touch=true

The setting upload.wait_for_upload_port=true is also relevant. It waits for the virtual serial port to reappear after the reset was triggered.

Could that be the missing piece?

[ivankravets]

@manuelbl Thank you so much for the hint!

@valeros please use reset code from Atmel SAM dev/platform. See “BeforeUpload” pre-action.

[ivankravets]

@sean-mcmanus is it possible to pass different configuration for C and C++ compilers? We have different flags for C and C++.

[sean-mcmanus]

@ivankravets Not currently via c_cpp_properties.json, because there is no separate cppCompilerPath and cCompilerPath setting (you could file a feature request for that...no one else has yet requested that though). However, via the custom configuration provider interface (https://github.com/Microsoft/vscode-cpptools-api/blob/master/api.ts) a custom configuration provider could provide separate compilerPath/args for .c files versus .cpp files.

[sean-mcmanus]

@ivankravets Another possibility is to have 2 different configurations, one for .c files and another for .cpp files, and then run the new cpptools.setActiveConfigName command (see microsoft/vscode-cpptools#4893 ) when the active file type changes, but that command hasn't shipped yet.

[valeros]

@sean-mcmanus

However, there's another bug in that a bunch of the defines are populated with "-D" in front -- those should be removed.

Thanks, this is already fixed, but hasn't been released yet.

The " around the path after the @ is causing the breakage to our compiler querying -- removing that fixes it.

Indeed, it works after removing extra quotes, but how we can handle whitespace characters in path to files specified using @file syntax?

[sean-mcmanus]

Our compilerPath property doesn't actually work with @\"path with spaces\" so the usage of \" doesn't fix the path with spaces scenario (could be a bug in our handling of the compilerPath).

However, using the compilerArgs enables the @\"path with spaces\" to parse correctly, e.g.

            "compilerPath": "~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-gcc",
            "compilerArgs": [
                "-iprefix/~/.platformio/packages/framework-arduino-nrf52-mbedos/cores/arduino",
                "@~/.platformio/packages/framework-arduino-nrf52-mbedos/variants/ARDUINO NANO33BLE/includes.txt"
            ]

[ivankravets]

We opened an issue in PIO Core platformio/platformio-core#3364

@valeros will back soon with updates. Thanks!

[valeros]

@sean-mcmanus Could you please also give us a hint about -include flag in compilerArgs? So, in a nutshell, VSCode is not able to see any definition that is specified in a special header file which is passed to the compiler via -include file command although the path to this file is specified in includePath section. It only works if path to this file is specified in compilerArgs using -I flag. Is that how it should work by design?

I prepared a basic example that is compilable using CMake, but when you open it in VSCode you'll see an issue with undefined symbol.
Thanks in advance!

[sean-mcmanus]

-include is equivalent to our "forcedInclude" setting (despite the name, it takes an array), so you should use that instead. Our compilerArgs setting is mostly just used for compiler querying for the system includes and defines, and code for translating the args into settings like forcedInclude that we understand doesn't exist (it exists for compile_commands.json processing though).

[valeros]

@sean-mcmanus Thanks for the hint, but looks like forcedInclude option also ignores paths specified in includePath. It works only if I specify the full path to a header file.
Am I missing something? Thanks!

[sean-mcmanus]

You've hit bug (feature request) microsoft/vscode-cpptools#2780 . I added a comment to that issue.

[valeros]

@sean-mcmanus Thanks! Also a question about escaping spaces in compilerArgs. For example, on Windows we have to wrap flags with spaces (e.g. @\"path with spaces\"), while on Linux the syntax with \" just breaks IntelliSense. I checked Includes field in the report generated by C/C++: Log Diagnostic command and indeed the includes specified in @\"/path/with spaces/file\" are missing on Linux if a flag contains escaped symbols. Is there a reason for this behavior?

[sean-mcmanus]

On Windows, we create a command line via appending spaces between the args (e.g. gcc -IC:\\path with space, which will fail without quotes), but on Linux/Mac we send the args in an array, which is equivalent to gcc "-I/path with space". Maybe on Windows we should be surrounding all the args with quotes? I don't recall any other user reports on this though, and I'm sure if anyone is relying on the existing behavior. You or I could create a bug or feature request at https://github.com/Microsoft/vscode-cpptools/issues .

[JasonBSteele]

FYI: I am able to build a deploy to Nano 33 BLE Sense. The application uses the builtin microphone and BLE and all works fine.

The only issue encountered is that the default path used for the project Library Options was specified as ~/Documents/Arduino/libraries. I had to change this to ~/OneDrive/Documents/Arduino/libraries. Happy to raise this as a separate issue if it is not known.

[tylerhartwig]

I see this item as open, but it seems that support is at least partially in the platform. I'm having trouble on my Arduino Nano 33 BLE, it will not execute the main loop when built with PlatformIO, but will using the Arduino tooling. My sketch is as simple as a Serial.println("Hello world"). I have tried with setting up Serial in the setup() function as well. All the code in the setup() function executes correctly, including printing out to Serial.

Not sure how to go about debugging this, and would love to use CLion + PIO over using the Arduino IDE, thanks!

[manuelbl]

This sounds like the typical problem of most Arduinos implementing the Serial-to-USB bridge in software (instead of using a dedicated Serial-to-USB chip). Such a solution depends on the MCU being responsive, in particular during USB enumeration, i.e. when the host computer discovers the USB device and needs to figure out the device configuration.

In your case, the MCU is probably stopped by the debugger during enumeration and therefore the host computer gives up on the device. Later the code is stuck in while (!Serial); or some USB interrupt handler.

The proper solution would be if the Arduino core was changed such that it forces USB enumeration when Serial is initialized and waits and stays responsive until the host computer has completed the device discovery.

As a workaround, try one of the following:

• Set a break point in setup after while (!Serial); and immediately continue when the debugger initially stops.
• Possibly add delay(1000); after while (!Serial); and set the break point even after delay.
• Change the initial break point to loop or some other function after Serial initialization using debug_init_break = tbreak loop (in platformio.ini)
• Remove the use of Serial

[tylerhartwig]

I tried #4, in order to test out the Serial path. I wrong a simple blink program

digitalWrite(LED_BUILTIN, HIGH);
delay(1000);
digitalWrite(LED_BUILTIN, LOW);
delay(1000);

This caused the board to go into an mbed os crash state (3 short blinks and 3 long blinks)

Curious what you said about the USB enumeration, it does work successfully with the Arduino IDE (a simple Hello World loop). Additionally, I did not think the Arduino Nano 33 BLE was debuggable without an additional board, is it? I do not have a debug board.

[manuelbl]

It looks as if there are more issues than I thought. If you run the program with PlatformIO's upload command (and not using the green debug arrow) and it fails, then there is indeed an issue in PlatformIO. Last December it has been working (except for IntelliSense issues). But a lot of things have changed in the mean time. I'll check it again.

Regarding debugging: It can be done with a debug adapter and some soldering: https://medium.com/@manuel.bl/arduino-in-circuit-debugging-with-platformio-9f699da57ddc

[tylerhartwig]

@manuelbl I am indeed using the green upload arrow (not the debug icon). I have tried this via command line as well, with the same results. Thanks for the link! Let em know if I can do anything to help the development.

[tylerhartwig]

@manuelbl FWIW, I tried going back through the old versions of this released package, none of them worked, guessing it may have to do with PlatformIO itself? I did not have an easy way to test this however.

[manuelbl]

I've just tested PlatformIO with my Arduino Nano 33 BLE again and I can report that it fully works: compiling, IntelliSense, uploading, executing, debugging.

For the first test, I've used a simple blink program and uploaded the program using the USB port:

platformio.ini

[env:nano33ble]
platform = nordicnrf52
board = nano33ble
framework = arduino

main.cpp

#include <Arduino.h>

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop() {
  digitalWrite(LED_BUILTIN, HIGH);
  delay(1500);
  digitalWrite(LED_BUILTIN, LOW);
  delay(500);
}

Next, I've hooked up my J-Link and added these two lines to platformio.ini:

upload_protocol = jlink
debug_tool = jlink

Both uploading and debugging worked flawlessly.

Finally, I've added serial output and it work again, even when debugging. And I have tested it both on macOS and Windows.

If it still doesn't work for you, you should probably go to https://community.platformio.org/ and for help there (incl. a full project to reproduce your error).

[tylerhartwig]

should jlink matter? what options can I use if I don't have a jlink?

EDIT: what version of pio do you have?

[manuelbl]

J-Link is only needed for debugging. Without J-Link, just omit upload_protocol and debug_tool. It will use the default protocol (sam-ba I think).

I'm using the latest official PIO core release (5.0.1) and up-to-date platform and other package versions.

[tylerhartwig]

Turns out the "Quick installer" path for PlatformIO installs the latest (5.0.2b) rather than latest stable, installing 5.0.1 fixed it! thanks for the help @manuelbl. I'm not sure if this means there will be a problem in the future with 5.0.2, or if it's just unstable.

[ivankravets]

@manuelbl do we have an issue with the upcoming 5.0.2-dev? We didn't do any significant changes.

[manuelbl]

@ivankravets I've tested it on both macOS and Windows and it works with 5.0.2-dev. I've used Visual Studio Code while @tylerhartwig also talked about CLion. So I doubt it's related to 5.0.2-dev. It might have been another installation problem though.

Some of the symptoms would also fit if the code contained while (!Serial) delay(1);. It has the effect that setup() waits until a terminal connects to the virtual serial port.

[tylerhartwig]

@manuelbl all of my tests beyond maybe my first comment were from command line. I did see issues when Serial was not included. If I'm not mistaken the version was 5.0.2b I'm not sure if that's the same as dev?

I specifically followed this for installation.

I followed up with this.

[tylerhartwig]

One additional question, is any support planned to be able to use mbed directly on this board? my understanding is this is possible via mbed command line, but having this in platformio would be awesome as well.

EDIT:

I should clarify, I know you can use mbed features, wondering if it will be possible to compile with mbed over arduino framework = mbed.

[lzq420241]

package framework-arduino-nrf52-mbedos tracks https://github.com/arduino/ArduinoCore-nRF528x-mbedos, which will continue tracking mbed 5.x series and new releases will only happen in case of security bugs.
Will it change to track https://github.com/arduino/ArduinoCore-mbed instead?

[tylerhartwig]

along the lines of what @lzq420241 said, I would be interested in some guidance on what needs to be done to update to the new 6.x library. I have some spare time I could potentially spend on this.

EDIT -- this should likely be tracked against #111 I'm guessing