Need help regarding implementation of a library exactly like softdevice

[Vijay.kashid]

Hello, I am working on Bluetooth mesh application and i am using nRF52832/40 for the development purpose.

I wants to create one independent library with its own data section in RAM, where main application will interact with this library and may use its data variables.

As Nordics soft-device already working like an independent library, Can you please help us with the implementation of soft-device?
How to initialize the ram section independently before execution of main application?
How to access the data variables from RAM section allocated for library?

Is there any documentation regarding soft-device implementation??

[Marjeris Romero]

Hi,

What kind of library are you developing? Is there are a reason you don't want to implement a linkable library instead?

Best regards,

Marjeris

[Vijay.kashid]

Hi,

I want to implement a linkable library that should be accessible from the bootloader as well as application.

The library is nothing but a set of functions that utilizes UART functions present on nRF52 SDK.

Thanks and regards,
 Vijay

[tesc]

Hi,

I am afraid we cannot recommend to try to implement what you describe, or anything like it.

While it may be possible to write the equivalent of a dynamically linked library, you cannot do that the same way as we have written the SoftDevice. The reason is the SoftDevice acts in some respect as a light-weight operating system on the device, and you cannot have two such systems on the device at the same time. Note also that all interrupts go through the SoftDevice interrupt handlers and get redirected to the interrupt handlers of the application. (Hence slightly higher interrupt delays when using SoftDevice.) You would not want a shared library to also act as an interrupt vector table switchboard.

If you make a shared library, as a standalone build and separate from Bootloader, SoftDevice and Application, you no longer fit within the DFU Bootloader paradigm of having one SoftDevice, one Bootloader, and one Application. You introduce an extra unit, let's call it "Library", and you introduce dependencies from Bootloader to Library and from Application to Library. With that, you must rework the DFU Bootloader to handle those dependencies, to handle the additional type of DFU unit (the Library), and you must handle all possible edge cases that may arise.

If you want to call into an external application, you can use the Supervisor call interface. Before designing anything using supervisor calls you should have a thorough understanding of the SoC and understand what is meant in all the "Warning" sections in the Supervisor call interface documentation (see the above link).

If all you want is to use the same UART functions in application and bootloader, then a statically linked library (that gets linked into both application and bootloader) is extremely likely to be the best solution. I.e. you get slightly higher code flash usage (because it gets built into both bootloader and application), but you get much much much less complexity and it will be way way way easier to implement.

Regards,
Terje