Change Details

I am integrating the latest version of upstream TF-M with Zephyr. It seems that when Zephyr locks IRQs (using BASEPRI_NS) psa_calls do not function properly. In particular, psa_connect returns an invalid (zero) handle, while psa_call() also seems to hang. To reproduce: It seems as simple as setting BASEPRI to 32, in the non-secure world. Lower values of BASEPRI allows the psa connect calls to function properly. This is strange because, to the best of my knowledge, TFM is setting AIRCR.PRIS=1 to de-prioritize non-secure interrupts, so setting NS BASEPRI to 32 should not mask any secure IRQs. Calling PSA API with IRQs locked was working with earlier versions of TF-M, so perhaps this has something to do with TFM features merged lately, e.g. the FLIH feature. Assigning Kevin to take a look. If, indeed, it should not be possible for PSA calls to proceed with NS IRQs being locked, this deserves a documentation edit, IMHO.

I am integrating the latest version of upstream TF-M with Zephyr. It seems that when Zephyr locks IRQs (using BASEPRI_NS) psa_calls do not function properly. In particular, psa_connect returns an invalid (zero) handle, while psa_call() also seems to hang. To reproduce: It seems as simple as setting BASEPRI to 32, in the non-secure world. Higher values of BASEPRI allows the psa connect calls to function properly. This is strange because, to the best of my knowledge, TFM is setting AIRCR.PRIS=1 to de-prioritize non-secure interrupts, so setting NS BASEPRI to 32 should not mask any secure IRQs. Calling PSA API with IRQs locked was working with earlier versions of TF-M, so perhaps this has something to do with TFM features merged lately, e.g. the FLIH feature. Assigning Kevin to take a look. If, indeed, it should not be possible for PSA calls to proceed with NS IRQs being locked, this deserves a documentation edit, IMHO.

I am integrating the latest version of upstream TF-M with Zephyr. It seems that when Zephyr locks IRQs (using BASEPRI_NS) psa_calls do not function properly. In particular, psa_connect returns an invalid (zero) handle, while psa_call() also seems to hang. To reproduce: It seems as simple as setting BASEPRI to 32, in the non-secure world. LowerHigher values of BASEPRI allows the psa connect calls to function properly. This is strange because, to the best of my knowledge, TFM is setting AIRCR.PRIS=1 to de-prioritize non-secure interrupts, so setting NS BASEPRI to 32 should not mask any secure IRQs. Calling PSA API with IRQs locked was working with earlier versions of TF-M, so perhaps this has something to do with TFM features merged lately, e.g. the FLIH feature. Assigning Kevin to take a look. If, indeed, it should not be possible for PSA calls to proceed with NS IRQs being locked, this deserves a documentation edit, IMHO.