mbed official / mbed-src

mbed library sources

Dependents:   Encrypted my_mbed lklk CyaSSL_DTLS_Cellular ... more

Superseded

This library was superseded by mbed-dev - https://os.mbed.com/users/mbed_official/code/mbed-dev/.

Development branch of the mbed library sources. This library is kept in synch with the latest changes from the mbed SDK and it is not guaranteed to work.

If you are looking for a stable and tested release, please import one of the official mbed library releases:

Import librarymbed

The official Mbed 2 C/C++ SDK provides the software platform and libraries to build your applications.

Last commit 20 Feb 2019 by mbed official

targets/cmsis/TARGET_NXP/TARGET_LPC11XX_11CXX/cmsis_nvic.c@358:9d7ef901f004, 2014-10-20 (annotated)

Committer:
mbed_official
Date:
Mon Oct 20 08:45:07 2014 +0100
Revision:
358:9d7ef901f004
Parent:
30:91c1d09ada54 
Synchronized with git revision 996e49964cd2c762ffd47bdce32ff3211f997782



Full URL: https://github.com/mbedmicro/mbed/commit/996e49964cd2c762ffd47bdce32ff3211f997782/



API: Timer - start() behavior (bug)fix

Who changed what in which revision?

UserRevisionLine numberNew contents of line
mbed_official 358:9d7ef901f004 1 /* mbed Microcontroller Library
mbed_official 358:9d7ef901f004 2 * CMSIS-style functionality to support dynamic vectors
mbed_official 358:9d7ef901f004 3 *******************************************************************************
mbed_official 30:91c1d09ada54 4 * Copyright (c) 2011 ARM Limited. All rights reserved.
mbed_official 358:9d7ef901f004 5 * All rights reserved.
mbed_official 358:9d7ef901f004 6 *
mbed_official 358:9d7ef901f004 7 * Redistribution and use in source and binary forms, with or without
mbed_official 358:9d7ef901f004 8 * modification, are permitted provided that the following conditions are met:
mbed_official 30:91c1d09ada54 9 *
mbed_official 358:9d7ef901f004 10 * 1. Redistributions of source code must retain the above copyright notice,
mbed_official 358:9d7ef901f004 11 * this list of conditions and the following disclaimer.
mbed_official 358:9d7ef901f004 12 * 2. Redistributions in binary form must reproduce the above copyright notice,
mbed_official 358:9d7ef901f004 13 * this list of conditions and the following disclaimer in the documentation
mbed_official 358:9d7ef901f004 14 * and/or other materials provided with the distribution.
mbed_official 358:9d7ef901f004 15 * 3. Neither the name of ARM Limited nor the names of its contributors
mbed_official 358:9d7ef901f004 16 * may be used to endorse or promote products derived from this software
mbed_official 358:9d7ef901f004 17 * without specific prior written permission.
mbed_official 358:9d7ef901f004 18 *
mbed_official 358:9d7ef901f004 19 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
mbed_official 358:9d7ef901f004 20 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
mbed_official 358:9d7ef901f004 21 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
mbed_official 358:9d7ef901f004 22 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
mbed_official 358:9d7ef901f004 23 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
mbed_official 358:9d7ef901f004 24 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
mbed_official 358:9d7ef901f004 25 * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
mbed_official 358:9d7ef901f004 26 * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
mbed_official 358:9d7ef901f004 27 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
mbed_official 358:9d7ef901f004 28 * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
mbed_official 358:9d7ef901f004 29 *******************************************************************************
mbed_official 358:9d7ef901f004 30 */
mbed_official 30:91c1d09ada54 31
mbed_official 30:91c1d09ada54 32 #include "cmsis_nvic.h"
mbed_official 30:91c1d09ada54 33
mbed_official 30:91c1d09ada54 34 /* In the M0, there is no VTOR. In the LPC range such as the LPC11U,
mbed_official 30:91c1d09ada54 35 * whilst the vector table may only be something like 48 entries (192 bytes, 0xC0),
mbed_official 30:91c1d09ada54 36 * the SYSMEMREMAP register actually remaps the memory from 0x10000000-0x100001FF
mbed_official 30:91c1d09ada54 37 * to adress 0x0-0x1FF. In this case, RAM can be addressed at both 0x10000000 and 0x0
mbed_official 30:91c1d09ada54 38 *
mbed_official 30:91c1d09ada54 39 * If we just copy the vectors to RAM and switch the SYSMEMMAP, any accesses to FLASH
mbed_official 30:91c1d09ada54 40 * above the vector table before 0x200 will actually go to RAM. So we need to provide
mbed_official 30:91c1d09ada54 41 * a solution where the compiler gets the right results based on the memory map
mbed_official 30:91c1d09ada54 42 *
mbed_official 30:91c1d09ada54 43 * Option 1 - We allocate and copy 0x200 of RAM rather than just the table
mbed_official 30:91c1d09ada54 44 * - const data and instructions before 0x200 will be copied to and fetched/exec from RAM
mbed_official 30:91c1d09ada54 45 * - RAM overhead: 0x200 - 0xC0 = 320 bytes, FLASH overhead: 0
mbed_official 30:91c1d09ada54 46 *
mbed_official 30:91c1d09ada54 47 * Option 2 - We pad the flash to 0x200 to ensure the compiler doesn't allocate anything there
mbed_official 30:91c1d09ada54 48 * - No flash accesses will go to ram, as there will be nothing there
mbed_official 30:91c1d09ada54 49 * - RAM only needs to be allocated for the vectors, as all other ram addresses are normal
mbed_official 30:91c1d09ada54 50 * - RAM overhead: 0, FLASH overhead: 320 bytes
mbed_official 30:91c1d09ada54 51 *
mbed_official 30:91c1d09ada54 52 * Option 2 is the one to go for, as RAM is the most valuable resource
mbed_official 30:91c1d09ada54 53 */
mbed_official 30:91c1d09ada54 54
mbed_official 30:91c1d09ada54 55 #define NVIC_RAM_VECTOR_ADDRESS (0x10000000) // Vectors positioned at start of RAM
mbed_official 30:91c1d09ada54 56
mbed_official 30:91c1d09ada54 57 void NVIC_SetVector(IRQn_Type IRQn, uint32_t vector) {
mbed_official 30:91c1d09ada54 58 int i;
mbed_official 30:91c1d09ada54 59 // Space for dynamic vectors, initialised to allocate in R/W
mbed_official 30:91c1d09ada54 60 static volatile uint32_t* vectors = (uint32_t*)NVIC_RAM_VECTOR_ADDRESS;
mbed_official 30:91c1d09ada54 61
mbed_official 30:91c1d09ada54 62 // Copy and switch to dynamic vectors if first time called
mbed_official 30:91c1d09ada54 63 if((LPC_SYSCON->SYSMEMREMAP & 0x3) != 0x1) {
mbed_official 30:91c1d09ada54 64 uint32_t *old_vectors = (uint32_t *)0; // FLASH vectors are at 0x0
mbed_official 30:91c1d09ada54 65 for(i = 0; i < NVIC_NUM_VECTORS; i++) {
mbed_official 30:91c1d09ada54 66 vectors[i] = old_vectors[i];
mbed_official 30:91c1d09ada54 67 }
mbed_official 30:91c1d09ada54 68 LPC_SYSCON->SYSMEMREMAP = 0x1; // Remaps 0x0-0x1FF FLASH block to RAM block
mbed_official 30:91c1d09ada54 69 }
mbed_official 30:91c1d09ada54 70
mbed_official 30:91c1d09ada54 71 // Set the vector
mbed_official 30:91c1d09ada54 72 vectors[IRQn + 16] = vector;
mbed_official 30:91c1d09ada54 73 }
mbed_official 30:91c1d09ada54 74
mbed_official 30:91c1d09ada54 75 uint32_t NVIC_GetVector(IRQn_Type IRQn) {
mbed_official 30:91c1d09ada54 76 // We can always read vectors at 0x0, as the addresses are remapped
mbed_official 30:91c1d09ada54 77 uint32_t *vectors = (uint32_t*)0;
mbed_official 30:91c1d09ada54 78
mbed_official 30:91c1d09ada54 79 // Return the vector
mbed_official 30:91c1d09ada54 80 return vectors[IRQn + 16];
mbed_official 30:91c1d09ada54 81 }
mbed_official 30:91c1d09ada54 82