NUC472/M453/M487/NANO130: Add updates for Nuvoton targets

[ccli8]

Description

This PR includes the following updates:

1. Fix ethernet multi-function pin configuration error (NUC472/M487).
2. Fix RTC hour error with AM/PM (NUC472/M453/M487/NANO130).
3. Move target configuration from mbed_lib.json to targets.json (NANO130).
4. Fix lp_ticker wake-up is incorrectly disabled (NANO130).
5. Other minor fixes.

[0xc0170]

Changes look fine to me.

One question:

• Refine sleep code - serial/spi/i2c - fine, but what about pwm, is not required by these targets to have it there?

[ccli8]

Refine sleep code - serial/spi/i2c - fine, but what about pwm, is not required by these targets to have it there?

@0xc0170 I re-clean dead power-down code thoroughly. Please check bf426b0.

[0xc0170]

@0xc0170 I re-clean dead power-down code thoroughly. Please check bf426b0.

I see. My question was about pwm and deepsleep. It used to disallow deep sleep if pwm was used, with this clean up it can happen PWMOut object is active and it goes to deepsleep, or is not the case?

[ccli8]

I see. My question was about pwm and deepsleep. It used to disallow deep sleep if pwm was used, with this clean up it can happen PWMOut object is active and it goes to deepsleep, or is not the case?

@0xc0170 Yes, you are right. But I am not sure if deep sleep is locked when there is any PWMOut object active per HAL spec. I suppose it would be addressed in upper layer (PWMOut and sleep manager) in an organized way.

[0xc0170]

@0xc0170 Yes, you are right. But I am not sure if deep sleep is locked when there is any PWMOut object active per HAL spec. I suppose it would be addressed in upper layer (PWMOut and sleep manager) in an organized way.

At the moment, it is not (PWMout does not lock deepsleep). I would propose to keep it as it was for backward compatibilty (target would handle it). What do you think?

A question - what clocks depend your PWM module on?

cc @c1728p9

[ccli8]

At the moment, it is not (PWMout does not lock deepsleep). I would propose to keep it as it was for backward compatibilty (target would handle it). What do you think?

@0xc0170 Do you mean I can call sleep_manager_lock_deep_sleep() to lock deep sleep when there is any PwmOut object active? If so, there is another issue. I find there is only pwmout_init() in PwmOut ctor but no pwmout_free() in PwmOut dtor (no explicit dtor defined), and I cannot judge to unlock deep sleep with sleep_manager_unlock_deep_sleep().

A question - what clocks depend your PWM module on?

Current PWM HAL implementation relies on HIRC, which would stop as system enters deep sleep mode.

[c1728p9]

@0xc0170 I would expect PWM to use a high frequency clock (and thus lock deep sleep).

[0xc0170]

@0xc0170 I would expect PWM to use a high frequency clock (and thus lock deep sleep).

👍 thus we need to fix it

[0xc0170]

Fixed proposed, please review

[ccli8]

@0xc0170 As #5177 has addressed deep sleep lock in PwmOut class, I needn't do it in PWM HAL.

[0xc0170]

/morph test-nightly

[mbed-bot]

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1444

Test failed!

[0xc0170]

/morph test-nightly

[mbed-bot]

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1494

Test failed!

[0xc0170]

The last run was with Ticker test that we fixed in the meantime, I am retriggering CI

[0xc0170]

/morph test-nightly

[mbed-bot]

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1526

All builds and test passed!