This shouldn't break, is my BLE unstable?

RE: This shouldn't break, is my BLE unstable?

Michael0123456 — Mon, 03 Aug 2026 21:15:23 GMT

I'm sorry, this was dumb.

I wasn't the one who changed this code "buttons_leds_init(&erase_bonds)". I thought this was just a matter of removing hardware that exists in the development board and doesn't exist in the hardware I'm using. But now I see it is leaving erase_bonds uninitialized.

Turbo_J had this exactly right but I didn't read that paragraph carefully. Sorry about that.

Sorry for the waste of time.

int main(void)
{
bool erase_bonds;
// int i;

sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);
nrf_power_dcdcen_set(true);

// Initialize.
log_init();
timers_init();
// buttons_leds_init(&erase_bonds);
power_management_init();
ble_stack_init();
scheduler_init();
gap_params_init();
gatt_init();
advertising_init();

RE: This shouldn't break, is my BLE unstable?

Michael0123456 — Mon, 03 Aug 2026 07:46:17 GMT

These are some good ideas, but at this point I'm thinking it is just the way the advertising works (or doesn't).

I was trying to measure delays around the logging and found that at the exact point in the code I'm doing that logging, clocks are starting up.That in and of itself is weird because I would think a lot of stuff that the code is starting up is going to be using clocking, and so there ought to be a point where everybody knows the clocks are working, and not try to use them before they are. But anyway, while I was doing that I noticed I was getting some different messages from the advertising code, depending on changes in the amount of delay from the logging.

That seems wrong to me. And it also seems wrong that the code can easily go into an advertising mode where Windows ignores it. But obviously I didn't have any say in how the advertising was written, and I don't know anything about how to advertise "properly" for Windows. (I admit, I was hoping to learn that from code in the SDK, but people in hell want ice water...)

I did notice that advertising_start() runs right after the logging I'm doing. So my strong suspicion is that one or more threads that are started because of the logging are affecting the way the advertising starts up. (And probably shouldn't, but, you know, bugs and stuff. Like, is the clock running? Sure, I think so, we need to create some known delays here, etc.)

I certainly don't suspect stack overflow or any other kind of corruption. There are no error messages, no indication of a crash. All the code I'm involved with at this point does what I expect without complaint (mostly a heartbeat into the log in the case where I can't connect it, but I think the advertising changes to slow after a while like it normally does). The only symptom I know of at this point is it doesn't show up in Windows as a device to connect to. And as I said, I think there are some changes to what the log says about the advertising. But I'm just barely starting to look at that. I think I read much of the Bluetooth is actually in the "Soft Device" code and I have no idea how to get logging from that. (I generally can't even find the code that might be running.) The first thing I have to figure out is what it does when it works. Then figure out why it is doing something different.

I'm sure there is another issue with the advertising and connection because when I reboot the device (after having it connected, when it works) it shows in Windows as toggling back and forth between connected and paired. (My assumption is it would either connect without any intervention, or it would wait for me to connect it, not crash in this way where I have to disconnect it and then reboot it again.) So I know there is work to do there.

You mentioned erase_bonds. I don't see any indication of a problem. But I can only say I started from the SDK. I don't know what is correct other than that. Anyway, there are zero compile time warnings. And zero run time errors reported that seem to have anything to do with the issue. (Like I say, sometimes it puts up a message if I halt it from the JLink.) I admit, I don't know what would be logged by this code at this point, since I haven't seen any of the messages of the type we might hope for.

Anyway, thanks for your time and thoughts.

PS. As far as the string constants. Note that the whole point of the code I wrote initially was that there was one string and I logged it from within a loop. If that by itself was a problem it would be a problem when I run the loop one time. And it isn't a problem then. It is only a problem when I run the loop two or more times. (Or, I should say, I only see the problem. I can't say that the code that is breaking is working reliably with any logging code including what I checked out of GitLab, just that I see it work regularly.) Changing the loop count limit definitely doesn't take any more space in any memory, stack or otherwise. The "lazy" code just cuts and pastes the log statement with the string in it. I suspect the compiler wouldn't notice the string is reusable, so it WOULD exist in memory multiple times. In later testing I also got a change in behavior by doing the lazy cut and paste, which brought me to this post. Not to mention this code probably uses a tiny fraction of the stack available to it. At least I hope so, since it isn't really doing anything yet, and does as close to nothing as it ever would before it is connected.

That said, it probably is a good explanation for how the changes would be changing the delays of the logging executing. If the string is in ROM or RAM, for example. (Although I kind of feel like given the code that is there, I should be able to insert any delay I want there and it should still work, no?)

RE: This shouldn't break, is my BLE unstable?

Turbo J — Sun, 02 Aug 2026 07:22:37 GMT

Its probably just a stack overflow.

I believe all those string constants will end up on the stack - they are not declared const. And the old SDK has zero stack overflow handling - overflowing stack can silently corrupt (overwrite) other data.

There is a reason why we don't recommend this for new designs.

Another cause could be RTT. By default is set up to throw away log messages when they don't fit in the log buffers, but you might have changed that in the past and forgot about it.

Does the compiler moan about erase_bonds? I don't see an initial value for this variable. Bond erasing behaviour could be random across compiler runs here.

RE: This shouldn't break, is my BLE unstable?

Michael0123456 — Sun, 02 Aug 2026 00:46:59 GMT

Also, I'm fully aware that the answer might be, this is old code and not really supported. But at least if that is the answer, I would like to see it. And it would be good to hear that this problem has surely been fixed in later BLE code.

RE: This shouldn't break, is my BLE unstable?

Michael0123456 — Sun, 02 Aug 2026 00:42:02 GMT

The AI answer makes sense. Sending a pointer (potentially to RAM) into the logging system can affect its behavior. Sure. But I'd like my code to be fixed, not just accidentally run.

If there is a critical timing relationship among the initialization calls in my main, why is there no information about it in the initialization code? How come I can log the string 8 times with the literal in the macro but not even twice with an actual pointer. I CAN log it once with the regular pointer, so that by itself is apparently not a problem. How much delay can be tolerated? What if I have some other high priority initialization going on that causes delay? (And the logging always works, it is the BLE that breaks. That makes me think the problem is in the BLE code.)

EDIT: I forgot about the case where I'm logging with the regular pointer, but I make calls each on their own line, and it works. Even if I log the line 8 times! What I can't do is log from within a loop (unless the loop only runs once). It is a true mystery...