I am trying to write to the flash from a non-secure application via the fsl_iap driver. I therefore configured TrustZone and Secure AHB Controller so that the ROM_API_TREE is in non-secure memory. In the secure world, it is possible to call FLASH_Init() and then write to the flash. In the non-secure world, I get a Hardfault because of an SAU violation at address 0x13001100.
I think this is because ROM_API_TREE in fsl_iap.c is defined to
#define ROM_API_TREE ((uint32_t *)0x130010f0) // line 22 of fsl_iap.c
Which is secure memory, so assert(FLASH_API_TREE) fails, as FLASH_API_TREE points to ROM_API_TREE.
To test, I set ROM_API_TREE to non-secure memory:
#define ROM_API_TREE ((uint32_t *)0x030010f0)
Now the assert does not cause a hardfault anymore, but FLASH_API_TREE->flash_init(config); (line 136 of fsl_iap.c) does cause a hardfault. The SAU violation is now at a different address: 0x13001088. This address is before the actual ROM API.
The behaviour can be replicated easily with importing one of the TrustZone SDK examples, adding the fsl_iap driver, configuring the Secure AHB Controller to be non-secure (privileged) for the ROM area where the ROM_API_TREE is located and calling FLASH_Init(). From the secure project, this is possible, from the non-secure project, it fails.
In the user manual, I found:
"TrustZone disabled image is executed in normal mode and whole memory space is
configured as non-secure (except first 4kB of ROM). Thus, the ROM API can be used
without any limitation as on any LPC device without security extension."
This makes me think, that it should be possible to access the flash from non-secure memory also if the non-secure application runs after a secure application that configured SAU and Secure AHB Controller correct. Could you please clarify if and how it is possible to write to the flash from a non-secure application?