Description:
A common problem when trying to debug a LatticeMico32 C/C++ project is an error message that reads:
"Check that the target FPGA contains an LM32 CPU with DEBUG_ENABLED equal to TRUE and that the FPGA has configured correctly."
This error message has several possible causes:
- FPGA preference file did not get implemented or has incorrect values
- The memory the LatticeMico32 Exception Base Address points to does not have valid opcodes, or the opcodes don't match the LatticeMico32 configuration.
- The LatticeMico32 core does not have the DEBUG_ENABLED set to TRUE.
- The LatticeMico32 core is not running.
- The reset input to the LatticeMico32 is asserted.
- The ISPVM_DIR environment variable is not set correctly.
- The LatticeMico32 being debugged is in a FPGA in a JTAG chain (supported in 7.0 SP2 and later)
- The processor is not running because the Wishbone ACK strobe is not being returned.
The first case is usually the most common cause of the inability to connect to the debugger. The FPGA preference files for the Lattice evaluation boards use a syntax referred to as
Consistent Bus Name Conversion. The two synthesis tools provided by Lattice use two different methods for naming a bus. In order to eliminate this issue ispLever can convert the bus names to signame_0_. By default ispLever uses the naming method for the synthesis tool defined by the project. The LatticeMico32 evaluation board preference files use the "consistent" naming convention. Thus if the
Consistent Bus Name Conversion feature is not turned on ispLever fails to assign bus signals to the FPGA I/O in locations requested. This issue is evident in the
Design Planner (Pre-Map) Tool or during the
Map phase.
To turn on
Consistent Bus Name Conversion right click on the "Build Database" tool, and make sure the
Consistent Bus Name Conversion entry is set to TRUE (7.0 and earlier), or Latttice (7.0 SP1 and later).
A properly configured
LatticeMico32/DSP Development Board for LatticeECP2 that uses a pre-configured platform definition like
Platform E will have all 8 LED's turned on. This is good visual evidence the FPGA pin assignments are correct.
Another reason this message may occur is that the memory the LatticeMico32 attempts to boot from has invalid or corrupted opcodes. The LatticeMico32 begins running opcodes at the Exception Base Address after the FPGA is initialized. If the opcodes at the Exception Base Address (EBA) are invalid it is possible the LatticeMico32 will put into an invalid state such that it will not respond to a Debug Exception. If it is unable to respond to the debug exception it is unable to get into the debug monitor code and can not respond to the GDB requests.
A fail-safe method during debug intensive sessions is to point the LatticeMico32 exception address to the base address of the LatticeMico32 debug memory. This memory is EBR and always has valid code in it. This eliminates the possibility of the LatticeMico32 executing corrupted opcodes and improves the chances that the debug session will start successfully.
The third cause denoted above can be easily verified from the ispLever log file when the FPGA bitstream image is being created. A design that has the DEBUG_ENABLED flag asserted will have a jtagconn16 component and a lm32_monitor_ram component added (among others). Search the Automake.log output for these components to make sure they have been inserted into the LatticeMico32 core.
The fourth cause listed is a fundamental error that can be easy to make. The LatticeMico32 is a Wishbone compliant master. Therefore it needs to have a
clk_i input. If there isn't a clock input, the processor can't fetch and execute opcodes, and will be unable to execute any of the debug monitor code. The clk_i input should not exceed the maximum frequency of the design, as that will cause the LatticeMico32 to behave erratically.
The fifth case is also an easy mistake to make. Make sure the
reset_i input is not asserted high, thereby preventing the LatticeMico32 from exiting the reset state and running the debug monitor code.
The sixth possible problem is the ISPVM_DIR environment variable isn't set correctly. The LatticeMico32 System debugger requires access to some components from the ispVM System tool. Make sure the ISPVM_DIR environment variable points to a valid ispVM System installation. This is typically
/ispvmsystem.
The seventh issue revolves around having a chain of JTAG devices, and LatticeMico32 is embedded in an FPGA in the JTAG chain. In order for this feature to work the MSB Debug session must be provided information about the structure of the JTAG chain. This is done by launching ispVM and defining the devices in the JTAG chain. Once the chain has been defined use the File->Save feature to save the JTAG chain information as a XCF file. Make sure the XCF file name or the path to the file does not contain any blank spaces.
The eighth issue is also a common problem. The LatticeMico32 processor must be able to respond to debug exception requests. If the processor has been given an instruction to read from or write to a memory range that does not return ACK the LatticeMico32 will never terminate the memory transaction. If the memory transaction never terminates all interrupts, including the debug interrupt, go unprocessed.
Platforms that use EBR must be cautious about the memory range created. Platforms created using ispLever 7.0 SP2 and earlier require the memory range be 2^N in size. This limitation has been removed in newer versions of the LatticeMico System Builder tools. The boot firmware in all platforms attempts to clear the BSS data segment. This is the uninitialized data and stack area. If the BSS is linked to reside in EBR and the platform is affected by the 2^N size limitation the firmware attempts to clear the entire 2^N range. If the size of the memory is smaller than 2^N then the ACK strobe will not get returned, and the processor will be stuck in a never ending memory transaction. Debug exception requests go unfulfilled during this time, and will cause the Eclipse debug environment to fail to launch the debugger.