Manual

Chapter 11. Porting Guide
3. Real-time clock interrupts drive the eCos scheduler clock. Many embedded CPUs have an on-core timer (e.g.
SH) or decrementer (e.g. MIPS, PPC) that can be used, and in this case it will already be supported by the
architecture/variant HAL. You only have to calculate and enter the proper CYGNUM_HAL_RTC_CONSTANTS
definitions in the platform CDL file.
On some targets it may be necessary to use a platform-specific timer source for driving the real-time clock.
In this case you also have to enter the proper CDL definitions, but must also define suitable versions of the
HAL_CLOCK_XXXX macros.
4. Interrupt decoding usually differs between platforms because the number and type of devices on the board
differ. In plf_intr.h (ARM: hal_platform_ints.h) you must either extend or replace the default
vector definitions provided by the architecture or variant interrupt headers. You may also have to define
HAL_INTERRUPT_XXXX control macros.
5. Caching may also differ from architecture/variant definitions. This maybe just the cache sizes, but there can
also be bigger differences for example if the platform supports 2nd level caches.
When cache definitions are in place, enable the caches on startup. First verify that the system is stable for
RAM startups, then build a new RedBoot and install it. This will test if caching, and in particular the cache
sync/flush operations, also work for ROM startup.
6. Asynchronous breakpoints allow you to stop application execution and enter the debugger. Asynchronous
breakpoint details are described in .
You should now have a completed platform HAL port. Verify its stability and completeness by running all the eCos
tests and fix any problems that show up (you have a working RedBoot now, remember! That means you can debug
the code to see why it fails).
Given the many configuration options in eCos, there may be hidden bugs or missing features that do not show up
even if you run all the tests successfully with a default configuration. A comprehensive test of the entire system
will take many configuration permutations and many many thousands of tests executed.
Hints
• JTAG or similar CPU debugging hardware can greatly reduce the time it takes to write a HAL port since you
always have full visibility of what the CPU is doing.
• LEDs can be your friends if you don’t have a JTAG device. Especially in the start of the porting effort if you
don’t already have a working ROM monitor on the target. Then you have to get a basic RedBoot working while
basically being blindfolded. The LED can make it little easier, as you’ll be able to do limited tracking of program
flow and behavior by switching the LED on and off. If the board has multiple LEDs you can show a number
(using binary notation with the LEDs) and sprinkle code which sets different numbers throughout the code.
• Debugging the interrupt processing is possible if you are careful with the way you program the very early
interrupt entry handling. Write it so that as soon as possible in the interrupt path, taking a trap (exception) does
not harm execution. See the SH vectors.S code for an example. Look for cyg_hal_default_interrupt_vsr
and the label cyg_hal_default_interrupt_vsr_bp_safe, which marks the point after which traps/single-
stepping is safe.
225