C030 boards fail new platform critical section test

[RobMeades]

Description

• Type: Bug
• Related issue: Test set for critical section #5201
• Priority: Blocker

Bug

Targets
UBLOX_C030_U201, UBLOX_C030_N211

Toolchain:
GCC_ARM

Toolchain version:
6.3.1 20170215

mbed-cli version:
1.2.0

mbed-os sha:
3c793a7

Expected behavior
Test mbed_platform-critical_section should pass on all platforms.

Actual behavior
The very first test fails (test_C_API() with N=1). The test sets up a Timeout, attaches a callback to this with a timeout value of 1 usecond, waits for 100 useconds and then tests that the callback has been called. In this case it hasn’t. If the timeout value is set to 3 useconds or higher (with the wait time fixed at 100 useconds) the test passes. All the UBLOX_C030_xxx boards use an STM32F437VG CPU so, for comparison, we've tried running the same test on a UBLOX_EVK_ODIN_W2 (which uses an STM32F439ZI) and a NUCLEO_F429ZI board. For an interesting data point, while doing this we measured the time it takes to run the attach_us() method:

    Timer t;
    t.start();
    timeout.attach_us(callback(tiemout_callback), timeout_time_us);
    int x = t.read_us();
    wait_us(wait_time_us);
    printf("*** x was %d.\n", x);

In the ODIN and NUCLEO cases it was 13 useconds while in the C030 case it was 9 useconds.

Both C030 and ODIN set a 168 MHz sysclock but C030 uses a 12 MHz crystal whereas ODIN uses an 8 MHz crystal. I’m not entirely sure what the NUCLEO board does by default but C030 is certainly running faster. I’ve tried adding a 1 second wait before the test runs (just to make sure that all clocks have settled) and that doesn’t help. My guess is that this is somehow a clock speed issue, though I don't understand why.

Steps to reproduce
Run mbed test on any UBLOX_C030_xxx board with GCC_ARM or ARM toolchains.

[RobMeades]

@adustm, @LMESTM, @jeromecoutant, @fahim-ublox, @andreaslarssonublox FYI.

[RobMeades]

Some poking around has shown that this test passes if #5677 (a brief instantiation of the I2C interface, called from HAL_MspInit(), to set up an external regulator on the C030 board) is reverted. I've no idea what the connection is since the test passes perfectly happily if you make exactly the same call (to set_minimum_battery_voltage()) on entry to main() instead. Probably @bqam-ublox needs to help debug this one.

[RobMeades]

A question for the experts (tagging @0xc0170): I believe the reason this is failing is because the target's i2c_read() and i2c_write() HAL functions make calls to wait_us(), an RTOS call, and the kernel is not initialised until after the call to HAL_MspInit(); is there a target-specific pre-main() hook inside mbed-os after the RTOS has been initialised that we could move our brief instantiation of I2C to? Hooking into mbed_main() rather than HAL_MspInit() seems to work but are we allowed to hook into that from way down here?

[RobMeades]

I have just done some experiments which make me wonder if this might be to do with C++ initialisation, or the lack of it. wait_us() resides in mbed_wait_api_rtos.cpp, a C++ file, and the HAP_MspInit() hook is before libc is initialised. Has the stuff that get_us_ticker_data() returns actually been initialised at this point?

[0xc0170]

#6117 fixes this issue