Uploading Custom Firmware onto OpenLog Artemis Board

I have been trying (unsuccessfully) to update the firmware on my OLA board with a custom sketch and was hoping someone might be able to point me in the right direction.

I have installed the Apollo 3 board definitions in Arduino 1.8.12 (on OS X) and am compiling the blink sketch with the “Artemis Redboard ATP” board selected.

Using the artemis_firmware_upload_gui it seems that my exported binary is successfully uploaded (as I see “Upload complete!” in the status log) but the code doesn’t seem to running. The default logging functionality and serial menu is gone so something has changed but I don’t see any blinking.

Uploading the precompiled OLA Firmware binary (v17) does work and restores the default logging functionality so I guess the problem is somehow related to my binary and not the upload gui or the board.

I also tried compiling and uploading the ConstantSerialBlastTest which also seemed to upload successfully but when I open the serial monitor nothing comes through.

Any ideas on what I am doing wrong would be most appreciated!

The LED_BUILTIN doesn’t seem to be correct on this board. If you define the LED on pin 19, the ‘STAT’ LED will blink just fine, see below. I’m not sure what the ConstantSerialBlastTest is but I tested the serial and it works. I’m using arduino IDE 1.8.13 and SparkFun Apollo3 Boards 2.0.2. So I don’t think you are doing anything wrong.

#define LED 19

// the setup function runs once when you press reset or power the board
void setup() {
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED, OUTPUT);
  Serial.begin(9600);
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(LED, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  Serial.println("OFF");
  digitalWrite(LED, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);                       // wait for a second
  Serial.println("ON");
}

Thank you for the reply @stealth!

I should have mentioned that I did actually try using pin 19 for the LED instead of LED_BUILTIN and unfortunately had the same result.

I just tried again to be sure with the code you posted and unfortunately it didn’t seem to work–I didn’t see any blinking and nothing is coming through when I opened up the serial monitor.

Not sure what to try next. One thing to note is that I am getting an error when I try to burn the boot loader via the Arduino IDE and similarly it fails when I try to burn it from the upload gui.

This is the error I am getting when I try to re-burn the boot loader:


Arduino: 1.8.13 (Mac OS X), Board: "RedBoard Artemis ATP, 921600, Ambiq Secure Bootloader (Recommended)"

java.lang.NullPointerException

at cc.arduino.packages.uploaders.SerialUploader.burnBootloader(SerialUploader.java:329)

at processing.app.Editor.lambda$handleBurnBootloader$61(Editor.java:2379)

at java.lang.Thread.run(Thread.java:748)

Error while burning bootloader.

Anyway let me know if any other ideas for things I could try. Thanks!

java.lang

Generally anytime you see “java” in an error, it indicates an issue with the IDE. You’re best bet is to uninstall the board from Arduino and reinstall it. If that doesn’t solve the issue, you might need to completely remove the IDE and reinstall it and the board package.

Thanks for the suggestion @YellowDog. I tried reinstalling the board definitions and The Arduino IDE (and even updated my JRE) but was getting the same error.

I switched over to windows and installed everything there to see I could successfully upload custom firmware to the OLA board from that environment.

Unfortunately I am getting the same behavior on Windows:

  • I am able to successfully compile and export a binary of the code @stealth posted above with the Artemis RedBoard ATP selected in The Arduino IDE.

  • However when upload the binary to the board via the Artemis Firmware Uploader GUI, it says the upload was successful but I don’t get any blinking.

  • On Windows I am also able to upload the code directly to the board from The Arduino IDE using the Sparkfun Variable Loader but while the upload completes in the IDE, just like with the Artemis Firmware Uploader GUI, the code does not run (the STAT LED doesn’t blink).

  • What does work for me is uploading the blink.bin binary that is included in the Artemis Firmware Uploader GUI repo. The blue STAT light blinks as expected when I upload this binary.

So both in an OS X environment and in Windows 10, the custom firmware I compile with Arduino 1.8.12 does not run on my OpenLog Artemis board. I also tried with Arduino 1.8.13 but got the same result.

Not sure what else to try :? …

Hello!

Tell me which Board to choose in Arduino (1.8.13) in the Board Manager when compiling a project for SparkFun OpenLog Artemis (DEV-16832). Unfortunately, the SparkFun OpenLog Artemis Board is not present there.

1.jpg

paulmans:
Arduino: 1.8.13 (Mac OS X), Board: “RedBoard Artemis ATP, 921600, Ambiq Secure Bootloader (Recommended)”

Try decreasing your Baud Rate to 115200. I’ve never been able to successfully upload code to any Artemis-based products using 921600 on macOS.

Cheers,

Adam

foxii:
Hello!

Tell me which Board to choose in Arduino (1.8.13) in the Board Manager when compiling a project for SparkFun OpenLog Artemis (DEV-16832). Unfortunately, the SparkFun OpenLog Artemis Board is not present there.

The OpenLog Artemis doesn’t have a board definition (yet). The SparkFun RedBoard Artemis ATP is the correct board to select.

Also to note that it is possible to use “Export compiled Binary” and the Artemis Firmware GUI (https://github.com/sparkfun/Artemis-Firmware-Upload-GUI) to uploaded binaries to the OLA.

Cheers,

Adam

Problem solved. It was necessary to downgrade my version of the Arduino Artemis Core (Apollo 3 boards) to version 1.2.1. After doing this I can compile a simple sketch and successfully run it on the OLA board.

I experienced this issue with v2.0.2 and v2.0.3 of the Arduino Artemis Core boards library, maybe future versions won’t have this issue.