SparkFun Forums

[E.HP.S]

Okay, this is a little complicated to explain, but I've run into three Artemis units (2 independent units and one Artemis Nano), all purchased through Digikey, and they seem to all share one address of sorts.

Basically, when all three of them are turned on and advertising themselves, they muscle each-other out of the way in nRF connect and when I say to connect to one, it's completely random which one I connect to. What's more, while I'll be able to identify which Artemis I'm connected to based on an LED indicator and the unit's characteristics, it always has the incorrect name assigned to it. We discovered this while testing with four older Artemis units and what I'm talking about can be seen below.

BluetoothLE#BluetoothLE78:2b:46:0e:87:c8-66:77:88:23:bb:ef New Artemis Nano
BluetoothLE#BluetoothLE78:2b:46:0e:87:c8-c0:07:e0:8d:20:44 Old Artemis 1
BluetoothLE#BluetoothLE78:2b:46:0e:87:c8-c0:87:d0:82:dd:04 Old Artemis 2

BluetoothLE#BluetoothLE78:2b:46:0e:87:c8-66:77:88:23:bb:ef New Artemis 1
BluetoothLE#BluetoothLE78:2b:46:0e:87:c8-66:77:88:23:bb:ef New Artemis 2

BluetoothLE#BluetoothLE78:2b:46:0e:87:c8-c0:5c:82:ea:d0:08 Old Artemis 3
BluetoothLE#BluetoothLE78:2b:46:0e:87:c8-c0:04:64:ea:b0:03 Old Artemis 4

As you can see, New Artemis Nano, New Artemis 1 and New Artemis 2 all share the same (MAC?) address. Is there anything I can do within the code to fix this, or am I stuck with these three (and possibly more) trying to muscle each other out of the way when they're active. The device I'm working on is meant to work in pairs connected to a central device, so it's not like I can just have one running at a time.

[paulvha]

Yep.. known issue.. which library version do you use? 1.2.X ?
look at https://github.com/paulvha/apollo3/blob ... bdaddr.ino

[E.HP.S]

Yep.. known issue.. which library version do you use? 1.2.X ?
look at https://github.com/paulvha/apollo3/blob ... bdaddr.ino

Which one are you asking about? ArduinoBLE? If so, it's... 1.2.2? I thought I was at 1.2.9.

I wanted to update to 1.3.X but when I tried, things went haywire and I haven't had time to find out why

[paulvha]

It is around the Sparkfun Apollo3 board library. This was solved in the later versions of V2.x.x
The ArduinoBLE code seems to be going through (nearly) uncontrolled changes in support of the new UNO R4 WIFI board.

[E.HP.S]

It is around the Sparkfun Apollo3 board library. This was solved in the later versions of V2.x.x
The ArduinoBLE code seems to be going through (nearly) uncontrolled changes in support of the new UNO R4 WIFI board.

Hrm. Thanks for referring me to your fix. I'll try to find the Apollo3 board library version and see if I can update it

[E.HP.S]

Okay, it says I have 2.2.1 installed. Could the bug have come back?

[paulvha]

No.. not really. Looks like a problem with the Apollo3 chips OR the way option setting was when the archive for a board version was set. In the file /.arduino15/packages/SparkFun/hardware/apollo3/.2.2.1/cores/mbed-os/features/FEATURE_BLE/targets/TARGET_Ambiq_Micro/hal/apollo3/hci_drv_apollo3_c. See from line 160 for explanation and line 734 for implementation when a reset is sent, it will read the chipID to overwrite the default.

BluetoothLE#BluetoothLE78:2b:46:0e:87:c8-66:77:88:23:bb:ef New Artemis Nano : Not Unique
BluetoothLE#BluetoothLE78:2b:46:0e:87:c8-c0:07:e0:8d:20:44 Old Artemis 1: Unique
BluetoothLE#BluetoothLE78:2b:46:0e:87:c8-c0:87:d0:82:dd:04 Old Artemis 2: Unique

BluetoothLE#BluetoothLE78:2b:46:0e:87:c8-66:77:88:23:bb:ef New Artemis 1 NOT unique
BluetoothLE#BluetoothLE78:2b:46:0e:87:c8-66:77:88:23:bb:ef New Artemis 2 NOT unique

BluetoothLE#BluetoothLE78:2b:46:0e:87:c8-c0:5c:82:ea:d0:08 Old Artemis 3 Unique
BluetoothLE#BluetoothLE78:2b:46:0e:87:c8-c0:04:64:ea:b0:03 Old Artemis 4 Unique

[E.HP.S]

I found the github discussion for V2.0.6 where you and Wenn were discussing the changes to fix the address problem. Do I still use your solution to fix this, or is there a more... "official(?)" solution for it? I'm feeling a little lost at the moment and I'd rather not go digging through other libraries and accidentally break something if I can avoid it.

[paulvha]

The official one is the one that Sparkfun added.

When an HCI reset is sent, as done during AruindoBLE.begin(), it reads the CHIP ID and overwrites the default BD_addr. BUT for that fix to work the parameter AM_CUSTOM_BDADDR had to be set when building the libmbed-os.a for the variant. From what I can see from V 2.2.1 this was done during the build. You can check the chip ID with:

Code: Select all

void setup() {
 Serial.begin(115200);
 while (!Serial);

 Serial.println("read the Apollo3 chip id");

 am_hal_mcuctrl_device_t sDevice;
 am_hal_mcuctrl_info_get(AM_HAL_MCUCTRL_INFO_DEVICEID, &sDevice);

 uint8_t bd_addr[6] = { sDevice.ui32ChipID0, sDevice.ui32ChipID0 >> 8, sDevice.ui32ChipID0 >> 16, 
                          sDevice.ui32ChipID1, sDevice.ui32ChipID1 >> 8, sDevice.ui32ChipID1 >> 16};

 for(uint i = 0; i < 6; i++) {
  Serial.print(bd_addr[i], HEX);
  Serial.print(":");
 }
 
 Serial.println();


}

void loop() {
  // put your main code here, to run repeatedly:

}

[E.HP.S]

Thanks for clarifying! I'll keep that in mind. In the meantime, I tried your original fix and it worked like a charm. Now I'm back to figuring out how to clear an interrupt flag on the Artemis so that the interrupt stops triggering as soon as it gets attached to a pushbutton

[E.HP.S]

Hey, I got a *funny* follow-up for this. So, I've got a pair of previously working Artemis units that wind up with the same BLE address when programmed on one computer, but different ones when programmed on *another* computer. This is with the exact same code BTW, and that code doesn't mess with the BD_addr. This is less a request for help so much as a disbelieving chuckle to mask the frustration. I'll post a followup if I figure it out or I need help