SparkFun Forums

[sghertner]

My newly purchased OpenLog Artemis is detecting a MS5637 Pressure Qwiic sensor, but not detecting a KX134 accelerometer Qwiic sensor. They appear to have different I2C addresses. I also tried with the KX134 as the only sensor on the Qwiic bus without any success. The KX134 is listed as a compatible sensor.

Any suggestions?

[PaulZC]

Hi,

Please check which version of the OLA firmware your board is running. We added support for the KX134 in version 2.5. If necessary, please upgrade by following these instructions:

https://github.com/sparkfun/OpenLog_Art ... UPGRADE.md

I hope this solves your issue,
Paul

[sghertner]

I downloaded the firmware uploader for mac. Uploaded ver 2.5 to my openLogger. Now the device appears bricked. I get the usb port showing in the /dev directory, but I don't get a menu anymore or any logging on the terminal screen. In addition, when I connect back my MS5637 and KX134, they do not have an LED illuminated like they had before. I don't see any LED's come on anymore on the OpenLogger except when I first bootup a quick blink of an orange LED some times. I tried loading ver 2.4 back but I can't the uploader to see my USB anymore.

[sghertner]

Further info, I tried to update the bootloader and got:

Artemis Bootloader Upload

Baud: 115200
File: /Applications/ArtemisUploader.app/Contents/MacOS/resource/artemis_svl.bin
Port: /dev/tty.usbserial-1420

Header Size = 0x80
original app_size 0x328c ( 12940 )
load_address 0xc000 ( 49152 )
app_size 0x328c ( 12940 )
w0 = 0xcb00330c
Security Value 0x10
w2 = 0x10008080
addrWord = 0xc000
versionKeyWord = 0x0
child0/feature = 0xffffffff
child1 = 0xffffffff
crc = 0xc703da31
Writing to file /var/folders/7y/kbd7y0554s3dqwz33x49wvh00000gn/T_OTA_blob.bin
testing: /var/folders/7y/kbd7y0554s3dqwz33x49wvh00000gn/T_OTA_blob.bin
Header Size = 0x60
app_size 0x330c ( 13068 )
Writing to file /var/folders/7y/kbd7y0554s3dqwz33x49wvh00000gn/T_Wired_OTA_blob.bin
Image from 0x0 to 0x330c will be loaded at 0x20000
Connecting over serial port /dev/tty.usbserial-1420...
Baud rate: 115200
Sending Hello.
No response for command 0x00000000
Failed to respond
Fail
Sending Hello.
No response for command 0x00000000
Failed to respond
Fail
Sending Hello.
No response for command 0x00000000
Failed to respond
Fail
Tries = 3
Upload failed
Complete.

[PaulZC]

Hi,

Apologies for the inconvenience. We only recently added the Mac version of the update tool, so it is possible we missed something.

Please make sure the Artemis is connected directly to the Mac USB port. Please do not connect via a hub.

Please also try uploading more than once. You can't harn anything by trying multiple times.

If you are still having problems, please tell us what machine and version of Mac OS you are using.

I hope this helps,
Paul

[sghertner]

I tried uploading several times. I get the following message:
Artemis Firmware Upload

Baud: 115200
File: /OpenLog_Artemis-V10-v25.bin
Port: /dev/tty.usbserial-1420


Artemis SVL Bootloader - Version: 5

[Uploading] █████████████████████████████████████████ 100%

Upload Successful


The serial terminal connects but doesn't display anything, and no LED's illuminate on the board. I am using USB-C to USB-C cable connecting directly to a Mac mini. Hardware is Mac mini (2018) 3.2Ghz 6-core intel core i7 16GB ram. I am using macOS Monterey Version 12.6.3.

[sghertner]

I tried uploading several times. I get the following message:
Artemis Firmware Upload

Baud: 115200
File: /OpenLog_Artemis-V10-v25.bin
Port: /dev/tty.usbserial-1420


Artemis SVL Bootloader - Version: 5

[Uploading] █████████████████████████████████████████ 100%

Upload Successful


The serial terminal connects but doesn't display anything, and no LED's illuminate on the board. I am using USB-C to USB-C cable connecting directly to a Mac mini. Hardware is Mac mini (2018) 3.2Ghz 6-core intel core i7 16GB ram. I am using macOS Monterey Version 12.6.3.

I tried on a windows machine and could update the bootloader to update and install firmware ver 2.5. However, I still don't get the LED's to light on the datalogger PCB except a quick blink of the orange LED on connection and no LED's when connecting sensor boards. Also, there isn't any output when connecting with Putty.

[PaulZC]

Hi,

Apologies for the inconvenience. I'm glad the upload is working for you.

It's rare, but we have seen situations where powering on the microSD card causes the OLA's power rail to brown-out, putting the OLA into deep sleep. It is microSD card dependent. Some cards cause it, most don't.

Some solutions / suggestions for you:

Please try removing the microSD card. Then connect via USB to wake the OLA. Or manually press the reset button to wake the OLA. Does the OLA power on and stay on if you do that? Can you then see the serial menu etc?

Please try a different microSD card, if you have one. Does the OLA behave normally with that card?

Last resort, please try the "No Power Loss" version of the firmware ( OpenLog_Artemis-V10-v25-NoPowerLossProtection.bin). That version has the sleep-on-power-loss feature disabled. If the power is lost, or it browns-out, the firmware will reset and keep running instead of going into deep sleep.

Apologies again for the inconvenience. I hope this gets you up and running,
Paul

[sghertner]

None of those suggestions made a difference. I had been using the board without an SD card. I tried with two different ones also. I tried uploading v2.3 and v2.4 with no power loss protection. The upload fails except for v2.5. It ran great out of the box from you with v2.4 except it didn't recognize the KX134. I didn't have an SD card, but was just watching the logging and playing with the log settings. Everything fell apart when I updated the firmware to v2.5 using the gui uploader on my mac. I bought this for a project for next week as a quick tool to get some datalogging. At this point, I need to either get a new one that works or start working on an alternative. I don't have high hopes for troubleshooting this board at this point.

[PaulZC]

Hi,

Do you have access to a Windows machine? If you do, please try updating and uploading using the Windows version of the tool. I did test the GUI on a Mac Mini before I released it, but maybe I missed something...

Apologies,
Paul

[sghertner]

All my attempts today and yesterday have been on a windows machine. I gave up on trying to use the mac a day or so ago.

[PaulZC]

Hi,

You appear to be doing everything correctly. All I can suggest is that you try updating the bootloader from your Windows machine, then try uploading the v2.5 firmware again. The order is important, bootloader first, then firmware. If that does not work for you, then all I can do is apologise and ask you to please return the board: http://www.sparkfun.com/returns

Best wishes,
Paul

[sghertner]

The windows gui firmware updater didn't work for me. I updated the bootloader then the firmware to v2.5. Both showed success, but no luck on getting any serial output from the openlog. I had success using the arduino ide and compiling the v2.5 source code. The openlog Artemis works again. However, even using v2.5 it's not recognizing the kx134. I tried the kx134 example program using an arduino uno, and it failed to recognize it. I suspect I have a bad kx134 board.

[PaulZC]

Hi,

Thanks for the update. I'm very glad your OLA is up and running again.

Please be careful with the Arduino Uno. If is is an original Uno, it is a 5V board. The I2C IO connections are 5V. The KX134 is 3.3V. That might explain why the KX134 not working with that board. Or, yes, you may have a bad board.

Please let me know if you need more help or advice.
Best wishes,
Paul

[sghertner]

Thanks for the heads up on the uno. I am actually using a Moteino that I had on my bench. It is a 3.3v device and uses the uno bootloader. I have a second KX134 board to test now also. I have modified the example wire I2C scanner sketch to just use a fixed address, 0x1F ( I also tried 0x1E for tests). I expanded the error reporting in that sketch to print out all 5 results. On my original KX134 board I get code error code #2, received NACK on transmit of address. This seems to be the same code if I don't have anything connected to the I2C bus. I have this in a loop, but the newer board locks up right after the wire.endTransmission() instruction. I made some voltage measurements and got different results for each board.

Board 1: CS=3.3V, ADR=3.3V, TRIG=0V INT1=2.8V INT2=2.8V SDA=3.3V SCL=3.3V
Board 2: CS=3.3V ADR=0.966V TRIG=0V INT1=0V INT2=0V SDA=0.2V SCL=3.3V

The pullups seem to be connected on each board when I use an ohm meter on those pads.

I would like to get at least one of them working. I guess I could cut all the onboard pullups, and try external pullups. However, INT 1 and 2 should not be connected and are driven low per the datasheet. So, I am not sure why I have voltage on Board 1. Any suggestions? Have you had issues like this on the KX134 Boards? Thanks