rtl8195am : fix greentea test fails (test_timeout & test_timerevent)

[M-ichae-l]

Description

Two greentea tests have the same issues.

• Test-timeout, case ”Zero delay (attach)" and case” Zero delay (attach_us)”
  This issue is metioned in issue Zero delay (attach) test fails for REALTEK_RTL8195AM #6410 .
• Test-timerevent, case "Test insert_absolute zero" and case "Test insert_absolute timestamp from the past”.

RTL8195AM has a hardware limitation which is 30.5 us per tick for us_ticker. When execute these tests, it is necessary to wait at least two whole tick, 62 us.

Both of the tests, are using Semaphore to release() attach callback with 0 delay and wait() with 0 delay, then compare the sem_slots. However, when apply the attach callback, the ticker is being used (https://docs.mbed.com/docs/mbed-os-api-reference/en/latest/APIs/tasks/Ticker/) and this is linked to the ticker hardware limitation.

Pull request type

[X] Fix

[cmonr]

@M-ichae-l Thank you for looking into the issue and the technical explanation.

We'll run morph test a couple of times since the issue is intermittent.

/morph build

[mbed-ci]

Build : SUCCESS

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

Triggering tests

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

[mbed-ci]

Test : FAILURE

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

[mbed-ci]

Exporter Build : SUCCESS

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

[0xc0170]

@M-ichae-l Thanks for the fix, I got one concern with the fix - tests should not contain ifdef targets (some code is not run for some), can this fix be made more generic? It can be applied to any other targets? If the ifdef is removed, will be test still valid and should pass for any hw ticker?

@fkjagodzinski Can you please review?

[M-ichae-l]

Hi, @0xc0170
The reason why I put the ifdef condition is to ensure that other targets are not affected. If you feel that the added delay is acceptable then the change can be made universal. Other targets should have different timing per tick, They may have different fixs or even not necessary to have a fix.

[0xc0170]

The reason why I put the ifdef condition is to ensure that other targets are not affected. If you feel that the added delay is acceptable then the change can be made universal. Other targets should have different timing per tick, They may have different fixs or even not necessary to have a fix.

If that is needed , should be done for all targets. Firstly, why is this actually needed ? Can't this be handled in the target implementation (the test stays as it is, target HAL for ticker needs an update?) ?

Generally, test is generic, no "ifdef targets". The problem often is somewhere else than in the test if this is needed

[fkjagodzinski]

I suppose the us_ticker_fire_interrupt() implementation for RTL8195AM needs an update to pass these tests. Similar issue was raised for other targets. For reference see issue #6319 or NRF51 implementation which uses NVIC_SetPendingIRQ() to overcome similar 2 tick limitation.

mbed-os/targets/TARGET_NORDIC/TARGET_NRF5/us_ticker.c

Lines 281 to 287 in c8bd08f

	void us_ticker_fire_interrupt(void)
	{
	core_util_critical_section_enter();
	m_common_sw_irq_flag |= US_TICKER_SW_IRQ_MASK;
	NVIC_SetPendingIRQ(RTC1_IRQn);
	core_util_critical_section_exit();
	}

[0xc0170]

@M-ichae-l Did @fkjagodzinski answer it ? Can you update the tickers implementation?

[M-ichae-l]

I have tried the NVIC_SetPendingIRQ() implementation. This is not able to overcome the issue.

[0xc0170]

RTL8195AM has a hardware limitation which is 31.5 us per tick for us_ticker. When execute these tests, it is necessary to wait at least two whole tick, 62 us.

What peripheral is used there? No other peripheral is available that would do the trick? where is this 31.5 us coming from? Can you describe the problem in detail.

We shall find another solution to the problem, wait() does not solve it as it is presented here.

[M-ichae-l]

Hi, @0xc0170
Sorry for the late reply. Peripheral G-timer is used and there is no other peripheral available. The ticker has us per tick: 30.5. G-timer needs at least 2 ticks (~62us) to trigger the interrupt which is too long. One tick is for load the counter the other is for issue the IRQ.
I will follow up the #6536. Thank you!

[cmonr]

@M-ichae-l Now that #6536 is in, how does it affect this PR?

[cmonr]

Closing since #6536 appears to have solved the problem in a generic way and no response has been given in this PR.

[studavekar]

Closing since #6536 appears to have solved the problem in a generic way and no response has been given in this PR.

@cmonr looks like on master test-timerevent, case "Test insert_absolute zero" and case "Test insert_absolute timestamp from the past”. still fails.