7/7/2016

Getting started with Nuvoton NUC140 32-bit ARM cortex-M0 Microcontroller

Getting started with Nuvoton

NUC140 32-bit ARM cortex-M0
Microcontroller
This blog presents articles on using KEIL and getting started with Nuvoton's NUC140 series 32 bit ARM cortex-M0
Microcontrollers. All these articles are based on Nuvoton's NUC140 EVM board. These articles are aimed at
helping/tutoring and sharing technical articles on programming the 32 bit microcontroller from Nuvoton. Please share
your comments and suggestions, if any (politely). The idea of this blog is learn from sharing knowledge so everyone can
benefit.

Wednesday, July 30, 2014

Know your chip on NUC140 EVM board

About Me

Rohit

My Photo

View my complete profile

The highlights of the NUC140 chip on the learning board:

All About your NUC140

1. Maximum supported CPU frequency via PLL is 50Mhz.

2. Maximum supported CPU frequency via external crystal is 24Mhz
3. Has inbuilt RTC with crystal of value 32.768Khz soldered to the learning board.
4. It can also run out of internal oscillator value of 22.1184Mhz.
5. Know your NUC140 series on your Learning board (EVM) of Nuvoton. The CPU name is
NUC140VE3AN*.

2014 (4)
July 2014 (1)
Know your chip on NUC140 EVM board
March 2014 (3)

NUC series in Nuvoton means it is a 32 bit microcontroller series.

1 in letter 140 means: It has 1 core only i.e. Cortex M0.
4 in letter 140 means: It belongs to the connectivity range.
0 in letter 140 currently does not hold any specific meaning.
V in VE3AN means: LQFP100 package
E in VE3AN means: 128KB APROM size
3 in VE3AN means: 16KB RAM size
A in VE3AN is reserved for future feature additions/revisions
N in VE3AN means: temperature range supported by chip is: -40C to +85C.
The chip is based on ARM v6-M architecture.
8. It has 128KB for Program FLASH, 16KB for SRAM, 4KB Data flash and 4KB of LDROM
(bootloader) and 76 IOs.
9. The page erase size of the dataflash is 512 bytes.
10. It has an inbuilt 12 bit resolution SAR ADC.
11. It has an inbuilt temperature sensor with an accuracy of +/-1 degree.
12. For the automotive line, it has support for BOSCH CAN 2.0 A/B and LIN support.
13. It has 4-32bit timers, 3-UARTs, 4-SPI channels, 2-I2C channels, 1-2.0v full-speed USB.
14.It has 8-16bit PWM channels and 2-Analog Comparators and 1-12S/AC97.
*There are other versions of NUC140 also available as per this ordering mechanism:

http://nuvotonnuc140.blogspot.sg/

1/7

7/7/2016

Getting started with Nuvoton NUC140 32-bit ARM cortex-M0 Microcontroller

NUC140 Hardw are chip orde ring options as provide d by Nuvoton

The nested vectored interrupt controller (NVIC) supports tail-chaining and late-arrival to assist in
developing true real time embedded applications.
Tail chaining is a method where the ISR, when it has executed and is about to return
back to the main method and is in the process of restoring the state of the registers, if
during that period another ISR occurs then the overhead of restoring and saving of the
state is reduced by directly allowing the NVIC to jump from one ISR to the other and
there by saving time in ISR overheads.
Late-arrival is a method where when one ISR is about to get executed (but not
started), if another higher priority ISR fires then the NVIC allows the higher priority ISR
to execute first there by eliminating any delay to allow the most highest priority ISR to
execute.

The CLOCK CONTROLLER of this chip:

It is very important to understand the variety of clock options provided by the controller
which clocks the various peripherals. It is hence important to understand the clock
options to calculate the clock signal timings.
Posted by Rohit at 11:07 AM

No comments:

Recommend this on Google

Labels: 32-bit ARM CortexM0, NUC140
Location: Ahmedabad, Gujarat, India

Monday, March 31, 2014

Embedded World's - Hello World - Toggling the GPIO.

Coding conventions followed in CMSIS:
1. All the data ty pes used in CMSIS is based out of stdint.h file. Data structures for core
registers are defined in the CMSIS header core_cm0.h file.
2. The core registers, peripheral registers and the CPU instructions follow capital
naming conv ention. Eg: NVIC->ISER[0], GPIOA->ISRC,
3. Peripheral access functions and interrupts use camel casing conv ention. Eg:
Drv GPIO_Open().
4. CMSIS allows C++ like commenting method (eg: // this is used for commenting.)

Finally , we are there on the m ain subject : Getting started!

So let us attempt to write our first ex ample for toggling GPIO (Embedded world's "HELLO
World" using Keil. It should be straight forward port for IAR and other tool chains, I guess
though I cannot comment on that much since I hav e not had an ex perience using them for
this controller.
Understanding the NU-LB-NUC140 board for the LED experiment:
The chip used on this EVM board is NUC140VE3CN. This board is powered by an external 12MHz
crystal as well as 32.768Khz crystal for RTC applications. In this experiment we will attempt our
first "Hello World" program by lighting up the LED for sometime and switching it off and continue
doing that. The LEDs on this EVM board are connected on GPIO-PortC on pins -12,13,14 & 15.
These LEDs are connected in SINK mode. Hence to turn on a LED you must place a ZERO on the
GPIO pin and to switch off you must place a ONE.

http://nuvotonnuc140.blogspot.sg/

2/7

7/7/2016

Getting started with Nuvoton NUC140 32-bit ARM cortex-M0 Microcontroller

NUC140 has 80 general purpose IOs.
80 IOs are arranged in GPIOA, GPIOB, GPIOC, GPIOD, GPIOE.
On reset all IO pins stay in Quasi-Bidirectional mode.
IOs as outputs can support source/sink capability.
First Step: Creating your project in KEIL:
1. Open KEIL -> New uVision Project -> <Select your custom folder> <select the chip as
NUC140VE3CN.
2. If asked for adding the startup file, please add to the project.
3. For simplicity, click on "File Extensions" icon in KEIL and create two sub folders apart from
source files folder. Name them as "Library" and "CMSIS" files. Move the files
"startup_NUC1xx.s" to "CMSIS" folder. Open the "File Extensions" folder and add
"startup_NUC1xx.c" and "core_cm0.c" files into the "CMSIS" folder.
1. The "core_cm0.c" file is found in the location <systemInstalledDrive>:\Nuvoton\BSP
Library\NUC100SeriesBSP_CMSIS_v1.05.003\CMSIS\CM0\CoreSupport.
2. The "startup_NUC1xx.c" file is found in the location:
<systemInstalledDrive>:\Nuvoton\BSP
Library\NUC100SeriesBSP_CMSIS_v1.05.003\CMSIS\CM0\DeviceSupport\Nuvoton\
NUC1xx
4. Add a main_gpio.c file to the "Source Files" folder. This is where your main() function will
reside and do all the necessary work.
5. As we studied in the earlier sections of CMSIS article, we will be using the library provided
Nuvoton to program the GPIOs via the nuvoton library wrapper for easy portability rather than
directly fiddling with the hardware registers. (Though it is perfectly fine if you wish to directly
fiddle around the hardware registers like you do for the conventional 8-bit microcontrollers. I
am using the Nuvoton library wrapper approach.
6. Since in this example we are going to set the GPIOs, we will first include the GPIO library
wrapper provided by Nuvoton by the name "DrvGPIO.c". This file is found in the location:
<systemInstalledDrive>:\Nuvoton\BSP
Library\NUC100SeriesBSP_CMSIS_v1.05.003\NuvotonPlatform_Keil\Src\Driver\
7. Since the clock control is handled by the file "DrvSYS.c". This file should also be included
similar to the "DrvGPIO.c".
8. It is important to let Keil's project settings know where your include library and core_cm0
headers files reside. Hence add the include paths by clicking on options for the project
settings >> C/C++ >> Include Paths and give the following paths in the following order:
./
../../../CMSIS/CM0/CoreSupport
../../../CMSIS/CM0/DeviceSupport/Nuvoton/NUC1xx
../../../Include
../../../Include/Driver
../../../Include/NUC1xx-LB_002
9. Then select in options for project settings >> Linker and add "--map -first='startup_NUC1xx.o(RESET)' --datacompressor=off --info=inline --entry Reset_Handler"
to Misc controls. Also untick "Use Memory Layout from target Dialog". (refer:
http://www.keil.com/support/man/docs/uv4/uv4_dg_adsld.htm)
10. One more setting to go, under Users, set "Run User Programs After build/rebuild"
1. Under Run1: Tick Run1 checkbox and argument as: fromelf --bin ".\obj\@L.axf" -output ".\obj\@L.bin"
2. Under Run2: Tick Run2 checkbox and argument as: fromelf --text -c ".\obj\@L.axf" -output ".\obj\@L.txt"
11. Create a folder as obj in the working directory and select this folder for your output dump in
Keil's project settings.
12. Now let us get to the action.
To set up the chip, first you need to select the clock input to your chip. In this case it could you
either internal oscillator or external crystal or PLL clock as per these configs:
E_SYS_CHIP_CLKSRC
Enumeration_identifier
Value
Description
E_SYS_XTL12M
0
Select External 12M Crystal
E_SYS_XTL32K
1
Select External 32K Crystal
E_SYS_OSC22M
2
Select Internal 22M Oscillator
E_SYS_OSC10K
3
Select Internal 10K Oscillator
E_SYS_PLL
4
Select PLL clock

Here is the main program:

#include "NUC1xx.h"
#include "Driver\DrvSYS.h"
#include "Driver\DrvGPIO.h"
void delay_loop(void)
{
uint32_t i,j;
for(i=0;i<10;i++)
{
for(j=0;j<60000;j++);
}

http://nuvotonnuc140.blogspot.sg/

3/7

7/7/2016

Getting started with Nuvoton NUC140 32-bit ARM cortex-M0 Microcontroller

}
int main(void)
{
//First set the clock input to the processor.
//The choices are internal clock or external crystal.
/* Unlock the protected registers */
UNLOCKREG();
//We will use the internal 22.1184Mhz
DrvSYS_SetOscCtrl(E_SYS_OSC22M,1);
//wait till the clock is stable
while (DrvSYS_GetChipClockSourceStatus(E_SYS_OSC22M) != 1);
/* HCLK clock source. 0: external 12MHz; 7:internal 22MHz RC oscillator */
DrvSYS_SelectHCLKSource(7);
/*lock the protected registers */
LOCKREG();
/* HCLK clock frequency = HCLK clock source / (HCLK_N + 1) */
/* Max divisor value: 0b1111 and min value: 0b0000 */
DrvSYS_SetClockDivider(E_SYS_HCLK_DIV, 0);
//Configure GPIO - GPC- pin 12 as output port pin. LEDS are connected on 12, 13, 14, 15.
DrvGPIO_Open(E_GPC, 12, E_IO_OUTPUT);
while(1)
{
DrvGPIO_SetBit(E_GPC,12);
delay_loop();
DrvGPIO_ClrBit(E_GPC,12);
delay_loop();
}
}
Compile, build and burn the hex file using Nuvoton's ICP programming tool and see the led
blinking. You can burn either the .hex file or the .bin file on the EVM board and check your
program.
Slight Tweaks for replacing the delay_loop() : Exploring System Tick - a 24bit Timer
available on ARM CortexM0.
Sy sTick prov ides a simple, 24-bit clear-on-write, decrementing, wrap-on-zero
counter with a flex ible control mechanism. It comprises of SY ST_CVR,
SY ST_RVR and SY ST_CSR registers.
SY ST_CVR is the Current Value Register while SY ST_RVR is the Reload Value
Register.
SY ST_CSR is the Sy stick timer control and status register.
Sy stick uses either the same CORE_CPU clock or any of the ex ternal clock. To use
the CORE_CPU clock, the v alue of bit named CLKSRC in SY ST_CSR should be
"ONE".
If CLKSRC in SY ST_CSR is "ZERO" then based on STCLK_S in CLKSEL0 register
decides the ex ternal clock speed to be used for SY STICK timer.
To replace the abov e delay _loop() , we made a new function:
void systemDelay(void) //1 sec delay if running out of 12Mhz.
{
//Considering 1tick = 12Mhz so for 1 sec, reload value = 12000000.
SysTick->LOAD = 12000000; //Reload value in register for SysTick for 1 sec delay
SysTick->VAL = (0x000000); //default value of SysTick Current value register.
//Switch on sysTick timer.
//System Clock source is (optional) external reference clock
SysTick->CTRL = (1<<SysTick_CTRL_ENABLE_Pos);
/* Waiting for down-count to zero . 16th bit in SYST_CSR */
while((SysTick->CTRL & SysTick_CTRL_COUNTFLAG_Msk) == 0);
}

One more important point to remember:

You cannot have systick timer source using a different clock source as compared to
the main system clock even though it is configurable. Meaning, if your CPU clock is
out of external crystal then you cannot select your systick to be coming out internal
oscillator at the same time, when I experimented on this board. (I thought it should be
possible!). Same way, if you ran the CPU over internal oscillator then trying to run the
systick timer clock to be running out of external crystal does not work.
I decided to use pre-processor directive for this reason as shown below. This code
should be part of the protected register write along with setting the CPU clock.

http://nuvotonnuc140.blogspot.sg/

4/7

7/7/2016

Getting started with Nuvoton NUC140 32-bit ARM cortex-M0 Microcontroller

#if CRYSTAL
DrvSYS_SelectSysTickSource(0);
#else
DrvSYS_SelectSysTickSource(7);
#endif

//Select External 12Mhz as the system Tick's clock

//Select Internal 22.1184Mhz/2 as the system Tick's

So the above code could be re-written to replace the delay_loop with systemTick timer in this
manner (main_gpio.c)
------------------------------------------------------------------------------------------------------------------------------Read more
Posted by Rohit at 6:22 PM

3 comments:

+2 Recommend this on Google

Labels: 32-bit ARM CortexM0, Hello World on NUC140, Toggling GPIO on a 32bit uC

CMSIS files for Nuvoton's NUC 140

Contents of the CMSIS file structure:
core_cm0.h : contains cortex -M0's global declarations & definitions as well as
static function definitions.
core_cm0.c : contains cortex -M0's global definitions.
<dev ice.h> [in this case: NUC1 x x .h] : Top lev el dev ice specific header file
containing dev ice specific bit definitions and structure/union definitions. This file
includes core_cm0.h and sy stem_NUC1 x x .h files. This file should be included
while writing application code.
sy stem_<dev ice>.h [in this case sy stem_NUC1 x x .h] : This file contains dev ice
specific declarations.
sy stem_<dev ice>.c [in this case sy stem_NUC1 x x .c] : This file contains dev ice
specific definitions like Sy stemCoreClockUpdate() and sy stemInit() calls.

Exploring the NUC1xx.h file :

In this file, the parameter _MPU Present 0 indicates there is no memory
protection unit while the other parameter __NV IC_PRIO_BITS 2 informs the
user that there can be max imum 2 priority bits to set.
The __V endor_Sy sTickConfig defined parameter has the default setting as 0.
When this macro is set to 1 , the Sy sTickConfig() function in the core_cm0.h is
ex cluded. If it is set to 1 then in that case file <dev ice>.h [here NUC1 x x .h] must
contain a v endor [Nuv oton] specific implementation of this function.

Com piler support built into CMSIS: Currently three main compilers are supported by
CMSIS namely , armgcc from ARM REAL v iew, iccarm from IAR EWARM and gcc from GNU
compiler collection. All the functions in the core peripheral access lay er are reentrant and
can be called from different interrupt serv ice routines. The ex ception handers are giv en a
suffix __Handler while the ex ternal interrupt handlers are giv en a suffix __IRQHandler.
Posted by Rohit at 4:04 PM

2 comments:

Recommend this on Google

Labels: NUC140, NUC140 Device interfaces

What is CMSIS?
CMSIS is an acrony m for Cortex

Microcontroller Software Interface Standard.

CMSIS is an abstract lay er that supports dev elopers and v endors in creating reusable
software components for ARM Cortex -M based sy stems. This lay er is useable for Cortex M0,M0+, M1 M3/M4 lay ers as well.

A brief glance into Cortex-M0,M0+, M1, M3 and M4 architectures:

Cortex-M0: The ARM Cortex -M0 processor is the smallest ARM processor
av ailable. The ex ceptionally small silicon area, low power and minimal code
footprint of the processor enables dev elopers to achiev e 32-bit performance at

http://nuvotonnuc140.blogspot.sg/

5/7

7/7/2016

Getting started with Nuvoton NUC140 32-bit ARM cortex-M0 Microcontroller

an 8-bit price point.
Supports 3-stage pipeline, thumb2, hardware-single-cy cle (32x 32)
multiply hardware.
Supports 1 NMI and 32 phy sical interrupts.
Has only 56 instructions and has 'C-friendly ' architecture.
Cortex-M0+: The ARM Cortex -M0+ processor is an adaption of Cortex -M0 but
with more improv ed performance and reduced energy footprint.
Supports 2-stage pipeline, thumb2, hardware-single-cy cle(32x 32)
multiply hardware.
Cortex-M1: The ARM Cortex -M1 processor is the first ARM processor designed
specifically for implementation in FPGAs.
Supports 3-stage
configuration.

pipeline,

thumb2

and

big

&

little

endian

Cortex-M3: The ARM Cortex -M3 processor is the industry -leading 32-bit
processor for highly deterministic real-time applications, specifically dev eloped
to enable partners to dev elop high-performance low-cost platforms for a broad
range of dev ices including microcontrollers, automotiv e body sy stems, industrial
control sy stems and wireless networking and sensors.
The Cortex -M3 NVIC is highly configurable at design time to deliv er up
to 240 sy stem interrupts with indiv idual priorities, dy namic
reprioritization and integrated sy stem clock.
Supports 1 NMI and 240 phy sical interrupts with 8 to 256 lev el
priorities.
Supports hardware div ide, single cy cle-multiply and saturated math
support.
Cortex-M4: The ARM Cortex -M4 processor is the latest embedded processor
by ARM specifically dev eloped to address digital signal control markets that
demand an efficient, easy -to-use blend of control and signal processing
capabilities.
Supports 3-stage pipeline with branch prediction and thumb2.
Supports hardware-div ide, 8/1 6 bit SIMD arithmetic.
Supports single precision floating point unit.
Supports Memory protection unit and deterministic operations.

Continuing further on CMSIS:

In order to reduce cost and software complexity and the fact that there are too rapid changes on
the technology front, CMSIS provides a uniform hardware abstraction layer that governs the way we
write and debug software by ensuring software re-useability.
CMSIS structure consists of three layers:
1. Core peripheral Access Layer (CPAL)
2. Middleware Access Layer (MAL)
3. Device peripheral Access Layer (DPAL)

CMSIS f unctional Flow (Courtesy: https://w w w .doulos.com)

http://nuvotonnuc140.blogspot.sg/

6/7

7/7/2016

Getting started with Nuvoton NUC140 32-bit ARM cortex-M0 Microcontroller

Functionality of each CMSIS layer:

Core Peripheral Access Lay er: This lay er is prov ided by ARM. The lowest lev el defines

addresses, and access methods for common components and functionality that ex ists in
ev ery Cortex -M sy stem. Access to core registers, NVIC, debug subsy stem is prov ided by
this lay er.
Middleware Access Lay er:This layer is defined by ARM, but is also adapted by silicon
vendors for their respective devices.The Middleware Access Layer defines a common API for
accessing peripherals.

Dev ice Peripheral Access Lay er:This lay er is prov ided by the silicon v endor and
contains the hardware register addresses and other dev ice specific access functions.

Posted by Rohit at 2:27 PM

No comments:

Recommend this on Google

Labels: CMSIS, Know ing CMSIS

Home
Subscribe to: Posts (Atom)

Search This Blog

Search

Copyright (C) 2014 Electronberry Solutions. Simple template. Powered by Blogger.

http://nuvotonnuc140.blogspot.sg/

7/7