Writing this post just want to remind the customer of RAM allocation when use the on-chip CAN drivers in LPC11C24. Otherwise, when meet the abnormal issues, it is difficult to locate the root reason and it also causes a waste of time.      Now, take a real customer question as an example, to highlight the RAM allocation importance when using the on-chip CAN API in LPC11C24. Problem description     Customer used the LPC11C24 on-chip CAN API to realize the CAN frames sending and receiving, the CAN code was from the official lpcopen, and it worked OK when he just used the CAN code. But when customer added the UART code, they found the code always enter hardfault after a short time running. They test the UART code which without the CAN code directly, the UART code worked perfectly. It means, independent UART code and independent CAN code are all working normally, but when combine the UART and on-chip CAN code together, the code will enter hardfault. Problem analysis From the Cortex M0 devices generic user guide, we can get the information about the hard fault:     Faults are a subset of exceptions, see Exception model. All faults result in the HardFault exception being taken or cause lockup if they occur in the NMI or HardFault handler. The faults are:      execution of an SVC instruction at a priority equal or higher than SVCall      execution of a BKPT instruction without a debugger attached      a system-generated bus error on a load or store      execution of an instruction from an XN memory address      execution of an instruction from a location for which the system generates a bus fault      a system-generated bus error on a vector fetch      execution of an Undefined instruction      execution of an instruction when not in Thumb-State as a result of the T-bit being previously cleared to 0      an attempted load or store to an unaligned address Now we debug the problem project to check, which detail code line caused this hardfault problem. When the code enters the hardfault handler, check the MSP address in the flash, then find the LR register, which will link to the code before entering in the hardfault handler, the following are the according debug result:   The LR register is 0X1FFF2C1F, it means before enter in hardfault handler, the code runs to this address code. Now, check the 0X1FFF2C1F in the memory map.    We can find the address is in the ROM area, because we just use the ROM CAN driver, UART is just the pure register control code, then we can get the problem still relate to the on-chip CAN driver, not the UART code. But we can’t see or debug the detail ROM CAN driver directly, we still can’t find the root problem.    Even we know the problem is not caused by the UART, but another important clue which relates to the UART function also influence the test result after I do a lot of testing. In the customer code, he defines the UART user transmit and receive buffer like this: #define UART_SRB_SIZE 128    // Send #define UART_RRB_SIZE 32    // Receive /* Transmit and receive buffers */ static uint8_t rxbuff[UART_RRB_SIZE], txbuff[UART_SRB_SIZE];   On one occasion, I tried changing #define UART_SRB_SIZE 128 To  #define UART_SRB_SIZE 32 Just minimize the txbuff size, I found the code won’t enter in the hardfault handler any more. It seems very strange and contradiction with the hardfault handler enter point which is test before.    I also check the generated code size, the used RAM and flash size is:   text       data        bss        dec        hex    filename    7672          0        244       7916       1eec    pscan.axf LPC11C24 RAM is 8K, here just 244 Bytes, the stack also use the whole RAM, so the 8K RAM size should be enough to use.   In this situation, I check the project’s .map file about the txbuff with 128 and 32 respectively.    1)txbuff with 128Bytes Rxbuff and txbuff occupy the RAM address from 0X10000048 to 0X100000E8.     2)txbuff with 32Bytes Rxbuff and txbuff occupy the RAM address from 0X10000048 to 0X10000088. We can find the txbuff start address is the same, just the end address has difference.    With these information, we checked the LPC11C24 user manual chapter C_CAN on-chip drivers again, we found a significant description:      0X10000050 to 0X100000B8 is used by the on-chip CAN API RAM, and from the issue project, memory map file, we can find rxbuff and txbuff RAM address is 0X10000048 to 0X100000E8, it already occupies the whole CAN API RAM, this is the key point. Minimize the txbuff, then rxbuff and txbuff occupy the RAM address from 0X10000048 to 0X10000088, this address doesn’t occupy the whole on chip CAN API RAM, in this situation, the problem doesn’t happen, I think the used CAN API may in the RAM address 0X10000089-0X100000B8.    Anyway, just minimize the buffer size can’t solve the problem from the root side. We must follow the user manual to keep the RAM address from 0x10000050 to 0x100000b8 won’t be used by any other application code.   Problem solutions      From the above chapter, we can find the root problem is the application code occupies the on-chip CAN RAM, to solve the problem, we need to modify the linker file, to prevent the usage of on-chip CAN RAM range.      Because the customer is using the LPCXPresso IDE, then we take this IDE as an example, to protect the RAM address 0x10000050 to 0x100000b8. From the above, we can get that the LPCX11C24 have 8Kbytes RAM, normally, customer will define it just in one, now we divide the RAM to two pieces. 1) RAM2: Location 0X10000000, size 0X100 2) RAM: Location 0X10000100, size 0X1F00 In the LPCXpresso, Project Properties -> C/C++ Build -> MCU settings, then modify it like this:     Then generate the code, and check the map file again.   RAM address from 0x10000000 to 0X10000FF is not used by any other application code. All the application code RAM is using from address 0x10000100. After long time testing, we find the hardfault problem never happens, on customer side, it also works OK. In conclusion, when customer want to use the on-chip CAN API, they need to protect the RAM address from 0x10000050 to 0x100000b8 in the linker file.    

This content was originally contributed to lpcware.com by Richard Man This project demonstrates how easy it is to port a commonly used open source FatFS code to the LPC4350 using SDIO and built-in SDMMC support. In the competitive embedded microcontroller market, one way a silicon vendor can differentiate its offerings from the rest is by integrating higher-function peripherals onchip. As such, it is no longer unusual to find chips with built-in LCD, USB, CAN, Ethernet, and in some instances, even hardware support for the SD/MMC memory devices. Such is the case with the NXP LPC4350. With two ARM Cortex cores and many other features, it also sports SD/MMC hardware. Without dedicated SD/MMC support, the firmware typically must use bit banging code which is timing sensitive and adds to the complexity of the code.

When you are the first time to debug LPC55S69, please read below document and double check your IDE, SDK and EVK version is correct. Usually, we prefer use the latest IDE, SDK and EVK boards. Important updates when using LPCXpresso55S69 Revision A2 boards and 1B silicon  [Problem Description] When you use IAR 8.32 to debug LPC55S69 '1B' silicon, the IDE will remind you "The debugging session could not be started", like below picture show: The reason of this failure is that IAR 8.32's LPC55S69 chip configuration files only support revision '0A' silicon, not '1B'. We strongly recommend customer download and use IAR 8.40.2 or latest version. The IAR IDE start support LPC55S68 '1B' silicon from 8.40.2. [Solution] If you have some reasons that must use IAR 8.32, you can download attached zip file. This zip file like a patch, include the IAR LPC55S69 '1B' support files. Un-zip this file and merge the same files under IAR installed path :IAR\arm\config\flashloader\NXP Then the IAR can support '1B' silicons. [How to identify LPC55(S)6x chip silicon versions] On the top-side marking code, there is '1B'  charactors at the end of mark strings. See below two pictures, the left one is '1B' version chips.                      LPC55(S)6x ver '1B'                                                               LPC55(S)6x ver '0A'                   

The DMX512 master and slave board (OM13043) are no longer available. This page is provided for reference purposes only. Board information and code is available in the zip file attached to this posting. NXP offers dedicated components to realize DMX512 based systems for both communication and power stages. The reference design provides a basic set of commands (including Remote Device Management) that can be used as a starting point to develop next-generation DMX512 platforms. The DMX512 Software Development Kit (SDK) for the LPC11xx/LPC11Uxx installer contains: AN11153 - Describes the use of the NXP LPC111x Cortex M0 microcontroller to create an RDM enabled DMX512 Slave AN11154 – Describes the use of the NXP LPC11U1x Cortex M0 microcontroller to create a RDM enabled DMX512 Master (USB - DMX interface) UM10536 - Explains how to get started with the NXP DMX512 Master (USB - DMX interface) and DMX512 Slave (demo board for DMX fixture) and the NXP Windows .NET DMX512control application Software Package – DMX master and slave implementation for LPCXpresso toolchain and Windows .NET GUI Schematics, Gerber files and BOM List The SDK is attached to this page (see below) for REFERENCE PURPOSES ONLY. DMX512 Master Board DMX512 Slave Board System notes Controller side: LPC1100XL microcontroller (up to 50 MHz - 45 DMIPS) offers performance needed to integrate DMX message coding/decoding and PWM generation in a single chip Industry-leading low active power consumption of 110 uA/MHz for bus-powered devices Storage of scene settings in non-volatile memory using EEPROM emulation in flash, or integrated EEPROM in LPC11E00 series Up to four 16-bit and 32-bit timers, generating up to 11 PWM signals to control and dim the ballast Reduced development complexity - software can be written in C Reduced bill of materials – significant cost savings through Cortex-M0 architecture, plus many built-in peripherals to interface with lighting drivers and network in LPC1100XL Power stage: LED dimming using the PWM input of the NXP UBA3070 DC-to-DC LED driver with up to 98% efficiency SSL4101 provides mains isolation for both the RGB LED power stage and the DMX wires Low component count and high efficiency through integrated PFC and flyback control functionality GreenChip TEA1721 buck converter supplies LPC1100XL with high efficiency; no-load power consumption levels 10 mW Implementation example (DMX512 slave unit): RDM-enabled DMX512 slave or receiver built around the NXP LPC111x Cortex-M0 microcontroller Features four DMX controllable LEDs, a red heartbeat LED, a green traffic LED, DIP switches for selecting the DMX start address, a 5-position joystick, and an optional LCD The UART and the 16-bit timer/counters of the LPC111x MCU are the main hardware blocks needed The I2C hardware block is used to interface with the (optional) LCD functionality References to DMX512 refer to DMX512-A, since both hardware and software are designed using the latest standard Implementation example (DMX512 master unit): DMX512 controller and monitoring device, built around the NXP LPC11U1x microcontroller, enabling Remote Device Management (RDM) Features a USB interface, a red heartbeat LED, and a green traffic LED The USB and UART of the LPC11U1x MCU are the main hardware blocks needed

lpcopen. uart  #ring_buffer

This content was originally contributed to lpcware.com by Dirceu Rodrigues Introduction My work evaluating the SCT peripheral with the Hitex LPC4350 board (ARM Cortex-M4/M0) included the generation of non standard PWM signals for use in Power Electronics. At the end, some results would be compared with solutions based on LPC1114 (Cortex-M0), for example.  The first idea was to apply a concept that I had used when developing universal controllers for laser printer fuser, at 2001. This is a gate drive for MOSFET / IGBT isolated by pulse transformers. Two pulses Gate Drive – LPC1114 solution The circuit is implemented with pulse transformers (20 kHz PWM frequency) using the gate-source capacitance as memory. A Schottky diode avoids the stored charge to leak through windings. Thus, it's possible to achieve duty-cycles near to 0 and 100 %, simply applying 1 µs pulses shifted in time - one for charge, other for discharge. A very simplified schematic is shown in Figure 1.       Figure 1. Simplified circuit. My solution for the LPC1114 - Cortex-M0, uses two timers in a different scheme: Phase-out or lead/lag the counter values. With CT32B0 and CT32B1 32 bit timers, the behavior, including the pulsed outputs, is better understood looking on Figures 2 and 3 for duty-cycles of 75% and 25%. As opposed to common solutions, for each timer, the MR0 and MR1 matching registers values are constant. The difference between them is equivalent to pulse width (1 µs). The MR0 value also defines the period. The duty-cycle it’s determined through the expression:   DC = TC1 / MR0                                   (1) Where, TC1 is the CT32B1 timer value when this one, for the CT32B0, is zero.      In order to change the duty-cycle, the code in foreground task establishes a new TC1 and enables the CT32B0 overflow interrupt, where  this value is effectively loaded on CT32B1 timer in a safe point (to avoid jitter and other dangerous edges on outputs). Also, the CT32B0 ISR disables itself at the end, ensuring low interrupt overhead. For safety, the first applied pulse is a “discharge pulse”. This solution was proven driving a 930 W (120V/8.7 A) single-phase induction motor and it can be seen in reference [1], using a synchronous AC version of circuit shown in Figure 1 (no diode, four mosfets).      Figure 2. LPC1114 Two Pulses Gate Drive solution - DC 75%.  Figure 3. LPC1114 Two Pulses Gate Drive solution - DC 25%.      Two pulses Gate Drive – LPC4350 SCT solution The equivalent SCT implementation for the Two Pulses Gate Driver has the advantage of saving one timer. The pulse generation can be accomplished through a Mealy finite state machine plus the companion SCT counter. The LPC4350 generates 1 µs pulses with repetition rate of 20 kHz on CTOUT_4 and CTOUT_5 outputs. Two pushbuttons allow that a falling edge on CTIN_2 input, start the timer and a low value on CTIN_6, stop it. The counter operates as a unified 32 bit timer (UNIFY = 1) counting up and down (BIDIR = 1). ADC0 input is used to read the voltage on R26 potentiometer. So, the firmware can convert it in PWM change. As for LPC1114, the LPC4350 core and SCT runs in 48 MHz. Register MATCH 0 defines half-period. The difference between MATCH 2 and MATCH 1 registers is equivalent to pulse width (1 µs). In other words: PULSE_WIDTH = MATCH 2 - MATCH 1                       (2) Despite this difference be constant, now the MATCH 2 and MATCH 1 contents must change at the same time. Figures 4 and 5 show the waveforms for duty-cycles 15 % and 85 %. For example, the duty-cycle can be determined through the expression: DC = 1 – (MATCH 1 + 0.5*PULSE_WIDTH )/ MATCH 0        (3) Figure 4. SCT Two Pulses Gate Drive solution - DC 15%. Note: In companion source code, the PULSE_WIDTH is referred as PULSE_LENGTH. Figure 5. SCT Two Pulses Gate Drive solution – DC 85%. In order to achieve this behavior, one simple Finite State Machine with two states has been defined (Table 1): STATE Meaning 0 CTOUT_4 pulse generation 1 CTOUT_5 pulse generation Table 1. Definition of states. Figure 6 illustrates the relationship between the counter, states and interrupts. The PWM updating scheme takes advantage of following SCT property (as stated on User Manual): “A MATCH register is loaded from the corresponding MATCHREL register when BIDIR is 1 and the counter reaches 0”. In this application, the ADC0 interrupts MCU in a 24 Hz rate, triggered by TIMER0 MR0 (EM0 rising edge). The code on this ISR determines the new MATCH 1, saves it on global variable match1 and enables the SCT interrupt associated with event “counter reach limit” - in fact, event for MATCH 0. Here note, as stated in expression (3), that DC depends only on MATCH1, since MATCH 0 is constant. The ISR code for MATCH 0 event, updates MATCHREL 1 and MATCHREL 2 registers based on variable match1. Also disables the associated interrupt for low overhead. When counter reaches 0, the MATCH 1, 2 registers will be reloaded from the MATCHREL 1, 2 values automatically. This procedure should avoid jitter and other dangerous edges on outputs. Note that MATCH registers are never handled by software when counter is running. The new desired values are indirectly loaded on MATCHREL registers. The first values for MATCH registers are intentionally unreachable (> MATCH 0). This ensures that only ADC readings brought useful values to them. The on board potentiometer generates a voltage from 0 V to 3.3 V, which translates to 0 – 1023 range by the 10 bit AD converter. The MIN_MATCH1 and MAX_MATCH1 predefined values equates to 36 and 1116 (equivalent to duty-cycle 5 % and 95 % DC). Therefore, the software relates ADC0 voltage to with match1 variable approximately through the expression: match1 = [(MAX_MATCH1 - MIN_MATCH1)*ADC0] / 1024 +            (4)                                                  MIN_MATCH1 Note: In the companion source code, the division by 1024 is performed with a 10 bit right shift.           Figure 6. PWM updating scheme - DC 50%. Table 2 lists the eight states comprising the state machine for the current application. The companion state transition diagram is showed on Figure 7. Here, note other SCT important property, as stated on User’s Manual: “If more than one event associated with the same counter occurs in a given clock cycle, only the state change specified for the highest-numbered event among them takes place”. This applies to events 6 and 7. In normal operation, the event 6 happens periodically in State 1; but when a pushbutton press causes a low level on CTIN_6, the event 7 is fired on State 1 and counter is stopped. The state is driven to 0, with the outputs cleared (until one falling edge on CTIN_2 initiates the counting). EVENT ID Happens in state Conditions Actions 0 0 Falling edge on CTIN_2 Start counter 1 0 Counter reach MATCH 1 when counting up Set CTOUT_4 (pulse rise) 2 0 Counter reach MATCH 2 when counting up Clear CTOUT_4 (pulse fall) 3 0 Counter reach MATCH 0 Limit counter (defines the half period) Int. to update MATCHREL 1/ 2 Change to STATE 1 4 1 Counter reach MATCH 2 when counting down Set CTOUT_5 (pulse rise) 5 1 Counter reach MATCH 1 when counting down Clear CTOUT_5 (pulse fall) 6 1 Counter reach MATCH 3 (0) MATCH 1/ 2 automatic reloading Change to STATE 0 7 1 Counter reach MATCH 3 (0) AND Low value on CTIN_6 Stop counter MATCH 1/ 2 automatic reloading Change to STATE 0 Table 2. Definition of states. Figure 7. State transition diagram. Conclusion The PWM generation carried out by two short pulses shifted in time is a good alternative when isolation and duty-cycles far from 50% are required - specially driving gate charge devices like Mosfet/IGBT. The main advantage over opto-isolated implementations is not necessary create an auxiliary power supply.  Regarding to the architecture, the designer can use microcontrollers equipped with UP/DOWN timers (bidirectional), but is required some external glue logic in order to generate those short pulses. In comparison with the LPC1114 presented solution, the SCT version consumes just one timer/counter. As shown, the SCT peripheral is very independent, resulting in low (or no) MCU intervention after an initial configuration. This simple application used only two inputs, two outputs, two states and eight events. For more complex designs, the SCT provides up to 8 inputs, 16 outputs, 16 events and 32 states. I’ve future plans to make other power electronics applications based on SCT, including a small dot matrix printer controller. Code Red company   provides a tool to draw state diagrams and automatically generate code for the SCT engine, called Red State [2] (not used in this application). Finally, I would like to thank David Donley from NXP, who assisted me by answering my technical enquiries about the State Configurable Timer and suggesting improvements on code. References     [1]    http://www.youtube.com/DirceuRodriguesJr     [2]    http://www.code-red-tech.com/lpcxpresso

#lpc‌ #dualcore‌ #feature‌ Attached doc is the LPC MCU Serial dual core feature introduction and application

lpc‌ feature‌ LCD‌ Attached doc is the LPC MCU Serial LCD controller feature introduction and application

Some processors in LPC family have EMC, which enable customer to connect external parallel SRAM, NOR flash, SDRAM, there is application which saves code in serial flash for example SPI flash or IIC flash, copy the code to SDRAM and run code in SDRAM. This is a simple code to demo how to run the code in SDRAM, the Code is developed under the SDRAM example code with SDK package, which initialize SDRAM and write data to SDRAM, read the data from SDRAM, compare whether the writing data and reading data are the same. A simple function void LED_Toggle(void) is used to toggle a LED, the API function is copied to SDRAM with the function void mem2mem(uint16_t *sourceAdd,uint16_t *destinationAdd,uint16_t length), after the function is called, an function pointer is defined and jump to the function pointer. BTW, if user would like to run code in SDRAM, the MPU module for the Cortex-M4 has to be initialized, which enable the code in SDRAM to be fetched and executed. The Demo code is developed under MCUXpresso ver10.3.1 and LPCXpresso546xx board(OM40003). after you Run code, the LED2 can toggle on LPCXpresso546xx board.. I list the main code here. All the project is attached. void mem2mem(uint16_t *sourceAdd,uint16_t *destinationAdd,uint16_t length) {     sourceAdd = (uint16_t *)((uint32_t)sourceAdd & (0xFFFFFFFE));     destinationAdd=(uint16_t *)((uint32_t)destinationAdd & 0xFFFFFFFE);     for(uint16_t i=0; i<length; i++)     {         destinationAdd[i]=sourceAdd[i];     }     __DSB();     __ISB(); } #define SDRAM_BASE_ADDR_CODE 0xa0000001 typedef void (*functionPointer)(void); //The PC value must be an odd value although the code address is an even //value void runCodeInSDRAM(void) {     ((functionPointer)SDRAM_BASE_ADDR_CODE)(); } void LED_Toggle(void) {     while(1)     {         delay_1();         GPIO->NOT[3]|=1<<3;     } } void MPU_Init(void) {     //disable MPU     MPU->CTRL=0x00;     //Region0: default region 0     MPU->RBAR=0x00000010;     MPU->RASR=0x1004003f;     //Region 1:     //set up flash, ROM, SRAM ... as region 1     //# 0x00000000 - 0x3FFFFFFF     MPU->RBAR=0x00000011;     MPU->RASR=0x0306E23b;     //Region 2:     //set up peripheral device     //# 0x40000000 - 0x400FFFFF     MPU->RBAR=0x40000012;     MPU->RASR=0x13050033;     //Region 3:     //set up chip select and device     //# 0x80000000 - 0x9000FFFF     MPU->RBAR=0x80000013;     MPU->RASR=0x1305001f;     //Region 4:     //set up SDRAM     //# # 0xA0000000 - 0xA0FFFFFF     MPU->RBAR=0xa0000014;     MPU->RASR=0x0307002f;     //Region 5:     //set up Cortex-M4 Private Peripheral Bus     //# 0xE0000000 - 0xE00FFFFF     MPU->RBAR=0xe0000015;     MPU->RASR=0x13040027;     //Region 6:     //set up Not used     //# 0xE0000000 - 0xE00FFFFF     MPU->RBAR=0xe0000016;     MPU->RASR=0x00000000;     //Region 7:     //set up stack     //#     MPU->RBAR=0x1000E017;     MPU->RASR=0x10060009;     //enable MPU     MPU->CTRL=0x01; } int main(void) {     uint32_t index;     uint32_t *sdram = (uint32_t *)SDRAM_BASE_ADDR; /* SDRAM start address. */     /* Hardware Initialization */     CLOCK_EnableClock(kCLOCK_InputMux);     /* attach 12 MHz clock to FLEXCOMM0 (debug console) */     CLOCK_AttachClk(BOARD_DEBUG_UART_CLK_ATTACH);     BOARD_InitPins();     BOARD_BootClockFROHF96M();     BOARD_InitDebugConsole();     LEDInit();     //LED_Toggle();     BOARD_InitSDRAM();     MPU_Init();     mem2mem((uint16_t *)LED_Toggle,(uint16_t *)SDRAM_BASE_ADDR_CODE,400);    // LED_Toggle();     runCodeInSDRAM(); }

View Webinar Recording

View Webinar Recording

This documet is an introduction about TrustZone on the LPC55S6x devices. LPC55S6x MCU platform and general-purpose blocks The LPC55S69 has one 100-MHz Cortex-M33 core with TrustZone, MPU, FPU, and SIMD and another 100-MHz Cortex-M33 without security features enable. Lets remark that the LPC55Sxx family has another LPC55S66 that only implements a single 100-MHz core. There are two coprocessors on core 0, a DSP accelerator called PowerQuad, and a crypto engine called CASPER. The core platform has a multilayer bus matrix that allows simultaneous execution from both cores and parallel access of the other masters to peripherals and memories. The memory on chip includes up to 640 KB of Flash, up to 320 KB of RAM, and 128 KB of ROM. Timers include 5 - 32-bit timers, a SCTimer/PWM, a multi-rate timer, a windowed watchdog timer, Real Time Clock (RTC), and a micro timer. Each core has its own systick timer. Communication interfaces include a USB high-speed with on-chip HS PHY, a USB full-speed that can run crystal-less, two SDIO interfaces to support WIFI and SD cards at the same time, 1 high-speed SPI with up to 50-MHz clock rate, and 8 Flexcomms with support of up to 8 SPI, I2C, UART, or 4 I2S. The analog system includes a 16-channel 16-bit ADC that samples at 1 MSPS, an analog comparator, 16-channel capacitive touch controller, and a temperature sensor. Other modules include a programmable logic unit, a buck DC-DC converter, operating voltage from 1.71 to 3.6 V over a temperature range from -40 to 105 °C. What is TrustZone? In recent years, the Internet of Things (IoT) has become a hot topic for embedded system developers. IoT system products have become more complex, and better solutions are needed to ensure system security. ARM® TrustZone® technology is a System on Chip (SoC) and CPU system-wide approach to security. The TrustZone® for ARMv8-M security extension is optimized for ultra-low power embedded applications. It enables multiple software security domains that restrict access to secure memory and I/O to trusted software only. TrustZone® for ARMv8-M: Preserves low interrupt latencies for both secure and non-secure domains Does not impose code overhead, cycle overhead or the complexity of a virtualization based solution Introduces efficient instructions for calls to the secure domain with minimal overhead TrustZone® is a technology available in Cortex M23 and Cortex M33. TrustZone® provides the means to implement separation and access control to isolate trusted software and resources to reduce the attack surface of critical components. The created trusted firmware can protect trusted operations and is ideal to store and run the critical security services. The code should also protect trusted hardware to augment and fortify the trusted software. This includes the modules for hardware assists for cryptographic accelerators, random number generators, and secure storage. Best practices demand that that this code be small, well-reviewed code with provisions of security services. The LPC55S66 and LPC55S69 have implemented core 0 as a Cortex-M33 with full TEE and TrustZone® support enabled. The LPC55S69 has a second Cortex-M33 (core 1) that does not implement the secure environment with TZ. Isolation is just the foundation. Security is about layers of protection, adding in further hardware and software to create more layers. Features of TrustZone® technology: Allows user to divide memory map into Secure and Non-Secure regions Allows debug to be blocked for Secure code/data when not authenticated CPU includes Security Attribution Unit (SAU) as well as a duplication of NVIC, MPU, SYSTICK, core control registers etc. such that Secure/Non-Secure codes can have access to their own allocated resources Stack management expands from two stack pointers in original Cortex-M (Main Stack Pointer (MSP) and Process Stack Pointer (PSP)) to four, providing the above pair individually to both Secure and Non-Secure Introduces the concept of Secure Gateway opcode to allow secure code to define a strict set of entry points into it from Non-secure code Secure and non-secure memory TrustZone® technology divides the system into two states, safe (S) and non-secure (NS), and can switch between the two states through corresponding commands. The CPU states can be secure privilege, secure non-privilege, privilege (Handler), or non-privilege (Thread). The Secure memory space is further divided into two types: Secure and Non-secure Callable(NSC). Below are the feature/properties of Trustzone memory regions ( S, NS, NSC 😞 Secure (S) - For Secure code/data − Secure data can only be read by secure code − Secure code can only be executed by CPU in secure mode Non-Secure (NS) – For non-Secure code/data − NS Data can be accessed by both secure state and non-secure state CPU − Cannot be executed by Secure code Non-Secure Callable (NSC) − This is a special region for NS code to branch into and execute a Secure Gateway (SG) opcode. Attribution Units Combination of Security SAU and IDAU assign a specific security attribute  (S, NS, or NSC) to a specific address from the CPU0. Device Attribution Unit (DAU) connects to CPU0 via IDAU interface as show the following Figure. Access from CPU0, dependent on its security status and the resultant security attribute set by the IDAU and SAU, is then compared by the secure AHB Controller to a specific checker which marks various access policies for memory and peripherals. All addresses are either secure or non-secure. The SAU inside of the ARMv8-M works in conjunction with the MPUs. There are 8 SAU regions supported by LPC55S69. Secure and non-secure code runs on a single CPU for efficient embedded implementation. A CPU in a non-secure state can only execute from non-secure program memory. A CPU in a non-secure state can access data from both NS memory only. For the secure, trusted code, there is a new secure stack pointer and stack-limit checking. There are separate Memory Protection Units (MPUs) for S and NS regions and private SysTick timers for each state. The secure side can configure the target domain of interrupts. The NXP IDAU (Implementation specific Device Attribution Unit) implementation of ARM TrustZone for core0 involves using address bit 28 to divide the address space into potential secure and non-secure regions. Address bit 28 is not decoded in memory access hardware, so each physical location appears in two places on whatever bus they are located on. Other hardware determines which kinds of accesses (including non-secure callable) are allowed for any address.  The IDAU is a simple design using address bit 28 to allow aliasing of the memories in two locations. If address bit 28 is = 0 the memory is Non-Secure. If address bit 28 = 1 the memory is Secure. The SAU allows 8 memory regions and allow the user to override the IDAU’s fixed Map, to define the non-secure regions. By default, all memory is set to secure. At least one ASU descriptor should be used to make IDAU effective. If either IDAU or SAU marks a region, then that region is secure. NSC area can be defined in NS region of the IDAU. For example a designer could use bit [28] of the address to define if a memory is Secure or Non-secure, resulting in the following example memory map. Simple IDAU, without creating a critical timing path. (CM33 does allows little for IDAU function) Addresses 0x0000_0000 to 0x1FFF_FFFF are NS, Addresses 0x2000_0000 to 0xFFFF_FFFF If Address Bit_28 = 0  Non-Secure If Address Bit_28 = 1  Secure All peripherals and memories are aliased at two locations. The SAU define region numbers for each of the memory regions. The region numbers are 8-bit, and are used by the Test Target(TT) instruction to allow software to determine access permissions and security attribute of objects in memory. The number of regions that are included in the SAU can be configured to be either 0, 4 or 8. Note: When programming the SAU Non-secure regions, you must ensure that Secure data and code is not exposed to Non-secure applications. Security state changes The system boots in secure state and can change security states using branches as summarized in the following Figure. Transitions from secure to non-secure state can be initiated by software through the use of the BXNS and BLXNS instructions that have the Least Significant Bit (LSB) of the target address unset. Note: The M profile architecture does not support the A32 instruction set. This allows the LSB of an address to denote the security state. Transitions from non-secure to secure state can be initiated by software in two ways: A branch to a secure gateway. A branch to the reserved value FNC_RETURN. A secure gateway is an occurrence of the Secure Gateway instruction (SG) in  the Non-Secure Callable (NSC) region. When branching to a secure gateway from non-secure state, the SG instruction switches to the secure state and clears the LSB of the return address in lr. In any other situation the SG instruction does not change the security state or modify the return address. A branch to the reserved value FNC_RETURN causes the hardware to switch to secure state, read an address from the top of the secure stack, and branch to that address. The reserved value FNC_RETURN is written to lr when executing the BLXNS instruction. Security state transitions can be caused by hardware through the handling of interrupts. Those transitions are transparent to software and are ignored in the remainder of this document. The TT instruction The ARMv8-M architecture introduces the Test Target instruction (TT). The TT instruction takes a memory address and returns the configuration of the Memory Protection Unit (MPU) at that address. An optional T flag controls whether the permissions for the privileged or the unprivileged execution mode are returned. When executed in the secure state the result of this instruction is extended to return the Security Attribution Unit (SAU) and Implementation Defined Attribution Unit (IDAU) configurations at the specific address. The MPU is banked between the two security states. The optional A flag makes the TT instruction read the MPU of the non-secure state when the TT instruction is executed from the secure state. The TT instruction is used to check the access permissions that different security states and privilege levels have on memory at a specified address. You can find more useful information about ARM® TrustZone®, in the following links: https://developer.arm.com/ip-products/security-ip/trustzone https://www.nxp.com/docs/en/application-note/AN12278.pdf http://www.keil.com/appnotes/files/apnt_291.pdf  http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/ECM0359818_armv8m_security_extensions_reqs_on_dev_tools_1_0.pdf

This document explains how to start with LPCXpresso845-MAX Evaluation Board building, running and debugging example codes. Introduction   Based on the ARM Cortex-M0+ core, LPC84x is a low-cost, 32-bit MCU family operating at frequencies of up to 30 MHz. The LPC84x MCU family supports up to 64 KB of flash memory and 16 KB of SRAM. There is no LPCOpen nor SDK for LPC84x, however there is an example code bundles (register level) available for this family. The example code bundles offer a fastest, and simplest way for user to learn how to program each peripheral before progressing to more advance features of the peripheral. New users of LPC84x can step through the Example Code like a tutorial. Each project contains concise and accurate explanations in Readme files and comments in source files help the user to start/debug quickly. LPC845 Example Code Bundle is available for KEIL, MCUXpresso and IAR IDEs and you can download it from next link:   http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc800-series-cortex-m0-plus-mcus/low-cost-microcontrollers-mcus-based-on-arm-cortex-m0-plus-cores:LPC84X?tab=Design_Tools_Tab Build, run and debug an example   This section describes the steps required to build, run, and debug an example application. 1. Download the LPC845 Example Code Bundle MCUXpresso from the next link:  http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc800-series-cortex-m0-plus-mcus/low-cost-microcontrollers-mcus-based-on-arm-cortex-m0-plus-cores:LPC84X?tab=Design_Tools_Tab 2. Open MCUXpresso IDE. 3. Select "Import project(s) …" from the Quickstart Panel. 4. Click the "Browse" button and point to the LPC845-Example-Code-Bundle-MCUXpresso.zip, which should be downloaded previously, and then click “Next” button. 5. By default all the projects are selected, however you can select only the desired example project. In order to build the example project, it is necessary to add in the workspace the following projects: common peripherals_lib utilities_lib For this document, we are using the Multi_Timer_Blinky example project. 6. Build the project using the hammer icon on Quickstar Panel.  7. Connect the development platform to your PC via USB cable. If connecting for the first time, allow some seconds for the devices to enumerate.   8. This example runs from Flash. To run this code you have two options: a) Download and Debug.    b) Load to flash using the “run” IDE icon and press the reset button on the board. Note: It may be necessary to power-cycle the board in order to regain control of the reset button after programming. At this moment, you can be able to run or debug the example project. I hope this helps!!!

This document explains how to create a new project using MCUXpresso IDE for a LPCXpresso1549 board. There is important to mention that there is no SDK for LPC15xx device family so we are using LPCOpen libraries.   MCUXpresso IDE introduction   MCUXpresso IDE is based on the Eclipse IDE and includes the industry standard ARM GNU toolchain. It brings developers an easy-to-use and unlimited code size development environment for NXP MCUs based on Cortex-M cores (LPC and Kinetis). MCUXpresso IDE debug connections support Freedom, Tower®, LPCXpresso and your custom development boards with industry- leading open-source and commercial debug probes including LPC-Link2, P&E and SEGGER. The fully featured debugger supports both SWD and JTAG debugging, and features direct download to on-chip flash. When MCUXpresso IDE is installed, it will contain pre-installed part support for most LPC based MCUs. Example code for these pre-installed parts is provided by sophisticated LPCOpen packages (and Code Bundles). Each of these contains code libraries to support the MCU features, LPCXpresso boards (and some other popular ones), plus a large number of code examples and drivers.   In addition, MCUXpresso IDE’s part support can be extended using freely available MCUXpresso SDK2.x packages. These can be installed via a simple ‘drag and drop’ and automatically extend the IDE with new part knowledge and examples. SDKs for MCUXpresso IDE can be generated and downloaded as required using the SDK Builder on the MCUXpresso Config Tools website at: http://mcuxpresso.nxp.com/   Create a new project   For this document, we are using the LPCXpresso1549 board (for this MCU an LPCOpen project exists), however the process is the same for any LPCXpresso board. It is necessary to download the LPCOpen bundle for your target MCU/board and import it into your Workspace, LPCOpen is available in the next link:  http://www.nxp.com/lpcopen Select “New project” in the QuickStart panel, this will open a new window   Select the desire board. For this case, we are using the LPCXpresso1549, and click “Next” NOTE: When the board is selected, you can see highlighted in the above figure that the matching MCU (part) is selected automatically. If no matching board is available, the required MCU can be selected from the list of Pre-Installed MCUs. The MCUXpresso IDE includes many project templates to allow the rapid creation of correctly configured projects for specific MCUs. This New Project wizard supports 2 types of projects: Those targeting LPCOpen libraries Standalone projects In this case, we will show the steps in creating a LPCOpen- Cproject. This option creates a simple C project, with the main() routine consisting of an infinite while(1) loop that increments a counter. In additions, code will also be included to initialize the board and enable a LED. Select the project name and click “Next” When creating an LPCOpen-based project, the first option page that you will see is the LPCOpen library selection page. It is necessary import the LPCOpen Chip Library for the device used and optionally the LPCOpen Board Library Project, the below window allows to import the libraries if you have not already done so. Follow the below steps: a. Click on “Import…”, a new window will appear, select the archive file to import. In this case, the projects imported are contained within archives .zip. For this example, the LPCXpresso1549 board is selected. Click “Open”. Then click “Next” b. Select only the LPCOpen Chip Library and LPCOpen Board Library Project. Click “Finish” Select LPCOpen Libraries. Click “Next” Select CMSIS Library project. The CMSIS library option within the MCUXpresso IDE allows you to select which (if any) CMSISCORE library you want to link to from the project you are creating. For this case we selected “None” as default. Click “Next” NOTE: The use of LPCOpen instead of CMSIS-CORE library projects is recommended in most cases for new projects. Enable SWO trace clock. Click “Next” Enable linker support for CRP. Click “Next” The “Semihosting C Project” wizard for some parts provides two options for configuring the implementation of printf family functions that will get pulled in from the Redlib C library: Use non-floating-point version of printf If your application does not pass floating point numbers to printf() family functions, you can select a non-floating-point variant of printf. This will help to reduce the code size of your application. For MCUs where the wizard does not provide this option, you can cause the same effect by adding the symbol CR_INTEGER_PRINTF to the project properties. Use character- rather than string-based printf By default printf() and puts() make use of malloc() to provide a temporary buffer on the heap in order to generate the string to be displayed. Enable this option to switch to using “character-by-character” versions of these functions (which do not require additional heap space). This can be useful, for example, if you are retargeting printf() to write out over a UART – since in this case it is pointless creating a temporary buffer to store the whole string, only to print it out over the UART one character at a time. For MCUs where the wizard does not provide this option, you can cause the same effect by adding the symbol CR_PRINTF_CHAR to the project properties. For this example we will maintain as default. Having selected the appropriate options, you can then click on the Finish button, and the wizard will create your project for you, together with appropriate startup code and a simple main.c file. At this point you should be able to build and debug this project Writing my first project The LPCOpen Chip Library (in this case lpc_chip_15xx) contains the drivers for some LPC peripherals. For these examples, we will use the GPIO Driver. The LPCOpen Board Library Project (in this case lpc_board_nxp_lpcxpresso_1549) contains files with software API functions that provide some simple abstracted functions used across multiple LPCOpen board examples. The board_api.h contains common board definitions that are shared across boards and devices. All of these functions do not need to be implemented for a specific board, but if they are implemented, they should use this API standard. After create a new project using MCUXpresso and LPCOpen, it is created a simple C project where it is initialized the board and set the LED to the state of "On" using the Board_LED_Set function. In this example, we will toggle the a LED using a push bottom. In LPCXpresso1549 board le LEDs are connected to PIO1.1, PIO0.3 and PIO0.25 pins. And the SW1 to PIO0.17 pin. The function Chip_GPIO_SetPinDIRInput configures a pin as input.  The function Chip_GPIO_GetPinState gets a GPIO pin state via the GPIO byte register. The function Board_LED_Set set the LED to the state of "On" or “Off”.. Complete code (Set the LED using a push bottom).   /* ===============================================================================  Name        : LPCXpresso_new_example.c  Author      : $(author)  Version     :  Copyright   : $(copyright)  Description : main definition ===============================================================================  */   #if defined (__USE_LPCOPEN) #if defined(NO_BOARD_LIB) #include "chip.h" #else #include "board.h" #endif #endif   #include <cr_section_macros.h>     int main(void) {         bool State_Input;  #if defined (__USE_LPCOPEN)        // Read clock settings and update SystemCoreClock variable        SystemCoreClockUpdate();  #if !defined(NO_BOARD_LIB)        // Set up and initialize all required blocks and        // functions related to the board hardware        Board_Init();        Chip_GPIO_SetPinDIRInput(LPC_GPIO, 0, 17); //Set GPIO direction for a single GPIO pin to an input   #endif #endif          while(1) {                State_Input=  Chip_GPIO_GetPinState (LPC_GPIO, 0, 17);  //Get a GPIO pin state via the GPIO byte register                if (State_Input==0){                       Board_LED_Set(0, true); // Set the LED to the state of "On"                }                else  {                       Board_LED_Set(0, false); // Set the LED to the state of "Off"                }        }        return 0 ; }  

The OM13043 kit described below is no longer available (the LPC1227 and LPC1100XL devices are still available). This material is provided for reference materials, but KNX software is still available from Weinzierl Engineering. Building automation systems based on KNX communication protocols Communication is becoming essential in complex buildings. For this reason, NXP cooperates with Weinzierl Engineering to offer dedicated components to realize KNX based systems. A professional version of the KNX system B stack is now available on LPC Microcontrollers to allow a jump start with KNX development. System notes LPC1100XL and LPC1200 series microcontrollers: Based on the highly energy-efficient ARM® Cortex™-M0 processor Dramatically lower the cost per KNX node in home and building automation networks Cortex-M0 architecture ideally suited for low-complexity end nodes Include up to 128 KB Flash and 8 KB SRAM, and offer highly configurable peripherals Can be powered directly from the DC-DC converter of the KNX twisted-pair transceivers, making bus-powered devices easy to implement With performance levels up to 45 DMIPS, a single MCU delivers the resources required to run a KNX System B stack (up to 65535 nodes), with enough bandwidth available for the end application Reduced time to market – full professional stack available from partners with flexible license models A certified implementation of the KNX System B is available for the LPC1200 from Weinzierl Engineering  Implementation example (OM13042 demo board): Available with the NXP LPC1227 microcontroller and ON Semiconductor’s NCN5120 transceiver, suitable for use in KNX twisted pair networks (KNX TP1-256) Specifically designed to simplify design process with a ready-to-implement, energy-efficient KNX TP solution for applications such as lighting switches and control, HVAC control, shutters and occupancy detection Improves power efficiency, reduces development costs, accelerates time to market for KNX applications on ARM Cortex-M0 Application Note AN11231 is available here More information on KNX:  www.knx.org KNX TP Stack System B from Weinzierl Engineering - The new dimension of KNX development Each KNX device is based on a device model, that specifies both the management procedure (that is, how the device is configured via the bus) and identifies the resources available to the device (for example, the maximum size of the connection table). System B (mask version 07B0) is a new device model that has been defined specifically for the implementation of complex KNX devices. The main advantage lies in the number of available communication objects. While previous devices models were limited to 255 objects or less, System B theoretically permits up to 65,535 communication objects. To achieve this, the formats of the communication tables (group address, association and group object tables) have been redefined in the KNX specification for System B. System B devices can update their communication objects at system startup. This function is called Read-On-Init and can be activated individually for each object. Once the application is started the system software sends group read-value services independent from the application task. These services are scheduled by the stack to ensure that the bus is not excessively loaded at startup. System B also offers a greatly increased address space. The configuration data (application, parameters and tables) can be loaded into a range of up to 1 MB (20-bit addressing) via the bus (using memory services). To access system parameters, additional properties in the interface objects of the system have been introduced. System B is supported by the ETS manufacturer tool MT4, by ETS3 andETS4. Implementation for optimal performance Weinzierl Engineering as a KNX system supplier offers a new implementation for KNX System B, specifically targeted at complex devices with a 32-bit architecture like the Cortex M0 from NXP. It includes a complete implementation of the specification and is optimized to ensure high performance for all application sizes. A major consideration in the development of System B is the timely (real-time) processing of the large association table, which contains the assignment of group addresses to the communication objects and vice versa. It is loaded by ETS and is not sorted. For a table length of more than a thousand entries, linear search algorithms are not effective and therefore additional look-up tables have been introduced that allow quick access via indices. The processing of the communication objects has also been accelerated and a linear search through all objects is avoided with the use of additional buffers. Although these design features may require additional memory, they facilitate low CPU clock speeds. Higher performance is achieved at the same frequency with than with previous implementations with considerably reduced KNX resources. The System B implementation from Weinzierl Engineering uses a virtual address space that is resolved at the driver level and mapped to the corresponding physical storage areas. This means that applications are easily ported to different platforms. As for all Weinzierl's stack implementations, the focus is to ensure ease of application development. The application interface has been largely maintained and is accessible via comprehensive API functions. It is possible to implement either internal or external applications. An internal application is bundled together with the stack in the device and the ETS simply has to load the parameters and tables, which ensures quick download times. An external application is loaded by the ETS along with the parameters and tables. The stack also supports additional interface objects (user properties). These objects can be used, for example, to set device parameters using point-to-point communication on the bus. ETS parameters can also be realized with Properties. For the creation of the product data base with ETS MT4 (Manufacturer Tool) our bus monitor and KNX development tool Net'n Node has been extended with a new export function. After importing the data of the software project it directly generates an XML file that contains all the storage areas, load controls and binary application data. This XML file can be imported directly into the MT4 solution.

LPC4088 Closed Payment Loop Demo - Running the demo Directly after programming the FLASH has finished, or after power-up, the demo is ready to use. The following screen will be presented: In order to use the demo, first the Mifare Classic card must be initialized. This can be done by holding the card in-range of the RFID antenna and pushing the center button of the Embedded Artists base-board. If successful, a confirmation message is shown for half a second. Next, credit must be added to the card. This is done by again holding the card in-range of the RFID antenna, but now pushing the joystick to the top-position (towards the edge of the board). Every time the joystick is pushed to the top-position, $10 will be added to the card. If successful, a confirmation message is shown for half a second after pressing the joystick. The credit can be queried by pressing the "Query Card" button. Now that the card is initialized and charged, products can be purchased. By pushing the product-buttons in the 3x3 grid, products can be selected. Every time a product is selected, it is added to the listbox and the total cost is updated. Upon pressing "Checkout", the credit available on the card is read-in, the total cost is subtracted and the new credit is written back to the card. A confirmation of this action will be shown.

#lpc5410x‌ #fifo‌ #timeout‌

#lpc5410x‌ #fifo‌ #timeout‌