Important changes to repositories hosted on mbed.com
Mbed hosted mercurial repositories are deprecated and are due to be permanently deleted in July 2026.
To keep a copy of this software download the repository Zip archive or clone locally using Mercurial.
It is also possible to export all your personal repositories from the account settings page.
Dependents: WizFi250_AP_HelloWorld
Fork of mbed-src by
vendor/NXP/LPC11U24/cmsis/cmsis_nvic.c@10:3bc89ef62ce7, 2013-06-14 (annotated)
- Committer:
 - emilmont
 - Date:
 - Fri Jun 14 17:49:17 2013 +0100
 - Revision:
 - 10:3bc89ef62ce7
 
Unify mbed library sources
Who changed what in which revision?
| User | Revision | Line number | New contents of line | 
|---|---|---|---|
| emilmont | 10:3bc89ef62ce7 | 1 | /* mbed Microcontroller Library - cmsis_nvic for LPC11U24 | 
| emilmont | 10:3bc89ef62ce7 | 2 | * Copyright (c) 2011 ARM Limited. All rights reserved. | 
| emilmont | 10:3bc89ef62ce7 | 3 | * | 
| emilmont | 10:3bc89ef62ce7 | 4 | * CMSIS-style functionality to support dynamic vectors | 
| emilmont | 10:3bc89ef62ce7 | 5 | */ | 
| emilmont | 10:3bc89ef62ce7 | 6 | |
| emilmont | 10:3bc89ef62ce7 | 7 | #include "cmsis_nvic.h" | 
| emilmont | 10:3bc89ef62ce7 | 8 | |
| emilmont | 10:3bc89ef62ce7 | 9 | /* In the M0, there is no VTOR. In the LPC range such as the LPC11U, | 
| emilmont | 10:3bc89ef62ce7 | 10 | * whilst the vector table may only be something like 48 entries (192 bytes, 0xC0), | 
| emilmont | 10:3bc89ef62ce7 | 11 | * the SYSMEMREMAP register actually remaps the memory from 0x10000000-0x100001FF | 
| emilmont | 10:3bc89ef62ce7 | 12 | * to adress 0x0-0x1FF. In this case, RAM can be addressed at both 0x10000000 and 0x0 | 
| emilmont | 10:3bc89ef62ce7 | 13 | * | 
| emilmont | 10:3bc89ef62ce7 | 14 | * If we just copy the vectors to RAM and switch the SYSMEMMAP, any accesses to FLASH | 
| emilmont | 10:3bc89ef62ce7 | 15 | * above the vector table before 0x200 will actually go to RAM. So we need to provide | 
| emilmont | 10:3bc89ef62ce7 | 16 | * a solution where the compiler gets the right results based on the memory map | 
| emilmont | 10:3bc89ef62ce7 | 17 | * | 
| emilmont | 10:3bc89ef62ce7 | 18 | * Option 1 - We allocate and copy 0x200 of RAM rather than just the table | 
| emilmont | 10:3bc89ef62ce7 | 19 | * - const data and instructions before 0x200 will be copied to and fetched/exec from RAM | 
| emilmont | 10:3bc89ef62ce7 | 20 | * - RAM overhead: 0x200 - 0xC0 = 320 bytes, FLASH overhead: 0 | 
| emilmont | 10:3bc89ef62ce7 | 21 | * | 
| emilmont | 10:3bc89ef62ce7 | 22 | * Option 2 - We pad the flash to 0x200 to ensure the compiler doesn't allocate anything there | 
| emilmont | 10:3bc89ef62ce7 | 23 | * - No flash accesses will go to ram, as there will be nothing there | 
| emilmont | 10:3bc89ef62ce7 | 24 | * - RAM only needs to be allocated for the vectors, as all other ram addresses are normal | 
| emilmont | 10:3bc89ef62ce7 | 25 | * - RAM overhead: 0, FLASH overhead: 320 bytes | 
| emilmont | 10:3bc89ef62ce7 | 26 | * | 
| emilmont | 10:3bc89ef62ce7 | 27 | * Option 2 is the one to go for, as RAM is the most valuable resource | 
| emilmont | 10:3bc89ef62ce7 | 28 | */ | 
| emilmont | 10:3bc89ef62ce7 | 29 | |
| emilmont | 10:3bc89ef62ce7 | 30 | #define NVIC_NUM_VECTORS (16 + 32) // CORE + MCU Peripherals | 
| emilmont | 10:3bc89ef62ce7 | 31 | #define NVIC_RAM_VECTOR_ADDRESS (0x10000000) // Vectors positioned at start of RAM | 
| emilmont | 10:3bc89ef62ce7 | 32 | |
| emilmont | 10:3bc89ef62ce7 | 33 | void NVIC_SetVector(IRQn_Type IRQn, uint32_t vector) { | 
| emilmont | 10:3bc89ef62ce7 | 34 | int i; | 
| emilmont | 10:3bc89ef62ce7 | 35 | // Space for dynamic vectors, initialised to allocate in R/W | 
| emilmont | 10:3bc89ef62ce7 | 36 | static volatile uint32_t* vectors = (uint32_t*)NVIC_RAM_VECTOR_ADDRESS; | 
| emilmont | 10:3bc89ef62ce7 | 37 | |
| emilmont | 10:3bc89ef62ce7 | 38 | // Copy and switch to dynamic vectors if first time called | 
| emilmont | 10:3bc89ef62ce7 | 39 | if((LPC_SYSCON->SYSMEMREMAP & 0x3) != 0x1) { | 
| emilmont | 10:3bc89ef62ce7 | 40 | uint32_t *old_vectors = (uint32_t *)0; // FLASH vectors are at 0x0 | 
| emilmont | 10:3bc89ef62ce7 | 41 | for(i = 0; i < NVIC_NUM_VECTORS; i++) { | 
| emilmont | 10:3bc89ef62ce7 | 42 | vectors[i] = old_vectors[i]; | 
| emilmont | 10:3bc89ef62ce7 | 43 | } | 
| emilmont | 10:3bc89ef62ce7 | 44 | LPC_SYSCON->SYSMEMREMAP = 0x1; // Remaps 0x0-0x1FF FLASH block to RAM block | 
| emilmont | 10:3bc89ef62ce7 | 45 | } | 
| emilmont | 10:3bc89ef62ce7 | 46 | |
| emilmont | 10:3bc89ef62ce7 | 47 | // Set the vector | 
| emilmont | 10:3bc89ef62ce7 | 48 | vectors[IRQn + 16] = vector; | 
| emilmont | 10:3bc89ef62ce7 | 49 | } | 
| emilmont | 10:3bc89ef62ce7 | 50 | |
| emilmont | 10:3bc89ef62ce7 | 51 | uint32_t NVIC_GetVector(IRQn_Type IRQn) { | 
| emilmont | 10:3bc89ef62ce7 | 52 | // We can always read vectors at 0x0, as the addresses are remapped | 
| emilmont | 10:3bc89ef62ce7 | 53 | uint32_t *vectors = (uint32_t*)0; | 
| emilmont | 10:3bc89ef62ce7 | 54 | |
| emilmont | 10:3bc89ef62ce7 | 55 | // Return the vector | 
| emilmont | 10:3bc89ef62ce7 | 56 | return vectors[IRQn + 16]; | 
| emilmont | 10:3bc89ef62ce7 | 57 | } | 
| emilmont | 10:3bc89ef62ce7 | 58 | 
