PSOC 4 BLE disconnecting with CySmart App after 30 seconds.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
AnCo_2736831
Level 4
Level 4
25 likes received 10 likes received 10 likes given

I am using a PSOC 4 BLE pioneer kit. I have one LED blinking controlled by CySmart (using an android), and whenever they are running they disconnect from the CySmart App itself after 30 seconds all the time. I searched up this problem and found out that I need to separate the Characteristic UUID from the Descriptor UUID. I tried this, but the error still came. Does anyone know how to fix this problem?

0 Likes
1 Solution
Anonymous
Not applicable

You would have to change the LED to blink using a hardware timer. Either a watchdog timer, a PWM timing, or a Timer module.

You would put the timer object in the top-design-schematic page, and then configure it for running at the interval you want.

Then, you set up the logic for handling the timer to alternate the LED state every event based on your LED_BLINK variables/settings.

View solution in original post

0 Likes
21 Replies
Anonymous
Not applicable

If you have a timer of some sort telling it to disconnect after 30 seconds;

The connection is timing out: This would cause inconsistent timing imo, so it should be easily verifiable.

The phone may be disconnecting after inactivity/ 30 seconds to prevent wasted power/communications.

Without seeing your project it would be mostly conjecture; If you can, attach a minimal zip of your project to the thread and then we can all take a look at the project/settings.

0 Likes
lock attach
Attachments are accessible only for community members.

Here is the zip file of the program.

Anonymous
Not applicable

The "Connection supervision" timeout is set to 10 seconds; Possibly, the supervision timeout is starting after 20 seconds due to a missed keep-alive packet? (This is under the BLE component->GAP Settings->Peripheral preferred connection parameters->"Connection supervision timeout (ms)"

The EnterLPM function you are calling in main.c is being called incorrectly based on the wording of the documentation around the function. Try removing that line and see if the random disconnect after 30 seconds disappears.

Edit: Also, your project looks to be outdated. Try updating your PSoC Creator IDE, and the project to the latest versions

Thanks for the information e.pratt. But I tried changing/disabling the connection supervision timeout, I deleted the EnterLPM, and I updated my project but the program keeps disconnecting after 30 seconds. Is there any other fixes or ideas to ensure that the program does not disconnect like before?

Anonymous
Not applicable

To be 100% sure it is not the PSoC project disconnecting after 30 seconds, you could run it in debug, and halt when it disconnects to see what the state variables are.

But, since it is pretty consistently 30s, and the most likely culprits on the CYBLE project were disabled, I would suspect that the phone is disconnecting after 30s. Have you tried looking through the CySmart app to see if it is set to disconnect after 30s?

lock attach
Attachments are accessible only for community members.

I tried checking through the CySmart App, but could nothing saying it will disconnect after 30 seconds. Then I tried Debugging the program but with no success. However, I have made a slight modification to the program where instead of blinking, it just stays a solid red LED light. For some reason, this program works instead of the blinking program. I have attached the program below. The only changes I made were getting rid of the for loop, the CyDelay, and OFF (LED1_Write(!wrReqParam->handleValPair.value.val[1]);). Could there be a problem in adding these to the program?

Additionally, I tried doing the same thing on my iOS device (iphone 5s) and it still disconnected after 30 seconds.

0 Likes
Anonymous
Not applicable

If you setup the PWM to do the timing of the LED, it will run asynchronously from the program, and you can just enable/disable it when necessary to prevent software timing/delays from being needed for the blink timing, and causing issues with the BLE code.

The iOS device might require bonding/pairing to connect/stay connected?

There were alot of iOS timing requirements that were pretty stringent for Bluetooth.

See here: https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf

But getting it to work with the android is a step up at least

Good job on finding the delay and testing it!

0 Likes

I commented the CyBle_EnterLPM(CYBLE_BLESS_DEEPSLEEP);   line and it made no difference.

Do you think it is possible to have a blinking LED using PSOC 4 BLE Interface without having this disconnecting problem occur? Is there any commercial product with PSOC 4 BLE?

Any help would be much obliged. Thanks.

0 Likes
Anonymous
Not applicable

You would have to change the LED to blink using a hardware timer. Either a watchdog timer, a PWM timing, or a Timer module.

You would put the timer object in the top-design-schematic page, and then configure it for running at the interval you want.

Then, you set up the logic for handling the timer to alternate the LED state every event based on your LED_BLINK variables/settings.

0 Likes
lock attach
Attachments are accessible only for community members.

Hey e.pratt,

Good news! I tried using the PWM for the connection and the program did not disconnect after 30 seconds. However, do you know how to make the PWM function stop at a certain amount of time so that the next LED pwm can start? (I am using two PWM LEDs.)

I will convert this program to be able to have it control two pumps instead of LEDs and I am testing it out with LEDs to make sure if it works.

Below is the zip file attached with my latest modifications to the program. Thanks for the tremendous help!

0 Likes
Anonymous
Not applicable

You would need a separate timer to control when it stops or to disable the PWM after a number of pwm interrupts have fired.

You can either turn the PWM's on/off using software, or setup a hardware timer to turn them on/off.

(fyi: uint8 green_State = ~green_Read(); is a bit complement, whereas uint8 green_State = !green_Read(); is a logical complement. It should resolve to the same result in this case, but using a logical not versus a bit complement when comparing values will give you incorrect values)

I'll attach a version of your program with the timer changes once I figure out the exact timer/t-flip-flop setup

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hmmm; I set it up the way I expect you are wanting it to work? I wasn't sure what exactly you are looking to do with the timer though, so I merely set it to switch to the green led blinking after writing to the attribute, then wait 5s before switching to the red one. Note: if you disconnect it automatically resumes to the blue led blinking. This can be changed as well...

I've attached the project with changes here.

0 Likes
Anonymous
Not applicable

This program only works the first time it runs; You will need to play around with the timer/interrupt functions/settings to get it to run on each connect and write value. I'll post a fix if I have time later

The timer is not working and the PWM LED is just staying on green, even after 5 seconds. Also, the red LED would not even appear at all though it is called in the isr_switch_pumps_StartEx(PumpSwitchCallback); line. Do we need to connect the interrupt on the timer to make sure that the LEDs switch from green to red?

Anonymous
Not applicable

In the top design, the timer interrupt output pin should be wired to the isr_ component; This will cause the ISR to interrupt when the timer runs out. Leading to the 5 second time to switch from the Green LED to the Red LED. I must not have connected that properly the first time; I'll check tomorrow morning when I'm back at work, but I remember getting it working the first time you connect to the device, and getting it to work every time should only be a little more work.

Essentially: The timer will get started by the software API call, will run 5 seconds, fire the interrupt pin, causing the ISR to fire after 5 seconds, which will handle the interrupt by changing the LED to RED.

lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

I've attached the updated project to this post with the fix on the interrupt not being connected Simply mistake on my part. I've attached the updated project with the fixes in it

I fixed it so that the timer resets on disconnect, and the timer works correctly with the interrupting.

Thanks a lot Pratt! The program successfully switched from green to red in 5 seconds! However, I need the red LED to stop after 10 seconds so that the program would run green for 5 seconds, red for 10 seconds, and it will stop completely after that. With this being said, do I need to add another timer block for the red LED to stop after 10 seconds?

Anonymous
Not applicable

There are two different approaches you could do:

Create a single timer, and use that timer to count off the 5/10 seconds for both colors, or add a new hardware timer as you suggested above.

If you don't need the hardware digital blocks for something else, the simplest would be to add a new timer block I think.

Otherwise, it would only be a few lines of code space to reuse the first timer for timing both options.

(e.g. the timer is already set for 5 seconds, once it switches to the RED LED, set the period to 10 seconds and run it again, or use a counter and run it twice more before turning off the RED LED)

Pratt, I decided to go with the two-timer option but I was having some difficulty in creating a second timer and implementing it to the program. When I added another timer, and built the program, it gave me this error: Resource limit: Maximum number of Datapath Cells exceeded (max=4, needed=5). Is there any way of getting out of this problem? Can I even add more than one timer?

Anonymous
Not applicable

The cydelay() function will stall the processor until it reaches the time delay requested. This means that if you have a delay when a BLE event occurs, and don't handle it with the CyBLE_ProcessEvents() call within the BLE window/timeframe, then the BLESS will probably crash

0 Likes