Post Go back to editing

[ARM] SC573 ARM core crashing when using rand()

Category: Software
Software Version: FreeRTOS 2.10.1

Context:

  • Using SC573 ezkit
  • Using FreeRTOS10.4.6 with CCES 2.10.1 ARM toolchain running on SC573 ARM core.
  • Using Clion rather than CCES IDE (pre-defined requirement)
  • Have migrated the FreeRTOS port provided in https://www.analog.com/en/design-center/evaluation-hardware-and-software/software/freertos.html#software-overview to Clion
    • FreeRTOS standard demo building and running successfully on SC573 ezkit
  • Using Cmake with ninja generator and ADI arm-none-eabi-gcc to build the bsp and application
  • Using ADI arm-none-eabi-gdb and OpenOCD for debugging (in Clion)
    • using the following cfg files for OpenOCD
      • source [find interface/ice1000.cfg]
      • source [find board/adspsc573_ezkit.cfg]
  • Using linker script provided by ADI for linker script
    • /opt/analog/cces/2.10.1/ARM/arm-none-eabi/arm-none-eabi/lib/ldscripts/adsp-sc573-l3.ld
    • let me know if I should be using adsp-sc573-l2.ld instead
  • Cmake flags 
    • -g
      -gdwarf-2
      -mcpu=cortex-a5
      -mabi=aapcs
      -mfloat-abi=hard
      -MMD # same as above but only uses user header files
      -MP # Emits dummy dependency rules
      -MF # specifies file name for the makefile dependency rule (MMD)
      -msi-revision=any #silicon revision
      -mproc=ADSP-SC573
      -D__ADI_FREERTOS #enables the freeRTOS version of osal functions, which are used by BSP libraries
      -DADI_DEBUG
      -mdebug-libs
      -lm
      -D__ADSP215xx__
      -DCORE0
      -Wl,--gc-sections -madi-threads -mdebug-libs -lm
      --specs=${CMAKE_CURRENT_LIST_DIR}/third_party/bsp/SC573/FreeRTOS/portable/ARM_CA5/freertos.specs
      -fdata-sections # Generates one ELF section for each variable
      -ffunction-sections # Generates one ELF section for each function

Problem

Currently trying to port LWIP over to FreeRTOS and am basing my port off a old port from CCES 2.8.3. I am experiencing a crash when I try and call LWIP_RAND() which is defined as rand(). I assume rand() is the function in arm-none-eabi/include/stdlib.h and is implemented in libc.a? I'm not sure why it would be causing a crash. Can you please have a look and let me know what I'm missing?

LWIP_RAND() is defined as rand()

Stack at time of crash

funcion where rand() is being used

disassmbly for rand()

disassembly for adi_rtl_get_tls_ptr: (only a snippet of it below)

disassembly for adi_fatal_error

Cheers,
Yan

  • Compiler tags
    -g
    -gdwarf-2
    -mcpu=cortex-a5
    -mabi=aapcs
    -mfloat-abi=hard
    -MMD # same as above but only uses user header files
    -MP # Emits dummy dependency rules
    -MF # specifies file name for the makefile dependency rule (MMD)
    -msi-revision=any #silicon revision
    -mproc=ADSP-SC573
    -D__ADI_FREERTOS #enables the freeRTOS version of osal functions, which are used by BSP libraries
    -DADI_DEBUG
    -mdebug-libs
    -lm
    -D__ADSP215xx__
    -DCORE0
    -Wl,--gc-sections -madi-threads -mdebug-libs -lm
    --specs=${CMAKE_CURRENT_LIST_DIR}/third_party/bsp/SC573/FreeRTOS/portable/ARM_CA5/freertos.specs
    -fdata-sections # Generates one ELF section for each variable
    -ffunction-sections # Generates one ELF section for each function
  • Turns out this flag "-madi-threads " messes things up, disabling that helped the crashing issue.

  • Hi,

    unfortunately this is not the correct solution as is likely to result in random crashes during execution.

    By removing the -madi-threads switch you are instructing the compiler to compile and link against artefacts that are not threadsafe. This means that there are no semaphores or mutex's in use within the system runtime libraries and SSL/DD.

    While this may make the error you saw go away, it means that there is a strong likelihood that competing threads may corrupt data within the runtime libraries, resulting in unexpected behaviour or a crash.

    Again, we strongly recommend that you use CrossCore Embedded Studio so we can support you with any issues.

    Dave

  • Hi Dave, thank you for your reply. 

    We'll try and duplicate the error in CCES and get back to you.