ARM Technical Support Knowledge Articles

Using CT7TDMI + EB: Boot Monitor will not display in RVD 'StdIO' pane

Applies to: CT7TDMI, EB (Emulation Baseboard)

Answer

[New 14 November 2007]

Systems affected:

EB + CT7TMDI, any revision. All Boot Monitor versions. (v4.1.0 was the latest released at the time this FAQ was written).

Symptoms:

If one attempts to program the EB application flash memory using the Boot Monitor, running semihosted via RVD on an ARM7TDMI processor, the Boot Monitor fails to detect the presence of the debugger and will only output its prompt from the UART0 serial port on the EB. (It is necessary to run the Boot Monitor program 'semihosted' via the RVD 'StdIO'window in order to restore the Boot Monitor image into EB Flash memory if there is no existing image to boot from. This procedure is described in the 'Getting Started' section of the EB user guide.)

Cause:

The debug tools (RVI + RVD) fail to trap a call to the semihosting SYS_HEAPINFO function in the Boot Monitor's semihosting detect code. Since the debugger does not trap the SVC (formerly SWI) exception, the Boot Monitor's real SVC handler informs the semihosting detect code that no debugger is present. The Boot Monitor then outputs its prompt text on the UART0 serial port as it was designed to do.

The exact cause of the problem is a combination of three things:

  • The ARM7TDMI does not contain the dedicated 'vector catch' logic that is present on its successors. The absence of this hardware means that the debugger must use a breakpoint to trap the semihosting (SVC) exception.
  • Where it finds RAM, the debugger saves precious watchpoint unit resources by setting software breakpoints. This involves temporarily replacing the contents of RAM at the breakpoint location with a special value - 0xEEEEEEEE.
  • Before the Boot Monitor checks for the existence of the debugger, it copies code into the vector table, which obliterates the software breakpoint placed by the debugger when the code image was loaded into RAM. The debugger then cannot trap any semihosting calls made by the Boot Monitor.

Workaround #1

The simplest solution is to prevent the debugger from using any software breakpoints. This can be specified in the RVI Configuration. Note that this option is only available if using RVI3.0 or higher.

1.  The RVConfig utility should be invoked by selecting 'Configure' for the RVI connection in RVD's 'Connection Window' (Alt + 0 shortcut in RVD). Note that this option may be disabled when the debugger is connected to the target.

2. Change the 'Software breakpoint mode' setting to '1 - NONE' and save the configuration:

RVI Config dialog for disabling SW breakpoints (thumbnail) (Click on thumbnail for larger picture)

3. Reconnect the debugger to the target and reload the Boot Monitor image into target RAM (Ctrl + Shift + F5). You should now find that semihosting works and the Boot Monitor prompt is displayed in the RVD StdIO console.

After the Boot Monitor has been programmed into Flash, you should change the RVI configuration again so that 'Software breakpoint mode' is set to AUTO. Leaving software breakpoints disabled will limit the amount of useful debugging that can be done, since the ARM7TDMI only has two watchpoint units and each hardware breakpoint occupies one unit.

Workaround #2

If the above method is not viable, an alternative would be to set up a memory map in RVD so that it treats the vector table area as Read Only. This will achieve the same result - a hardware breakpoint will be used for the semihosting vector. This operation is described in some detail in the RVD user guide. This has the added advantage that the memory map can be left enabled permanently.

Attachments: img19017.jpg , 19016.png

Article last edited on: 2009-01-20 13:39:52

Rate this article

[Bad]
|
|
[Good]
Disagree? Move your mouse over the bar and click

Did you find this article helpful? Yes No

How can we improve this article?

Link to this article
Copyright © 2011 ARM Limited. All rights reserved. External (Open), Non-Confidential