Open ducky64 opened 3 years ago
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
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.
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: https://github.com/ARMmbed/mbed-os/issues/10139
Description of defect
Instantiate a Timer on LPC1549. Instant hardfault.
Timer initializes its
_ticker_data
withget_us_ticker_data()
, but for non-USTICKER devices, this returns null. Then, inticker_read_us
(called fromTimer::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.jsonDEVICE_USTICKER
is defined as a compilation flagIn 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.