Hi Thomas, Ken,
Also note that there is a hardware bug in
Musca-B1 and Musca-S1 that prevents unprivileged access to APB
Expansion peripherals (such as the UART). See
https://developer.arm.com/documentation/101835/0000/Hardware-bug-software-workaround/S1-Secure-and-Non-secure-privilege-registers-hardware-bug
As far as I know the workaround in the
above doc is not implemented in TF-M. It may be a good idea to
add it though.
So if you find that CONTROL.npriv is set to
1 (unprivileged) when executing the IAR build, but set to 0 at
the same point in the GCC build, then you are running into
this bug. Aligning the privilege levels between IAR and GCC
builds would avoid it.
Kind regards,
Jamie
Compare the SAU/MPU
(PPC?) regions and the polling CONTRO.nPRIV may show up the
problem.
This looks like the
current program does not have the permission to access the
register, but the protection unit does not return an
exception and just access as nop.
Is it work under AN521?
If so I can have a try locally.
/Ken
I'm working on adding IARARM as a toolchain for
the Musca S1 (and B1) and I'm running into an issue where
the NS image can not properly access the UART.
The NS code loops trying to check the UART status
@0x40102030, which holds the value 0x301, as can be seen
with the debugger and also from the secure code, but when
read by the NS code it returns 0, with no error.
As this code works when building with ARMCLANG and GNUARM, I
assume there is some memory protection that gets incorrectly
setup when I build with the IAR toolchain, but I'm
struggling to find where this gets setup. I assume it is
done in the secure image.
Any hints where i should be looking?
Thanks,
Thomas