drivers/flash/soc_flash_mcux.c
/*
 * Interrupt vectors could be executed from flash hence the need for locking.
 * The underlying MCUX driver takes care of copying the functions to SRAM.
 *
 * For more information, see the application note below on Read-While-Write
 * http://cache.freescale.com/files/32bit/doc/app_note/AN4695.pdf
 *
 */
Interrupt vectors could be executed from flash hence the need for locking.
The underlying MCUX driver takes care of copying the functions to SRAM.


Interrupt vectors could be executed from flash hence the need for locking . The underlying MCUX driver takes care of copying the functions to SRAM .
static int flash_mcux_erase(struct device *dev, off_t offset, size_t len)
{
	struct flash_priv *priv = dev->driver_data;
	u32_t addr;
	status_t rc;
	int key;
	addr = offset + priv->config.PFlashBlockBase;
	key = irq_lock();
	rc = FLASH_Erase(&priv->config, addr, len, kFLASH_ApiEraseKey);
	irq_unlock(key);
	return (rc == kStatus_Success) ? 0 : -EINVAL;
}
static int flash_mcux_erase ( struct device * dev , off_t offset , size_t len ) { struct flash_priv * priv = dev -> driver_data ; u32_t addr ; status_t rc ; int key ; addr = offset + priv -> config . PFlashBlockBase ; key = irq_lock ( ) ; rc = FLASH_Erase ( & priv -> config , addr , len , kFLASH_ApiEraseKey ) ; irq_unlock ( key ) ; return ( rc == kStatus_Success ) ? 0 : - EINVAL ; }
Interrupt vectors could be executed from flash hence the need for locking.
Interrupt vectors could be executed from flash hence the need for locking .