LPC1549 - Timer instantiation hardfaults

[ducky64]

Description of defect

Instantiate a Timer on LPC1549. Instant hardfault.

Timer initializes its _ticker_data with get_us_ticker_data(), but for non-USTICKER devices, this returns null. Then, in ticker_read_us (called from Timer::reset), it tries to access a field in that (null) ticker object, which (at least on the LPC1549) crashes (and presumably would do weird things on any non-USTICKER device).

For the 1549 in particular, this issue seems to go away (and the Timer works as expected) if either:

• USTICKER is added to targets.json
• or the ultimate hack patch, DEVICE_USTICKER is defined as a compilation flag

In general since (I think?) Timer is a pretty core mbed API, having a null pointer where uses aren't guarded seems to be living very dangerously. I'm actually pretty surprised that this hasn't been causing visible pain elsewhere...

Target(s) affected by this defect ?

LPC1549 (at least!)

Toolchain(s) (name and version) displaying this defect ?

GCC-ARM 9.2.1 (via PlatformIO)

What version of Mbed-os are you using (tag or sha) ?

5.15.6 (via PlatformIO)

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

PlatformIO latest

How is this defect reproduced ?

Instantiate a Timer on LPC1549. Instant hardfault.

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-3849

[0xc0170]

thanks for the report, we will review.

Looks like timing drivers should protect as USTICKER might not be present and NULL is a valid use case. I recall handling a target without us ticker (I always expected to have us ticker but there are targets like LPC1549 that do not have it enabled).

This is reported to 5.15 but the problem should be also on master.

[antonverburg]

Have the same issue here. If I force a define for DEVICE_USTICKER, it will work. Than the SCT3 timer will be used. But if you want to use that timer for other tasks, it will hard-fault again. Seems this issue is related to this: #10139