Xenon example BLE code


#10

It’s not a command it’s a setting
File menu

I’ve had it take just short half an hour.


#11

It took longer than half an hour, maybe close to an hour but it finally compiled. That was very long, I’m not used to having to wait that long. I wish that was somewhere in the documentation :wink:

I got it to flash successfully also. Now I can move to writing code for BLE.
I copied the code from your link and it advertises my Xenon device. However I couldn’t see it with nRF Toolbox app that the BLT tutorial suggests I use. I used NRF Connect app to find the device. I don’t know why NRF toolbox can’t see it.

I would like to changes BLE advertising and advertising packet contents. How do I get access to those files?

I’m new to how Particle source files work.


#12

No files, API calls :wink:
There are several example in the tutorials section I linked above.
And there also is this
https://docs.particle.io/reference/device-os/firmware/argon/#bleadvertisingdata


#13

API calls will make it easier I hope, I will play around and try to make it work :slight_smile:

Thank you!


#14

I tried changing the advertising name and it didn’t work.
Then I removed all code in setup() my device was still advertising. Nothing works.
I used iOS and Android apps.
What the heck going on? Has anyone been able to get Xenon to work? Is this an issue with Xenon?

void setup() {
    //(void)logHandler; // Does nothing, just to eliminate the unused variable warning
    //  BLE.addCharacteristic(temperatureMeasurementCharacteristic);
    //  BLE.addCharacteristic(batteryLevelCharacteristic);
    //  batteryLevelCharacteristic.setValue(&lastBattery, 1);
    //  BleAdvertisingData advData;
    //  advData.appendLocalName(“my name”);
    // While we support both the health thermometer service and the battery service, we
    // only advertise the health thermometer. The battery service will be found after
    // connecting.
    // advData.appendServiceUUID(healthThermometerService);
    // Continuously advertise when not connected
    //BLE.advertise(&advData);
    //BLE.stopAdvertising();
}

#15

Your update does probably not stick?
In such circumstances you’d typically add some different active behaviour that can be observed from the outside to check whether your new code actually stuck.

Yes


#16

What do you mean by different active behavior? BLE related or non BLE related?

And why wouldn’t it stick? If I compiled and flashed some code then this new code should be flashed to the flash memory. How can it not execute this new code?


#17

e.g. some LED blinking in one code and then another blink pattern for the next code. Or some Serial.println() message for one version and then some other message for the next.

Since this BLE is what you wonder whether it’s working or not I would not be using it for confirming itself.

First confirm whether this is the case, once that’s confirmed you could investigate the possible reasons - of which are multiple.


#18

I used Serial.println() and nothing was printed. This is my code in setup():

Serial.begin();

Serial.println(“Hello World!”);


#19

@ScruffR What are my other options? You mentioned multiple reasons in an earlier post.


#20

A single Serial.println("Hello World!") in setup() may easily be missed as it may be happening before the USB enumeration process has been completed.
I’d put that either into loop() or hook it up to the MODE button via System.on() to trigger on demand.

Also a D7 LED blink pattern can provide continous feedback.
Another option may be taking over the RGB LED via RGB.control(true) to set a custom colour.

You can also run particle binary inspect <yourFirmware.bin> file to ensure it’s actually built for the correct platform.
You may also try particle flash --usb <yourFirmware.bin> -v to get a more verbose output regarding the flashing process.


#21

I’d put that either into loop() or hook it up to the MODE button via System.on() to trigger on demand.

I tried in the loop() and it didn’t print.
I don’t know what you mean by hooking it up to the MODE butting via ‘System.on()’ . I’m new to Particle development.

Also a D7 LED blink pattern can provide continous feedback.

So I should write a code to blink LED on D7? I don’t understand this.


#22

I ran particle flash --usb <yourFirmware.bin> -v . What is Invalid DFU suffix signature?
here’s the output:

Opening DFU capable USB device…
ID 2b04:d00e
Run-time device DFU version 011a
Claiming USB DFU Interface…
Setting Alternate Setting #0
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash "
Downloading to address = 0x000d4000, size = 11920
Download [=========================] 100% 11920 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!

Flash success!


#23

I also ran binary inspect and it looks like it’s built for Xenon:

PS C:\Projects\Code\Particle\FirstProject\FirstProject_1\FirstProject_1\target\1.4.4\xenon> particle binary inspect FirstProject_1.bin
FirstProject_1.bin
CRC is ok (430289ef)
Compiled for xenon
This is an application module number 1 at version 6
It depends on a system module number 1 at version 1406


#24

That can be ignored. This is a message that is emitted by the 3rd party dfu-util but doesn’t indicate an actual problem.

However, all these outputs don’t seem to suggest an immediate problem, so my next guess would be that your device just doesn’t execute the code - probably due to SYSTEM_MODE(AUTOMATIC) (default when not stated otherwise) without SYSTEM_THREAD(ENABLED).

I should probably have asked that earlier:

  • Is this Xenon hooked up to a mesh network?
  • With what gateway?
  • What does the RGB LED do?
  • Can you share your code?

#25

It is not hooked up to a mesh network. I only have a USB cable plugged into it.

RGB LED goes to yellow when it goes to DFU mode and then after it is done flashing it starts blinking BLUE.

Here’s my code:

#include "Particle.h"

// This example does not require the cloud so you can run it in manual mode or
// normal cloud-connected mode
// SYSTEM_MODE(MANUAL);

//SerialLogHandler logHandler(LOG_LEVEL_TRACE);


void setup() {
  Serial.begin();
  Serial.println("Hello World!");
  
}

void loop() {
  Serial.println("Hello World!");
    
}

Also, the BLE chip is advertising all the time and I don’t know if that’s a normal behavior since my code is not telling it to advertise.


#26

This means your application will not run.
You first need to get your device out of Listening/Setup Mode (blinking blue).
The BLE advertising comes from the Setup Mode which expects you to connect to the device via the Particle App for setup.

I’d also suggest using SYSTEM_MODE(MANUAL) and SYSTEM_THREAD(ENABLED).


#27

So I’m suppose to place SYSTEM_MODE(MANUAL) and SYSTEM_THREAD(ENABLED) at the beginning of the file?

I just did that and compiled and BLUE led is blinking still.
So I am not doing something right. What am I suppose to do to get it out of this “listening mode” ?


#28

Since Xenons were not supposed to be running without an “owning” mesh it’s not that straight forward.
If you had a gateway device it would be easy. You could just assign it to that dummy mesh and then never reconnect to it again (SYSTEM_MODE(MANUAL)).

Since I don’t have any “virgin” Xenons anymore I don’t know what exactly is required to do that without assigning it to a mesh.

You could search for Xenon standalone and Xenon without mesh tho’

e.g. this might help


#29

Before I continue with Xenon let me first ask if I should even be using Xenon for my application since it looks like it wants to be connected to the mesh to work. I want to change BLE advertising and have custom characteristics, is this possible on Xenon ? Is there another product that might be better/easier for this application?