There have been previous tickets about bsd_init() not working with trace_on=false, but the support team said it had been fixed in 0.7.x. However, it's still failing for me in 0.8.1. bsdlib_init() returns -1. I've also seen a separate issue where the AT socket creation gets a return value of -117, which I'll get to below.
Are there still known issues with this? Apparently even with trace_on=true, bsd_init() is fine with bsd_memory_size=BSD_RESERVED_MEMORY_SIZE_TRACE_DISABLED, which is interesting. In fact, I can give it a size of bsd_memory_size=0 and it will still work!
I've also found if I use a size of, say, 0xb000 -- which is between the trace enabled and trace disabled sizes in bsd_platform.h -- bsd_init() will successfully run, but if I used 0xc000 it will fail, even though that's also between the two sizes. I can also go under the smaller size with 0x8000, and it will still successfully run. Is there any documentation on exactly how the sizes affect the BSD library's ability to initialize itself? bsd_init() must be doing some interesting math to validate the size if 0 will succeed but 0xc000 fails.
Another interesting thing I've found is that if I change our internal Devicetree RAM partition for the BSD RAM -- and nothing else -- I can have bsd_init() succeed or fail:
sram0_bsd: memory@0x20000000 {
reg = <0x20000000 DT_SIZE_K(49)>;
compatible = "mmio-sram";
};
That will successfully run. However, if I simply change the Devicetree output such that the reserved space is at least 0x8020:
sram0_bsd: memory@0x20000000 {
reg = <0x20000000 DT_SIZE_K(33)>;
compatible = "mmio-sram";
};
that will fail, even though I'm using the 0x8020 size during bsd_init() and no application code RAM allocations or usage have changed. In this case, it will give a success for bsd_init() but will give a failure for allocating the AT socket with an error code of -117 (which doesn't seem to be defined in any nRF errno.h files). The exact cutoff for when it starts to work is around DT_SIZE_K(41).
I'm not yet sure if Zephyr's initialization system will automatically clear all mmio-sram sections during boot or something, but that's the only thing I've been able to think of that would change between the two Devicetree setups. Does bsd_init() and/or socket() throw an error if the RAM it allocates isn't cleared out or something? I could see that combined with it ignoring bsd_memory_size leading to that behavior.
