This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Not able to modify advertisement packet more than once, (without adv_timeout) on interrupt

Hi All,

My goal is to change the advertisement(when not "connected" to ble device) in every SPI Interrupt, depending on the data received i set corresponding data in advertisement packet. The small code snippet that I'm using, is given below.

spi_event_handler : ################################################################################ if (m_rx_buf[0]=='o') { if(connect) err_code = ble_nus_send_string(&m_nus, open_door_str, 10); else { open_door = 1; //sd_ble_gap_adv_stop(); open_door_adv_init(); advertising_start(); } } if (m_rx_buf[0]=='c') { if(connect) err_code = ble_nus_send_string(&m_nus, close_door_str, 10); else { close_door =1; close_door_adv_init(); advertising_start(); } } ########################################################################### The issue that i face here is i am able to change the advertisement packet on first interrupt, but advertisement packet doesn't change afterwards for later interrupts. But i need to change adv_data multiple times. I'm able to change the advertisement packet every time if i wait for adv_timeout. Although, when connected all the messages are sent regularly on every interrupt.

Can anyone please suggest me what's wrong with my method or above code snippet. Any suggestions or help would be appreciated.

Thanks Brajesh

  • Hi,

    What are you seeing when you try this? Does the device continue to advertise, but never change the data? Could you try putting a breakpoint/log output in the two adv_init() sections to see if they're actually called? It could be that the "connect" variable isn't set to volatile, and that it changes during the SPI-interrupt for instance.

    The advertising data will also not be updated until the current advertising event is finished, i.e. the advertisement has gone out on all the configured channels (default 37, 38, 39). So if you change it extremely fast, the advertised data might lag behind a bit.

  • Thanks Myhre for the response.

    Device continues to advertise the last changed advertisement data but doesn't change further. And I think I'm not changing the data very fast, the time difference varies, but i'm sure it's not the issue cause with the same speed, ble_send_string works (when connected).

    And about "connect" variable, when i don't have that condition itself, I face the same issue (I directly change the data without any if else statements.)

  • Thanks Myhre for the response.

    Device continues to advertise the last changed advertisement data but doesn't change further. And I think I'm not changing the data very fast, the time difference varies, but i'm sure it's not the issue cause with the same speed, ble_send_string works (when connected).

    And about "connect" variable, when i don't have that condition itself, I face the same issue (I directly change the data without any if else statements.)

  • I have some hardware limitations so it'll be difficult for me to put breakpoints and debug. But i have checked using some debug prints, that after changing the advertisement once, it doesn't come inside the spi handler further, which means it doesn't do anything else except advertising after modifying the adv packet once. I can't see why it happens, please give your comments on the same.

  • Sounds, given this comment in your comments,

    "it doesn't come inside the spi handler further"

    that this has nothing whatsoever to do with advertising, it sounds to me that you only enter the above piece of code once, with either 'c' or 'o' as the first character, change the advertising and then either you never read another character, or every one you read is the same as before and so you change the advertising to be exactly the same each time.

    You need to go work out why your spi handler doesn't get called again.

Related