This techerature is on ARM Cortex-M3 based system design. Most of
the things applies to ARM Cortex-M4 processor as well. Howver
the list of I/Os which are describled below are taken from Cortex-M3
processor is available to download free of charge from ARM Design
The Cortex-M3/M4 are one of the most popular choices on
Microcontrollers. The M4 is suited for application which require DSP
processing, and it offers an optionnal Folating Point Unit (M4F).
Use of thes processors are also common in small SoCs such as IoT
SoCs, Audio SoCs, WiFi SoCs, BlueTooth SoCs etc.
However irrespective of whether these are being used in
Microcontrollers or SoCs, the integration issues are constant.
This techerature first gives a very breif overview on these
processors and their features, and then considers the pinout of
Cortex-M3 processor, defining the function/use of each and every I/O
and how the I/Os needs to be connected or used in a system. This
will enable the user to integrate a Cortex-M3 processor in a system
they wish do design.
Cortex M3/M4 are low power low gate cound 32 bit processors. Both
processors have 3 AHB Lite interfaces, Namely the ICODE, DCODE and
SYSTEM bus. A fourth interface/Bus called the Private Peripheral Bus
is also present, but this is for processor's internal use.
A AHB-AP (AHB Access Port) is present to allow debugger accesses.
A WIC interface for power management features.
1. Power domain
// Isolate core power domain
// Retain core state during power-down - unused
The above 2 signals are as the name suggest related to power
domains for the cortex m3 processor.
If the Cortex-M3 does not implement any power domains, these are
to be left floating. These wont be connected to anything in the
RTL hence they will be removed by the synthesis tools.
While ISOLATIONn is used for activating the 'Isolation cells' in
the design, the RETAINn signal has to do with 'retention' of the
states of the flops inside the Cortex-m3 core, when the power
domain inside which the cortex-m3 resides has been shut down.
More on the power
managemnt of ARM Cortex M4 processor can be found here. The
M3 is quite similar to M4, so from power perspective, the M4
principles would apply to M3 as well.
2. Serial Wire Debug Signals:
// Test reset
// Test Mode Select/SWDIN
// Test clock / SWCLK
// Test Data In
CDBGPWRUPACK; // Debug power
3. RESET Signals:
// PowerOn reset
This is the main reset to the cortex-m3. It should reset
everything in the processor including the debug logic.
// System reset
This resets the cortex-m3 core except the debug logic. It is
possible to access the 'System-Bus' of the cortex m3 processor
while PORESETn is not asserted and SYSRESETn is asserted via the
This is of significant importance becasue even when this reset is
asserted, a path from external debug port to the memory is
possible via the DAP_AHB_AP. This will enable the debugger to
download the code into the system's RAM, while the processor is
still held in RESET. This is important for multi-processor system,
where this cortex-m3 processor is not the boot processor, and it
does not have a ROM. In this situation, the boot-code has to be
copied into its RAM before the processor can boot.
Now during development, the user may want to copy code to the
system's ram using debug port.
While the development process is over, even then, the code copy
into the system's RAM will be done, while the SYSRESETn is held
asserted, while de-assertion of PORESETn will and should enable
the path from external system bus to the RAM so that the boot code
may be copied to the RAM.
If the SYSRESETn is not asserted, then the processor starts to run
un-controlably while there isn't any valid code in the RAM.
In later CPUs, ARM introduced a new port on the processor called
CPUWAIT to hold the processor from running un-controlably while
there isn't any valid code in its boot ROM.
// Reset Bypass
This is to help DFT, i.e. design for test. While the chip is
tested for production, it is essential for the tester to have full
control over the functional resets, internally generated resets,
and clocking gating logic. This is to allow the tester to scan
patterns in and out of the scan chains, and for this it is
essential that every flop inside the design is out of reset, and
every flop gets the clock.
This signal when set to '1', will and should bypass any internally
// Architectural clock gate bypass
For the reason describled above, this signal will enable any
clock-gating for the purpose of Scan-testing.
4. CLK Signals
// Free running clock
This is the always-on clock on the M3/M3 based sub-system. The
frequency of this clock can be reduced, when the processor is
sleeping. The WIC usually works on this clock, hence this clock
should be ticking to allow the processor to wake-up using
// System clock
This is the clock that clocks most of the M3/M4 processor
internals. This can be gated, when the processor is in sleep mode.
HCLK MUST be derived from FCLK.
TPIU trace port clock
5. System Tick Clock And System Timer Signals:
// System Tick clock
// System Tick calibration
SYS TICK timer provide periodic pulses. Usually these pulses are
used by RTOS for time slicing
Systick is an internal timer inside the processor.
It can either count on the processor's FCLK or it can count on a
clock supplied on
the pin STCLK. This STCLK must be slower than the FCLK so that
FCLK can sample it easily.
Internal to the processor the STCLK signal is synchronised using
The ARM document says that you need external synchronisation of
STCLK before use but that is
not true. There is no need to synchronise it external to the
The STCALIB is a calibration count value for counting 10ms on
6. Auxiliary Fault Status Register
// Auxillary FSR pulse inputs
This input directly maps to 32 bits of Auxiliary Fault Status
This signal is used to provide user specified information to the
The software will ead the Auxiliary fault status register, and
since these bits map to this register,
there exists a possibiliy for the system to provide any
information to the software.
7. ENDIAN Ness signal
// Static endianess select
This input pin is sampled at reset and stored in Interrupt and
Reset Control Register Bit .
1 => big endian
0 => Little endian
8. Interrupt signals:
// Non-maskable Interrupt
9. ICODE Bus Input Signals
These signals are the AHB-Lite signals for the ICODE bus from
This is a read-only bus, and can only access memory region
0x0000_0000 -> 0x1FFF_FFFF
Code fetches are performed on this bus. The following are ICODE
bus Input siganls.
// Code (instruction & literal) bus
// ICode-bus ready
// ICode-bus read data
// ICode-bus transfer response
// ICode-bus buffer flush
11. DCODE Bus Input Signals:
These signals are the AHB-Lite signals
for the DCODE bus from the processor
It can access memory region 0x0000_0000 -> 0x1FFF_FFFF
Data fetches are usually performed on this bus. The following
are DCODE bus Input siganls.
// DCode-bus ready
// DCode-bus read data
// DCode-bus transfer response
// DCode-bus exclusive response
13. SYSTEM Bus Input Signals
// System Bus
// System-bus ready
// System-bus read data
// System-bus transfer response
// System-bus exclusive response
14. Receive Event Input
// Wait for exception input
This input signal is typically used in multi-processor system.
This wakes the processor up, if the processor has executed WFE
instruction before going to sleep.
This signal makes sure that if one processor wakes up, all
processors are woken-up. The first one to wake up will emit a
signal called TXEV (Transmit Event) this will be connected to
another processors's RXEV. In a system with only 1 processor RXEV
can be tied to '0'.
15. Extend Sleep Signal.
SLEEPHOLDREQn; // Hold core in sleep
This signal helps the processor to be in extended sleep mode, when
SLEEPING output signal from the processor is asserted.
This is the part of the handshaking pair of signals SLEEPHOLDREQn
Following a wake-up event, while the SLEEPING is de-asserted, the
SLEEPHOLDREQn can be kept asserted by the system to 'extend' the
sleep till the point the processor or the processor sub-system is
ready to wake up.
This provides the user time to do 'things' following a wake-up
event, before the processor starts to run.
16. Debug Req/Start Signal.
// External Debug Request
// Debug Request
EDBGRQ, when asserted, will halt the processor at the next
Its typical use is in multiprocessor systems, to enable proessor
halting, it there is debug event in another processor. However if
coresight infrastructure is used, then this halting is done using
CTI (Cross Trigger Interface), and in that case this signal can be
tied to '0'. This signal is tied to '0' in a single processor
system as well.
External Debug Restart request
DBGRESTART is kind of just the opposite of EDBGRQ. When this
signal is asserted, the processor is taken out of Halted state.
Again its typical use is in mutiprocessor system to ensure that
all the processors comes out of HALTED state simultaneously. Again
if CTI is being used in muliprocessor systms OR if it is a single
processor system, this can be tied to '0', and the complimentry
output signal DBGRESTARTED can be left unused.
17. Master ID signal
// DAP HMASTER override
FIXMASTERTYPE; // Override HMASTER
for AHB-AP accesses
This signal can override the the values on signals HMASTERD (DCODE
bus) and HMASTERI (ICODE Bus).
When this signal is set to '1', the accesses from the debugger is
always issed with HMASTERD and HMASTERI value of '1'. When this
signal is '0', the HMASTERD and HMASTERI takes values as defined
by software using the CSW (Control and Status Word).
With this set to '1', the accesses reflect true owner of the
18. WIC enable signal
// WIC mode Request from PMU
For the WIC to come into action, before the processor goes to
sleep, the WIC operation must be 'enabled'
This is done by the pair of signals WICENREQ & WICENACK.
The PMU will generate this request, and the processor will confirm
by asserting WICENACK.
This merely means an 'agreement' that the next time processor goes
to sleep WIC related action will take place.
This pin can be tied permanently to '1' (and WICENACK left unused)
to make sure that all the sleep requests are WIC mode sleeps, i.e.
the WIC related actions are taken for every sleep entry/exit.
19. Global Timestamp value.
// Timestamp intereace
// Binary coded timestamp value
This signal is used as a binary count value of global timestamping
is needed. Otherwise it MUST be tied to all 0s.
20. Scan Enable Signal.
// Scan Enable
21. DEBUG related signals.
// Logic disable
Disable the MPU (act as default)
// Enable debug
// Enable non-invasive debug
22. Parallel/Sequential selection of ICODE And DCODE
// Tie-High if code mux is used
I/DCode arbitration control
This signal decides, if the ICODE and DCODE buses may be used in
IF this is tied to '0', the buses operate in parallel
IF this is tied to '1', the ICODE bus's HTRANS, ie. HTRANSI is
suppressed internal to the processor whenever there is a parallel
access from ICODE and DCODE.
// Test Data Out
// Test Data Out Enable
CDBGPWRUPREQ; // Debug power
// Single Wire
// SingleWire data out
// SingleWire output enable
// JTAG mode(1) or SW mode(0)
// Single Wire Viewer
// SingleWire Viewer Data
// TracePort Output
// TracePort clock reference
// TracePort Data
// HTM data
// HTM data HADDR
HTMDHTRANS; // HTM
// HTM data HSIZE
HTMDHBURST; // HTM
// HTM data HPROT
HTMDHWDATA; // HTM
HTMDHWRITE; // HTM
HTMDHRDATA; // HTM
HTMDHREADY; // HTM
// HTM data HRESP
// Code (instruction & literal) bus
// ICode-bus transfer type
// ICode-bus transfer size
// ICode-bus address
// ICode-bus burst length
// ICode-bus protection
// ICode-bus memory attributes
// DCode-bus master
// DCode-bus transfer type
// DCode-bus transfer size
// DCode-bus address
// DCode-bus burst length
// DCode-bus protection
// ICode-bus memory attributes
// ICode-bus exclusive request
// DCode-bus write not read
// DCode-bus write data
// System Bus
// System-bus master
// System-bus transfer type
// System-bus write not read
// System-bus transfer size
// System-bus address
// System-bus write data
// System-bus burst length
// System-bus protection
// System-bus memory attributes
// System-bus exclusive request
// Core Status
// Branch status
// Core is halted via debug
DBGRESTARTED; // External
Debug Restart Ready
// Lockup indication
// Core is sleeping
// System can enter deep sleep
SLEEPHOLDACKn; // Indicate core is
force in sleep mode
// Interrupt that is currently active
Interrupt activation status
// Trace Enable
// Current Int Priority
// Reset request
SYSRESETREQ; // System
// Event output
// Clock gating control
// when high, HCLK can be turned off
// WIC mode acknowledge from WIC
// Wake-up request from WI