User`s manual

Copyright © Quantum Leaps, LLC. All Rights Reserved.
QDK™
Renesas RX with HEW
state-machine.com/rx
(2-3) The idle LED (LED12 of the YRDKRX62N board) is toggled on and off each time through the idle
callback. Thus, a brighter LED indicates more idle time. A heavily loaded CPU will spend little or no
time in the idle loop and thus the idle LED would be dim. Note that in a release build, the CPU will
sleep most of the time, and the LED will be toggled only at the rate of the interrupts that wake up the
CPU. In a debug build variant, the CPU never sleeps, and the LED's intensity gives a good
indication of the idle task activity.
(4) The software-tracing code is conditionally compiled into the build when enabled at compile time.
When using QS, the trace data is sent out during idle loop processing. If the UART's Transmit Data
Register (TDR) is empty, this code calls a QSPY API to see if there is another byte of data to send
out the serial port.
(5) In release mode (no debugger) the CPU can be put to low-power sleep.
(6) The __wait_for_interrupt() intrinsic provided by the Renesas compiler simply inserts a WAIT
instruction to the RX CPU. (More advanced power management could be performed here; this port
only sleeps the CPU, and does not put any other peripheral in low-power mode).
NOTE: Even though the WAIT instruction is executed with interrupts locked (PSW[I] = 0),
the instruction re-enables interrupts (PSW[I] = 1) as the CPU goes to sleep. Thus, when
the CPU re-wakes, interrupts are already enabled.
(7) release build variant) or doing QSPY tracing, simply unlock interrupts (a requirement) before
returning.
4.3.5 Assertion-Failure Callback
As described in Chapter 6 of [PSiCC2], all QP components use internally assertions to detect errors in the
way application is using the QP services. You need to define how the application reacts in case of
assertion failure by providing the callback function Q_onAssert() . Typically, you would put the system in
a fail-safe state and try to reset. It is also a good idea to log some information as to where the assertion
failed.
The following listing shows the Q_onAssert() callback in the bsp.c file. The function locks all interrupts
and hangs in an endless loop. When executing the code from a debugger you can break into the code
and inspect the cause of the assertion by backtracking the call stack.
NOTE: This policy is only adequate for testing, but is not adequate for production release.
Listing 9: Assertion-Failure callback in bsp.c
void Q_onAssert(char const Q_ROM * const Q_ROM_VAR file, int line) {
(void)file; /* avoid compiler warning */
(void)line; /* avoid compiler warning */
QF_INT_DISABLE();
for (;;) {
}
}
4.3.6 The Startup Code (resetprg.c)
The startup code is traditionally provided in the file resetprg.c , which provides the definition of the
PowerON_ResetPC() reset vector. The standard starup code is adequate for QP, except that you should
remove switching the RX CPU mode to User, because the QP port is designed to execute in the
Supervisor mode.
21 of 32