Skip to main content
Ricardo Hassan
Ricardo Hassan
Associate III
August 3, 2017
Solved

STM32L4 hard faulting in BlueNRG stack

  • August 3, 2017
  • 1 reply
  • 610 views
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

    This topic has been closed for replies.
    Best answer by Ricardo Hassan
    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

    1 reply

    Ricardo Hassan
    Ricardo HassanAuthorBest answer
    Associate III
    August 31, 2017
    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

    Terms & ConditionsAccessibility statement