rau cha / mbed-src-I2CWaitFix

fix for mbed lib issue 3 (i2c problem) see also https://mbed.org/users/mbed_official/code/mbed/issues/3 affected implementations: LPC812, LPC11U24, LPC1768, LPC2368, LPC4088

Fork of mbed-src by mbed official

vendor/NXP/LPC11U24/cmsis/cmsis_nvic.c@13:bd9ff402dd42, 2013-08-05 (annotated)

Committer:
Shikaneo
Date:
Mon Aug 05 02:27:27 2013 +0000
Revision:
13:bd9ff402dd42
Parent:
10:3bc89ef62ce7 
equipped timeout

Who changed what in which revision?

UserRevisionLine numberNew 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