Hi Thomas,
I find out this reference:
https://github.com/ARM-software/CMSIS_5/issues/718.
As the page said, RTX osKernelInitialize()
is already called at the very early stage before C main(),
with Armclang and GCC toolchain. Therefore the ordering of
osKernelInitialize() and NS mailbox init doesnât matter in C
main() with Armclang or GCC toolchain.
IMO, the issue was caused by the incorrect
sequence of osKernelInitialize() and NS mailbox in the RTX
example (my bad
đ ). It is unnecessary to
adjust anything for IAR.
It is a RTX specific implementation.
Best regards,
Hu Ziji
Hmm, what
startup code does this for armclang and gnuarm?
I don't see anything obvious in startup_psoc64_ns.[sS] for
armclang or gnuarm.
If there's a difference, I'd like to fix it the same for IAR
too.
Cheers,
Thomas
Den 2021-03-01 kl. 06:52, skrev David Hu:
Hi Thomas,
It seems to be related to the startup
assembly code. It was reported by Alamy.
Dual-cpu NS mailbox relies on some RTOS
modules, which shall be initialized after RTX kernel starts.
Armclang and GNUARM startup assembly code already calls
kernel start function. Therefore the ordering of NS mailbox
init and RTX kernel init doesnât matter.
I guess IAR startup code doesnât call the
additional kernel start function.
This change has already included by the
tf-m-tests version specified in TF-M configuration. Could
you please update your TF-M version a bit?
Best regards,
Hu Ziji
It fixed a runtime problem with psoc64
when building with IAR.
I donât understand why ARMCLANG and
GNUARM builds seems to have been unaffected.