When creating a simple L562 uVision app, uVision produces an error message about not being able to copy system_stm32l5xx_ns.c file to the app.
The ST HAL library V1.4.0 includes Template files system_stm32l5xx.c, system_stm32l5xx_ns.c and system_stm32l5xx_s.c, I believe the _ns.c and _s.c versions are for a Trust Zone application and not needed for a non-trust application. DFP 1.4.0 contains only a system_stm32l5xx.c file.
Defaulting to copying system_stm32l5xx.c should be the first fix. Determining if the app is a Trust Zone application probably requires a Managing Run Time Environment change.
Of course, if I got something wrong, please politely explain the error of my ways.
Edit: Copying a system_stm32l5xx_ns.c file from ST's HAL L5 library to the app is not a good workaround. This will cause the startup to hang before reaching main. A workaround that seems to work is to delete the system_stm32l5xx_ns.c file from the app, replace it with a system_stm32l5xx.c file and rename it to system_stm32l5xx_ns.c. But, of course, that is a hell of a way to run a railroad.
The hangup occurs when adding a PUTCHAR_PROTOTYPE <stdio> printf functionality, The .ns.c flash does not start the load at the beginning of flash, which causes the startup to run to stdio code that hits a breakpoint,
ST MX has a solution that works - an option to set up a non-TrustZone application for stm32L562 that works for a printf application.