Skip to content

Add tests for critical section HAL API #5789

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 26, 2018

Conversation

maciejbocianski
Copy link
Contributor

@maciejbocianski maciejbocianski commented Jan 4, 2018

Description

This PR contains critical section HAL API tests.
Test were created based on documentation provided in PR #5346

Status

READY

Migrations

NO

Notes

in order to run these tests #5346 has to be merged first,

Todos

  • adopt test for NRF5X series

@maciejbocianski
Copy link
Contributor Author

@scartmell-arm
as discussed it would be good to have hal_in_critical_section function to cover NRF5x like targets which mask application interrupts rather than disable all interrupts

@maciejbocianski maciejbocianski force-pushed the hal_critical_section_tests branch 3 times, most recently from cc5630d to 182dca7 Compare January 12, 2018 09:45
@maciejbocianski
Copy link
Contributor Author

support for NRF5x added

@maciejbocianski maciejbocianski force-pushed the hal_critical_section_tests branch 2 times, most recently from 92f0217 to f90759a Compare January 17, 2018 07:01
@maciejbocianski maciejbocianski force-pushed the hal_critical_section_tests branch 2 times, most recently from cdf8ff8 to 4560558 Compare January 19, 2018 07:26
{
// NRF5x targets don't disable interrupts when in critical section, instead they mask application interrupts this is due to BLE stack
// (BLE to be operational requires some interrupts to be always enabled)
#ifdef TARGET_NRF52_DK
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wasn't there somewhere a request for having function to check if interrupts are enabled? Or even an implementation?

Copy link
Contributor Author

@maciejbocianski maciejbocianski Jan 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indeed, there is function hal_in_critical_section(), but it would be nice to verify API functions by something form outside critical section API. us_ticker could be used to check interrupts but unfortunately it utilises core_util_critical_section_ (which also call HAL critical API ) and it brakes the test. Generly we should always use platform core_util_critical_section not HAL, in particular we cannot use both in the same time

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was concerned about the portability (how this function can grow in time).

Looks fine to test this here.

@0xc0170 0xc0170 requested a review from a user January 22, 2018 12:38
@0xc0170
Copy link
Contributor

0xc0170 commented Jan 22, 2018

/morph build

1 similar comment
@cmonr
Copy link
Contributor

cmonr commented Jan 22, 2018

/morph build

@mbed-ci
Copy link

mbed-ci commented Jan 22, 2018

Build : SUCCESS

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

Triggering tests

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

@cmonr
Copy link
Contributor

cmonr commented Jan 23, 2018

Jenkins didn't report abort.

/morph export-build

@mbed-ci
Copy link

mbed-ci commented Jan 23, 2018

@mbed-ci
Copy link

mbed-ci commented Jan 23, 2018

@maciejbocianski maciejbocianski force-pushed the hal_critical_section_tests branch from 4560558 to 628f521 Compare January 24, 2018 09:14
@maciejbocianski
Copy link
Contributor Author

maciejbocianski commented Jan 24, 2018

@scartmell-arm @0xc0170
I have added fix for masked interrupts check on NRF52

It turned out that none of interrupts handled by ISER/ICER[1] is actually enabled(used)
and (NVIC->ISER[1] & __NRF_NVIC_APP_IRQS_1) != 0 always returns false.

I modified the checking code from:

return (((NVIC->ISER[0] & __NRF_NVIC_APP_IRQS_0) != 0) 
           && ((NVIC->ISER[1] & __NRF_NVIC_APP_IRQS_1) != 0));

to:

return (((NVIC->ISER[0] & __NRF_NVIC_APP_IRQS_0) != 0) 
           || ((NVIC->ISER[1] & __NRF_NVIC_APP_IRQS_1) != 0));

Now we check __NRF_NVIC_APP_IRQS_1 only when __NRF_NVIC_APP_IRQS_0 are masked

@0xc0170
Copy link
Contributor

0xc0170 commented Jan 24, 2018

/morph build

@mbed-ci
Copy link

mbed-ci commented Jan 24, 2018

Build : SUCCESS

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

Triggering tests

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

@mbed-ci
Copy link

mbed-ci commented Jan 24, 2018

@0xc0170
Copy link
Contributor

0xc0170 commented Jan 25, 2018

/morph build

@mbed-ci
Copy link

mbed-ci commented Jan 25, 2018

Build : SUCCESS

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

Triggering tests

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

@mbed-ci
Copy link

mbed-ci commented Jan 25, 2018

@mbed-ci
Copy link

mbed-ci commented Jan 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants