Xenon example BLE code


#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?


#30

It is possible to have Xenons run standalone entirely - it just requires some initial persuasion to do what it’s not voluntarily doing :wink:

The bad thing about having done so much with these devices is that I just tend to throw all tools I know of at it and at the end it usually does what I want, but I haven’t got any wiser which of the actions of what combination thereof did the trick :blush:


#31

Not sure if that will help but i had the same struggles as you seem to have and made a small post explaining how i fixed things some weeks ago :

Also, the original post explains things quite clearly :slight_smile: