platform timer: Call timer start in enable

[JarkkoPaso]

This timer was never started and therefore read_us returned always 0 causing bad timings.

Description

This timer was never started and therefore read_us returned always 0 causing bad timings.

Tested with K64F and Nucleo-F429ZI

Pull request type

[x ] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Breaking change

[kjbracey]

Um. Seriously? I guess no-one was ever relying on this in the absence of frequency-hopping?

Yikes.

Anyway, if you're doing timer->start(), don't need the "dummy" timer.get(), so remove that line.

[kjbracey]

Oh, and maybe put the "prime" comment above just the remaining timeout.get, as it's about that dummy get. timer->start() is inherently obvious.

But apparently not obvious enough for me to put in the code in the first place. Sigh.

[JarkkoPaso]

@kjbracey-arm I guess, even without frequency hopping it caused some issues with MAC timer. Too short Ack wait durations caused MAC retransmissions etc. Please check the changes I made.

[TuomoHautamaki]

@0xc0170 can you please initialise CI for this PR.

Thanks,
Tuomo

[0xc0170]

I can build it soon (there are two jobs in the queue now) but exporters are having an issue currently, we are investigating.

[cmonr]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 3280
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8210/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 2905
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/8210/

[mbed-ci]

Test : SUCCESS

Build number : 3088
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/8210/3088