cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L4 hard faulting in BlueNRG stack

Ricardo Hassan
Associate III
Posted on August 03, 2017 at 20:25

Hi,

   I am building an application using an STM32L4 and a BLUENRG-MS.  I have an GATT server application that can happily connect and ping pong messages with a GATT client.  The client sends a ping on one characteristic, and my application sends a response on a different characteristic by doing a characteristic update.  After a while it seems that something changes on the client, and the characteristic update call leads to a hard fault on the STM32L4, while it is deep within the BlueNRG stack.  Can someone tell me what is happening?  Is there a way to tell if a characteristic is ready to be updated before actually doing so?  Is there a known issue in the BlueNRG stack that leads to hard faults?

Ricardo

1 ACCEPTED SOLUTION

Accepted Solutions
Ricardo Hassan
Associate III
Posted on August 31, 2017 at 16:29

I'm posting this as a reference, because this was not easy for me to figure out.  The problem was I was trying to send data on one characteristic in the attribute modified event handler for another.  The stack does not tolerate this, and tries to dereference a null pointer as it's removing a node from it's internal linked list.  It would be nice if the stack was more robust to such a thing, and I suggest that STM improve this in the next stack release.   My solution was to make sure that I used a different thread to do the characteristic update, and everything worked fine.  HTH.

Ricardo

View solution in original post

1 REPLY 1
Ricardo Hassan
Associate III
Posted on August 31, 2017 at 16:29

I'm posting this as a reference, because this was not easy for me to figure out.  The problem was I was trying to send data on one characteristic in the attribute modified event handler for another.  The stack does not tolerate this, and tries to dereference a null pointer as it's removing a node from it's internal linked list.  It would be nice if the stack was more robust to such a thing, and I suggest that STM improve this in the next stack release.   My solution was to make sure that I used a different thread to do the characteristic update, and everything worked fine.  HTH.

Ricardo