[toolchain] Mac clean builds failing on arm 4.9.3; linker can't find _gettimeofday [solved]

Firmware
1

  1. I was building successfully for Photon on the 'develop' branch on Mac/OSX. With a recent pull, I now receive a notice to switch to the 'latest' branch. [BTW, to keep developing on 'experimental' add PARTICLE_DEVELOP=1 to your make command line or environment variables, as described here.

  2. However, whether on latest or develop, I'm now seeing:

$ make v=1 PLATFORM=photon PARTICLE_DEVELOP=1 APP=myprog clean all program-dfu
...
*** "ARM gcc version 4.9.3 20150529 or later required, but found 4.9.3 20150303 (release)

  1. But if I switch to the 0529 version of arm-none-eabi, the clean build fails on linking with:

/Users/[...]/gcc-arm-none-eabi-4_9-2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7-m/libg_nano.a(lib_a-gettimeofdayr.o): In function _gettimeofday_r': gettimeofdayr.c:(.text._gettimeofday_r+0xe): undefined reference to _gettimeofday'

How do I fix this?

To install gcc-arm-none-eabi-4_9, I downloaded it from here, then added its bin directory to my path.

2

Fixed. What I think is happening is that the gcc-arm-none-eabi compiler is intended for embedded systems, so its standard libraries don’t include all of the common functions. One of the functions missing is gettimeofday. I had an indirect dependency in my code here:

  srand(time(NULL));

Changing it to

  srand(millis());

solved the problem.

1 Like
3

If you are doing that in setup you may not be seeding the random number generator with different values. As millis() is time since power on, and that may be nearly the same, maybe even exactly the same, every time you start the hardware.

4

In case you’re not aware, the random number generator is seeded once the cloud is connected. And there is uint32_t HAL_RNG_GetRandomNumber(void); to retrieve a random number from the STM32 chip.

5

@rvnash, great point. Better would be micros(), although it would have the same problem: The time since startup is probably deterministic and consistent enough that time is a poor seed.

@mdma, I’m running offline, so HAL_RNG_GetRandomNumber is great!

It looks like the HAL_RNG_GetRandomNumber documentation is already configured for us in hal/src/stm32f2xx/core_hal_stm32f2xx.c. Then we can see its code in hal/src/stm32f2xx/rng_hal.c, where it wraps functions defined in platform/MCU/STM32F2xx/STM32_StdPeriph_Driver/src/stm32f2xx_rng.c.

Thanks!