CS 452/652 Spring 2022 - Lecture 11
Jun 7, 2022
Please refer to Chapter 14 in
EP93xx User Guide
for further details.
transmit (TX): FIFO at least half empty (level)
receive (RX): FIFO at least half full (level)
RX timeout: FIFO not empty; no arrival for 32 bit time (level)
status: CTS changes (ignore other flags) (edge)
combined interrupt: ORed combination of all of the above
"UART Interrupt Identification and Interrupt Clear Register."
Interrupts @ VIC
not all interrupts addressable by VIC
get rest (or all?) through combined interrupt
In general, the hardware FIFO can reduce the interrupt rate for highspeed devices (with interrupt mitigation), and absorb small bursts of output without software buffering.
RX interrupt only triggered when FIFO half-full → 8 bytes
proper operation (try read before interrupt) will drain FIFO
however, up to 7 keystrokes could go unnoticed...
RX timeout interrupt after 4 bytes silence - how long?
115,200 bits/sec at 10 bits/byte ⇒ 1 byte ~ 87 usec
acceptable for keyboard interaction
UART1/train: ~20ms latency not acceptable
naive: wait for interrupt → action
more robust: wait for interrupt → check status → action → repeat
reorder: check status → action or wait for interrupt → repeat
actual reading/writing is done in user-level server?
remember possible infinite loop with level interrupt signals...
example: read (assume reader/buffer is present)
try read; done?
enable RX interrupt
RX interrupt arrives → disable (level signal)
similar for write, if data is available
For UART2 (screen/keyboard), it is assumed that the receiver device is fast enough to handle communication at channel speed.
UART1 provides explicit flow control signal for (potentially slow) train controller.
UART's 'TX ready' status only means the communication channel is ready.
Clear-To-Send (CTS) is a separate signal (separate wire) that the receiver asserts when it is able to receive
the next byte.
aside: another reason not to bother with FIFO for UART1...
check TX up (cf. TX interrupt)
check CTS up (cf. status interrupt)
status interrupt needs to be confirmed (edge signal)
expected order of events and actions is:
TX & CTS up → write → TX & CTS down → wait → TX & CTS up (repeat)
due to different internal clock rates at ARM board and Marklin controller:
TX & CTS up → write → TX down → TX up
→ CTS down → CTS up
i.e., TX might go back up
CTS goes down
a simple status check might send next command too early
need state machine (triggered by status interrupts) to track CTS state after send
An earlier description by Bill Cowan is available
minimum functionality in kernel!
servers - how many? your design
services requests from clients, notifiers, reader/writer?
might have to park clients
notifier handles interrupts/events
actual low-level read/write operations: in server, notifier, or separate task?
be aware of Section 14.4.19 - but I have not seen this - only with HDLC operation?
"regular" hosted environment (such as Linux)
hardware: special instruction, exception
write to code segment of process
breakpoint - write special instruction, handle exception
continue - rewrite original code, resume execution
single step - breakpoint at next instruction (or source code line)
example: see 'man ptrace' on Linux
otherwise: remote operation
gdb stub/server co-located with target
EP 9302: gdb stub in RedBoot
communication over serial link or network (TCP)
breakpoint implemented as undefined instruction: 'user defined function' (udf)
udf handler accessed via branch in
, destination in
udf handler invokes gdb stub
are not modified from reset defaults!
works for breakpoints/single-stepping kernel code (in SVC mode)
debug operation: run user tasks in System mode
⇒ breakpoints/single-stepping should work for most code
however, assignment submissions must run user tasks in User mode!!
EP 9302 reset does not wipe all RAM (only RedBoot memory) → use for post-mortem
gdb's 'disassemble' command disassembles arbitrary memory regions with
online disassembler at