Why do all ADI FreeRTOS examples and instructions include libssl even though the documentation explicitly warns against this?

The Release Notes for ADI FreeRTOS 1.4.0 say this.

As of the 1.3.1 release of the Analog Devices FreeRTOS product the pre-built versions of the System Services and Devices Driver libraries are no longer compatible with FreeRTOS for the ADSP-SC5xx and Blackfin BF7xx platforms. In order to use the System Services and Device Drivers the project must include the source versions of these libraries rather than linking against the pre-built versions of the libraries.

They also contain this big block warning circled in red.

Attempting to use the pre-built versions of the System Services and Device Driver libraries may result in application corruption and run time execution failure.

The User's Guide for ADI FreeRTOS has a section called "Using CrossCore Embedded Studio System Services and Device Drivers with FreeRTOS".  It has similar warnings to the above release notes and also provides a guide to avoid loading the default libraries for Device Drivers and System Services.

However, the instructions provided for both the ARM and Sharc only avoid loading the pre-built version of the Device Driver library (libdrv).  They provide no guidance on how to remove the pre-compiled System Services library (libssl).

Looking through the resulting map files of several different ADI-provided ARM examples, you can see many functions being pulled from libssl.  For example...

c:/analog devices/crosscore embedded studio 2.9.3/arm/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/sc589_rev_any_mt\libssl.a(adi_dma.o)
                              system/drivers/uart/adi_uart.o (adi_pdma_Open)
c:/analog devices/crosscore embedded studio 2.9.3/arm/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/sc589_rev_any_mt\libssl.a(adi_gic.o)
                              system/osal/ARM-Cortex-A/adi_osal_arch_c.o (adi_gic_SetIntPriority)
c:/analog devices/crosscore embedded studio 2.9.3/arm/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/sc589_rev_any_mt\libssl.a(adi_int.o)
                              system/drivers/uart/adi_uart.o (adi_int_InstallHandler)
c:/analog devices/crosscore embedded studio 2.9.3/arm/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/sc589_rev_any_mt\libssl.a(adi_pwr.o)
                              system/FreeRTOS/portable/io_startup.o (adi_pwr_Init)
c:/analog devices/crosscore embedded studio 2.9.3/arm/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/sc589_rev_any_mt\libssl.a(adi_tmr.o)
                              system/drivers/uart/adi_uart.o (adi_tmr_Open)

Now for a few of these (PWR, TMR, and DMA), there are services that can be added to the project that will create local virtual folders so that the code will be properly locally compiled, and will disappear from the above listing.  That still leaves adi_gic_SetIntPriority and adi_int_InstallHandler, neither of which have a listed Service Add-in.  (Both could probably be handled by a new service called INT that virtually linked in "services\Source\int\adi_int.c", I'm guessing.)

So I'd like some clarification from ADI.  Is it true that libssl is problematic for use with FreeRTOS?  If so, can an INT service and specs files and compiler flags be provided to avoid linking it?  If not, can the documentation be changed to reflect that libssl is not a problem?

If the answer is actually "yes and no", meaning some parts are dangerous, some aren't, please describe exactly what problem is being avoided here.  I tried to figure this out by examining the differences between 1.2.0, 1.3.0, 1.3.1, and 1.4.0, but there are so little real changes in the ADI provided code between these versions that I can't figure out the problem ADI is trying to avoid.  Most likely, there has always been a problem, but version 1.3.1 addressed it by not loading the default libdrv.

There must be some header file change or a macro definition change that affects the driver/service library code when compiling for FreeRTOS.  Can ADI tell us what that is?

Thanks for any info or discussion.



highlighted libssl
[edited by: dsmtoday at 5:26 PM (GMT -5) on 1 Dec 2020]
  • I'm interested in this too. I have spent today trying to get the GPIO driver to fire an interrupt. This works very easily in a project with no OS, but in a FreeRTOS project I have yet to get an interrupt to fire. I can see it latch in the  PINT0 registers, but no matter how I try to register and enable my handler, it never seems to be called.

    Thanks in advance for any comment or help.

  • 0
    •  Analog Employees 
    on Apr 14, 2021 2:59 PM

    Hi both,

    firstly apologies that we didn't respond sooner to this thread.

    I can shed some light on to what is going.

    The short of it is that you can use SSL/DD with FreeRTOS, but you will need to use the source based mode.

    History of the problem

    The SSL/DD library is provided in a few formats within CrossCore Embedded Studio. The sources are provided to allow users to rebuild the libraries. The pre-built libraries are also provided, and these are linked into your applications by default. There are two variants of the pre-built libraries – bare metal and multi-threaded.

    By default if you create a new FreeRTOS project it will link with the pre-built, multi-threaded variant of the libraries.

    We developed the multi-threaded libraries to be OS agnostic, meaning that the same libraries would work with multiple RTOS – uC/OS, FreeRTOS etc.
    However we identified an issue in the library that meant that using the pre-built DD libraries could result in run time crashes and exceptions.
    (If you are interested, there was a statically allocated block of memory used for mutual exclusion, but the space reserved wasn’t sufficient for FreeRTOS).

    The problem is encountered when using the drivers in libdrv. We have not encountered any issues with libssl.

    The current solution

    The current workaround for this issue is to ensure that you link against the source based version of SSL/DD. Instructions for how to achieve this are provided in the User Guide for ADI FreeRTOS (It’s in the docs folder in the zip file). You will need to be on a recent version of ADI FreeRTOS (1.4) and CrossCore Embedded Studio for this to work correctly.

    Improving the fix

    ADI are currently focusing on FreeRTOS as the RTOS of choice for our Blackfin, SHARC and ARM Cortex-A DSP solutions. Micrium’s uC/OS will not be supported going forward.
    As such, we can update the SSL/DD pre-built libraries to reserve sufficient space for FreeRTOS, and then you can thankfully return to using the pre-built libraries. This fix will be available in a future update later this year.

    Please let me know if you have any further questions.

    Regards,

    Dave

  • Thanks. Clear information is _always_ helpful, and explanation of the context very much so! So libssl itself is OK, but libdrv (as supplied) is broken. Instead of linking to libdrv we have to include source for any device drivers (eg adi_sport.c etc.), the recommended way of doing this being via the system.svc.

    CH