ARM Technical Support Knowledge Articles

UV2 DEBUGGER AND TRISCEND E5 - OUTPUT FILE DOWNLOAD

Applies to: General Topics

Answer


Information in this article applies to:


QUESTION

When using uVision debugger with Triscend E5 DLL ( TE5_UV2.DLL ) for target debugging, what memory is used to download your code when you hit the start debugging session? Apparently there's no option to define what kind of memory I'm working with ( SRAM, internal, Flash, etc). How can I choose it?

ANSWER

The memory that your program is going to download is defined by a series of procedures that involve Keil uVision debugger and Triscend FastChip Device Link ( FDL ). The standard E5 debugging model that Triscend currently recommends to users is as follows.

#1 - Use FDL (or CSoC in command-line mode) to configure memory and then download the cfg file to the target.
#2 - Use uVision to start debugging ( triggering a code download ).

If the target memory is Flash, you must follow steps #1 and #2 every time you change your program and want to debug it. This is necessary, because uVision does not know how to program Flash memory.

If the target memory is SRAM, you must, at least for the first time, follow step #1. This is necessary because FastChip infers the correct E5 code and data mapper system register settings, which are not understood by uVision per se. Without step #1, your program may not even be able to fetch the first instruction properly after reset, as the code mapper may not be properly set up.

However, during subsequent iterative code development, you may download directly from uVision via te5_uv2.dll to SRAM. This should work in many cases. However, a bad program may disturb the code and data mapper settings inadvertently. When in doubt, do steps #1 and #2. When the target memory is Flash, and downloading (by selecting menu item Debug | Start/Stop Debug Session) causes "download verification" error(s), it is most likely that you are trying to download (a version of) a program that is not the same as the one already programmed in Flash. Again, the best way is to go through steps #1 and #2.

RESOLUTION

In order to avoid debugging problems, it is recommended to always follow step #1 and then step #2 for all target memories.

MORE INFORMATION

SEE ALSO

Article last edited on: 2004-06-30 11:10:48

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