FAQ: My application behaves incorrectly when using SDRAM.

Question:

My application has grown to a size where it is now too big for internal memory, so I am using SDRAM, I receive errors in the IDDE that 'External Memory is disabled for this region of memory', while the disassembly window shows 'Illegal opcode' errors. The code does not execute correctly any longer.

 

 

============================================

Answer:

When applications behave incorrectly during external memory access - either executing code, or reading/writing data - it may be that the external memory is not configured correctly. It may be that the code produces incorrect results, hits an exception or the PC appears to be in a random location in the Disassembly Window on halt. You may also encounter errors within the IDDE, such as the Memory Window/Memory Browser showing all contents as “0xDD” (Disabled), code sections showing “Illegal Opcode” in the disassembly window, or output in the console that “External memory is disabled for this region of memory”. There are some common pitfalls to be aware of.

 

 

Default Behaviour

When you connect to a target via a JTAG Emulator or Debug Agent, the default behaviour is that the Emulator will check a corresponding XML file to see if there is any configuration to be done of the EBIU/External Port/DDR. This feature is enabled/disabled via:

[VisualDSP++] “Settings: Target Options: Use xml reset values”

[CrossCore Embedded Studio] Under the "Custom Board Support" tab within the "Run: Debug Configurations" menu

 

 

This instructs the Emulator to check the corresponding XML file in "...\System\Archdef\"  within the VisualDSP++ installation directory for 'register reset definitions'.

e.g. "…\System\Archdef\adsp-bf561-proc.xml" for the BF561 in VisualDSP++

e.g. “...\System\Archdef\adsp-bf609-resets.xml” for the BF609 in CCES.

 

 

These XML files contain a section <register-reset-definitions> that specifies values that should be assigned to the external memory registers upon reset of the target. Note that the XML files only contain register reset values where there is a corresponding EZ-KIT Lite. i.e. as there is a BF533 EZ-KIT Lite, there are register reset definitions in "...\System\Archdef\adsp-bf533-proc.xml" in VisualDSP++.

 

 

However as there is no corresponding EZ-KIT Lite for the BF532 or BF608, for example, there are no register reset definitions in their corresponding XML files. These XML files provided with the VisualDSP++ and CrossCore Embedded Studio tools should not be modified, as they are liable to be overwritten. Additionally, these XML files work universally - that is, the BF533 XML file will affect all BF533 targets, so changes to make your custom board work correctly could lead to incorrect settings for an EZ-KIT Lite, or other third party/custom BF533 targets.

 

 

Custom/Third-Party Boards

When using a custom or third party board it is important to be aware that the Emulator will either apply the default EZ-KIT Lite external memory register settings, or make no configuration of the external memory at all. In both cases, access to external memory will be unreliable at best, and impossible in the worst case.

 

 

For custom and third party boards, we provide "Custom Board Support", which allows users to specify an XML file containing register reset definitions, to be associated with a specific Session. Attached is an example populated with the Blackfin BF527 EZ-KIT Lite Register Reset Definitions that can serve as a template.

 

 

Editing the Custom Board Support XML file

You will need to ensure that the document properties are correct; that the 'processor-family' matches your target (Blackfin, SHARC, or TigerSHARC), and that the 'file' name matches the name of the xml file.

 

 

[VisualDSP++ ]

<custom-visualdsp-proc-xml

     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

     xsi:noNamespaceSchemaLocation="\Program Files\Analog Devices\VisualDSP 5.0\System\ArchDef\ADSP-custom-board.xsd"

     processor-family="Blackfin"

     file="Custom_Resets.xml">

 

 

[CrossCore Embedded Studio ]

<custom-cces-proc-xml

     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

     xsi:noNamespaceSchemaLocation "\Analog Devices\CrossCore Embedded Studio 1.0.0\System\ArchDef\ADSP-custom-board.xsd"

     processor-family="Blackfin"

     file="Custom_Resets.xml">

 

 

Then, simply change the <register-reset-definitions> you require. It may be useful to copy the register reset definitions from a similar processor for which an EZ-KIT Lite exists (e.g. if you are using BF531, copy the definitions from adsp-bf533-proc.xml) as a starting point. Additionally, if the tools are not installed to the default path you will need to change the "noNamespaceSchemaLocation" path.

 

 

[VisualDSP++] In VisualDSP++ you can then associate the file with your session via 'Settings'->'Session'.

[CrossCore Embedded Studio] In CrossCore Embedded Studio you can associate the files with your session by going to the “Custom Board Support” tab for your Debug Configuration under ‘Run’->’Debug Configurations’.

 

 

We provide an EBIU Calculator, which can be used to determine the correct EBIU Register settings for your Blackfin target: http://ez.analog.com/docs/DOC-1441

 

 

For more information on Custom Board Support, xml structure and syntax please see:

[VisualDSP++] VisualDSP++ Help under ‘Help’->’Contents’->’Graphical Environment’->’Custom Board Support’.

[CrossCore Embedded Studio] CCES Help under ‘Help’->’Contents’->’CrossCore Embedded Studio 1.0.0’->’Graphical Development Environment’->’Tasks ’->’Running and Debugging Programs’->’Working with Launch Configurations’->’Configuring Custom Board Support’.

 

 

Other Common Issues

A common mistake when configuring the EBIU is not setting the PSSE bit within the EBIU_SDGCTL. This is the Power-up Sequence Start Enable bit, and ensures that – on the next access to SDRAM – the settings you have applied to the EBIU registers are executed to configure it appropriately. This bit always reads as ‘0’, but must be set whenever the EBIU registers are changed. This is detailed in the Hardware Reference Manuals.

 

 

Another common EBIU issue occurs when moving from debugging a DXE within the IDDE, to running your application stand-alone by building a loader file to be booted from an external source, e.g. Flash. Once the application is no longer being run within the IDDE, the Emulator, and therefore the XML files, are not in use and do not make any configuration of the EBIU.

 

 

Please be aware that you cannot modify the PLL values using an XML file. Programming of the PLL requires a PLL relock sequence to allow the clock to stabilize and lock to the new frequency, which cannot be done using the .xml file. Similarly, programming of the on-chip regulator initiates a PLL relock sequence when the processor reaches the programmed voltage level.