Monday, December 11, 2017
   
Text Size
Knowledge Base
faq-icon.png ABTR-BDI Errors
Knowledgebase Articles
  • KB00026 - Error Msg - i386 architecture

    Question:
    I am getting a warning message

    Answer:
    I am trying to get the BDI Probe up and running. The basic configuration appears to be fine. I can telnet and also connect via GDB. These are the steps I used:

    detach
    target remote bdi:2001
    file armboot

    Then I get a warning message about i386 architecture conflicts

    The error message about i386 architecture means that either the elf file (armboot) is compiled for x86 architecture or more likely the GDB is configured for --target=i386-xxx-linux.

    Hits : 147
  • KB00032 - Error Msg - Check LSRL length failed

    Question:
    During startup, my BDI prompt gives me an error: "Check LSRL length failed" and eventually states that the target is not supported.  What should I do.

    Answer:
    Please contact Ultimate Solutions and confirm that the processor you're targeting is supported.

    It's also possible that the BDI is attempting to send JTAG messages to the processor too soon after releasing HRESET.  Try to add a wakeup delay line to the Target section, "WAKEUP 2000" for the BDI2000 and "WAKEUP 3000"

    Hits : 204
  • KB00011 - Error Msg - PPC Core timeout waiting for freeze during Startup

    Answer:
    One possibility is that the TST and HRESET are wired together in some manner causing some unknown behavior resulting in a timeout. For a PPC405 core, the BDI sets the HALT pin and the stop bit in the debug control register. Then the 405 should enter debug mode (freeze) but in this case it doesn't. For both these situations try to add a wake-up delay: WAKEUP 2000.

    If there is a watchdog timmer do not set the WAKEUP delay too high or you end up triggering a board reset. Also, check JTAG/Reset circuit and compare it to the diagram on page 5 of the manual.

    Hits : 400
  • KB00013 - Error Msg - JTAG instruction stuff overrun

    There are a few reasons this may be happening

    1.) This maybe caused by bad init list values in some PPC processors. Remove all the entries in the INIT list
    and add them in chunks at a time to figure out which value is causing this problem.

    2.) Also for a test try and boot up in "load only" mode instead of Agent mode and see if this error goes away.
    In the target section add "BDIMODE LOADONLY".

    3.) Try and disable Vector Catching and see if this error goes away. This error has been tracked to a combination
    of Vector Catching and bad TLB entrees in a 440gp target environment.

    Hits : 232
  • KB00043 - Error Msg - Target not supported or PVR not supported

    Question:
    On startup, the following error message appears: "Target not supported" or "PVR not supported"

    We recommend you contact your Ultimate Solutions to confirm that the processor is supported by the current firmware loaded to the BDI probe.

    Below are some known issues why your Freescale "COP" target may be getting this error message.

    If the board has an invalid HRCW then it will sometimes display error messages saying "Target not supported" or "PVR no supported ".  In the case of an MPC82xx target, pull the RSTCONF (Pin X.45 on TQM8260) pin high and bring up the board with a valid config file from the BDI Probe. Keep in mind to turn off the watchdog and adjust for the default IMMR which is now located at 0x00000000. You will then have to set up the config file to let you program a valid HRCW. You can flash uBoot into the TQM8260 to program a valid HRCW. The procedure to program a valid HRCW is different for different targets. Put RSTCONF low again and now the board should be working fine.

    If you are also getting the error saying, "Check LSRL Length Failed", then add a wakeup delay line to the TARGET section of the config file, "WAKEUP 2000". This error occurs because the BDI might try to initialize communications with the target too soon after HRESET is released.

    Hits : 184
  • KB00044 - Error Msg - Target stop failed or Check stopped state failed

    Question:
    On startup, I keep getting the message, "Target stop failed" or "Check stopped state failed"  What is my problem?

    Answer:
    During startup the BDI sets a hardware breakpoint at the Boot Vector. If you have a boot monitor on your board try and use STARTUP RUN in your config file and the BDI will not try and set a breakpoint and will bring up your boot monitor. There are a few reasons that you may be facing this error and they are listed below starting from the most common reason:

    1) If HRESET is not being asserted properly then you can end up with this error. Please make sure the reset circuit is set up correctly and that you can assert HRESET independently of TRST from JTAG. Also, noise and skew on the reset circuit can result in unpredictable errors; use an oscilloscope to determine that the reset circuit is free of noise and skew. If necessary, use 1K pull-up resistors on the HRESET and TRST line.

    2) In your config file, make sure that the BOOTADDR is defined at your boot vector.

    3) On COP targets, if there is a reset chip on your board or there is some reset delay then you might encounter this error because the BDI cannot assert HRESET and stop the board in time. Please try and add a POWERUP delay in your config file. Start with 1000 then keep adding in 1000 increments till you reach 10K. Alternatively if it is possible increase the speed of your processor.

    4) On 82xx targets you can also experience this error if your HRCW is not valid. Pull the RSTCONF pin high and initialize your board through the BDI config file, making sure to change the default IMMR to 0x00000000. This error should go away. Also adjust the clock frequency of the processor while you do this, it is possible this error will go away at certain frequencies.

    5) On PPC750 and MPC74xx targets it is important that the QACK pin on the processor is pulled low, otherwise the BDI cannot soft stop the target and the breakpoint at the boot vector will fail.

    6) Monitor your PowerPC processor and make sure it comes out of reset properly. If a hardware problem causes the MPX bus to hang, the PowerPC will hang and the BDI will not be able to stop it. As a test disconnect all devices from the MPX bus.

    7.) Monitor your power supply to the processor after the BDI is connected If it falls under the specified threshold then it can cause undetermined errors on your target resulting in erratic behavior while the BDI is trying to startup the processor.

    8.) If you also get a message saying ‘Check stopped state Failed’ then the PPC asserts the CKSTP_OUT line. The PPC tries to access the BootVector, but due to some memory access problem it can’t fetch any data. When this happens the PPC will enter the Check Stop State and will disable all clocks. You will have to try and debug and figure out why the PowerPC is entering the Check Stop Mode. The PQ2 brings in HRWC on D0-D7 then shifts them over at the pins so D0-D31 must be free and not tied high or low. Not following this will cause an incorrect HRCW being read by the processor causing a crash.

    Hits : 279
  • KB00076 - Error Msg - Cannot determine target architecture for CPU 112

    Question:
    I get this target server error when I try and connect to the BDI Probe using a PPC405 - “Cannot determine target architecture for CPU 112”


    Answer:
    Unfortunately WindRiver has changed the CPU type for 405 from 112 to 2001. Add the old CPU type of 112 to Tornado as follows:

    In /host/resource/target/architecturedb add:
    [CPU_112]
    cpuname = PPC405
    cpuFamilyName = PPC

    In hostresourcetclwtxcore.tcl add:
    set cpuType(112)                PPC405
    set cpuFamily(112)              ppc

    Hits : 110
  • KB00083 - Error Msg - Target stop failed or Check stopped state failed

    Question:
    On startup, I keep getting the message, "Target stop failed" or "Check stopped state failed"  What is my problem?

    Answer:
    During startup the BDI sets a hardware breakpoint at the Boot Vector. If you have a boot monitor on your board try and use STARTUP RUN in your config file and the BDI will not try and set a breakpoint and will bring up your boot monitor. There are a few reasons that you may be facing this error and they are listed below starting from the most common reason:

    1) If HRESET is not being asserted properly then you can end up with this error. Please make sure the reset circuit is set up correctly and that you can assert HRESET independently of TRST from JTAG. Also, noise and skew on the reset circuit can result in unpredictable errors; use an oscilloscope to determine that the reset circuit is free of noise and skew. If necessary, use 1K pull-up resistors on the HRESET and TRST line.

    2) In your config file, make sure that the BOOTADDR is defined at your boot vector.

    3) On COP targets, if there is a reset chip on your board or there is some reset delay then you might encounter this error because the BDI cannot assert HRESET and stop the board in time. Please try and add a POWERUP delay in your config file. Start with 1000 then keep adding in 1000 increments till you reach 10K. Alternatively if it is possible increase the speed of your processor.

    4) On 82xx targets you can also experience this error if your HRCW is not valid. Pull the RSTCONF pin high and initialize your board through the BDI config file, making sure to change the default IMMR to 0x00000000. This error should go away. Also adjust the clock frequency of the processor while you do this, it is possible this error will go away at certain frequencies.

    5) On PPC750 and MPC74xx targets it is important that the QACK pin on the processor is pulled low, otherwise the BDI cannot soft stop the target and the breakpoint at the boot vector will fail.

    6) Monitor your PowerPC processor and make sure it comes out of reset properly. If a hardware problem causes the MPX bus to hang, the PowerPC will hang and the BDI will not be able to stop it. As a test disconnect all devices from the MPX bus.

    7.) Monitor your power supply to the processor after the BDI is connected If it falls under the specified threshold then it can cause undetermined errors on your target resulting in erratic behavior while the BDI is trying to startup the processor.

    8.) If you also get a message saying ‘Check stopped state Failed’ then the PPC asserts the CKSTP_OUT line. The PPC tries to access the BootVector, but due to some memory access problem it can’t fetch any data. When this happens the PPC will enter the Check Stop State and will disable all clocks. You will have to try and debug and figure out why the PowerPC is entering the Check Stop Mode. The PQ2 brings in HRWC on D0-D7 then shifts them over at the pins so D0-D31 must be free and not tied high or low. Not following this will cause an incorrect HRCW being read by the processor causing a crash.

    Hits : 382
  • KB00097 - Error Msg - step time out detected

    Question:
    During debugging the BDI displays a message saying “step time out detected”. I cannot single step anymore.

    Answer:
    The reason for this is that at some point during your board bring up the Debug Handler gets overwritten by your code.

    Go into your config file [TARGET] section and change the debug handler location to point to a location in the MINIIC that is not being used by your code.

    For instance if you set the debug handler to 0xffff0000 in your MINI IC then try and boot Linux, this location is the location of your high Vector Tables and at some point during kernel bootup the Vector Tables are written. When this happens the Debug Handler is over written and the step timeout message occurs.

    Hits : 172
  • KB00091 - Error Msg - writing to workspace failed

    Question:
    Error Msg - “writing to workspace failed” at the BDI Probe prompt when we have disabled the workspace by writing 0xffffffff to it?

    Answer:
    Disable the vector catch and this error message will go away.

    Hits : 456
  • KB00070 - Error Msg - JTAG instruction stuff overrun

    When in debug mode the PPC4xx fetches normal PPC instructions from the JTAG port. The error "# PPC: JTAG instruction stuff overrun" is raised when the processor stops fetching from the JTAG port, possibly because the processor hangs at an un-terminated memory transfer.

    1.) During processor startup this may be caused by bad init list values in some PPC processors. Remove all the entries in the INIT section from your BDI config and add them in chunks at a time to figure out which value is causing this problem.

    2.) For the PPC440 we need valid TLB before you can access memory, so you will need at least the TLB setup in the config file. Not having these in the config file can result in this error.

    For a 440GP use: ; Setup TLB WTLB 0xF0000095 0x1F00003F ; Boot Space 256MB WTLB 0x00000098 0x0000003F ;SDRAM 256MB @ 0x00000000

    For a 440GX use: ; Setup TLB WTLB 0xF0000095 0x1F00003F ;Boot Space 256MB WTLB 0x00000094 0x0000003F ;SDRAM 256MB @ 0x00000000

    For a 440EP use: ; Setup TLB WTLB 0xF0000095 0x0F00003F ;Boot Space 256MB WTLB 0x00000094 0x0000003F ;SDRAM 256MB @ 0x00000000

    3.) Also for a test try and boot up in "load only" mode instead of Agent mode and see if this error goes away. In the target section of the BDI config file, add "BDIMODE LOADONLY".

    4.) You can try and use mode STARTUP RUN in the [TARGET] section. This lets your boot loader bring up the target board. If the board comes up and runs as expected then recheck the values in the [INIT] list with those set by the bootloader and make sure you are not setting a register value that is causing your hardware to hang.

    5.) Try and disable Vector Catching and see if this error goes away. This error has been tracked to a combination of Vector Catching and bad INIT entries in a 440gp target environment. Keep in mind that the 440gp needs to have the TLB's setup before it can access memory.

    6.) If you also get a message saying "*** TARGET: core#0 startup failed" before the instruction stuff error, then some device on your external bus is not letting your PPC go through its startup sequence correctly. Make sure none of the devices on your board are arbitrating for the external bus while you are booting up the PPC4xx.

    7.) Similarly the PPC fetches the first instructions from the bootrom. If the bootrom is not configured correctly, the 440 can get stuck and not go through the startup sequence. Please make sure the bootrom is working normally and has a valid programmed HRCW. Test by disconnecting the BDI and seeing if the board is booting up correctly. Also, check the clocking and reset to make sure the 440 core is working as expected.

    8.) If this error happens during debugging or program execution always remember that the BDI is reacting to what is happening on your processor. Something has happened that has caused your target memory controller to stop taking in new memory transfers. Trying to debug the BDI will distract you from finding the problem that resides on your target system.

    Hits : 390
  • KB00080 - Error Msg - # SAP: read access failed

    Question:
    Why do I get this “# SAP: read access failed” error from the BDI?

    Answer:
    First of all make sure that your debug entry cause is not as this would indicate a more serious startup issue. Please check our Knowledgebase repository for the proper KB Areticle on this subject.

    1.) Access to invalid memory areas will always result in this error message. Please check if the memory area that you are accessing is valid/accessible and has been setup properly in your config file.

    2.) If access to flash, Ram and IMMBAR space result in this error but your startup seems to be fine then a missing clock to the DDR controller could be the fault. Also please be sure to check that all clocks are working and connected on your board.

    3.) If the RCW is not setup properly on your boards flash or in the BDI2000 config file then you will get this error. Make sure that the System Flash port size is specified properly and the memory timings are valid.

    4.) If you set up the data cache with a DBAT for a dcashed area without any memory behind it you will not be able to dump that dcache memory. Trying to do so you will result in a “SAP: Read access error”. Via JTAG (SAP) we always access real memory. The SAP is like an additional bus master that can access memory. The SAP accesses are snooped by the core/cache so the L1 caches are kept coherent. But there has to be real memory behind an address, otherwise the access will fail.

    To look at the cache content use Telnet "dcache" command:

    BDI> dcache 0xe4000000

    A hidden feature for MPC83xx is, that you can force the BDI not to use the recommended SAP for a memory accesses. Then it will use the core to access memory. With "sap 0" at the Telnet you can disable SAP access. Then the BDI accesses directly cache content. With "sap 1" you can enable SAP accesses again.

    Hits : 635
  • KB00023 - Error Msg - Can't open file on host TFTP Server

    Question:
    I am having trouble opening a file on my host TFTP Server.  What could be my problem?

    Answer:
    You will get this error when the BDI tries to access a file on the TFTP server and the file either does not exist or it cannot communicate with the TFTP server.

    1.) In your config file when you define the file in question, make sure you use the absolute path of the file if your host system is running Windows. For Linux, use the path from the TFTPBOOT directory.

    2.) In the [HOST] section of the config file please make sure that the IP address points to the computer where the TFTP server resides.

    3.) The file needs to exist and have the proper write permissions before the BDI can access it using TFTP.

    4.) When using the TFTP server on windows please use the "w" option to enable write access to the TFTP server.

    5.) Make sure that your firewall has been disabled to prevent the firewall from blocking the communication between the BDI and the TFTP server.

     

    Hits : 534
  • KB00021 - Error Msg - Cannot connect to BDI Loader

    Question:
    When I try to connect to the BDI2000/3000, I get an error stating "Cannot connect to BDI Loader"  How do I resolve this issue?

    Answer:
    The BDI setup utility has been run on countless Windows and Linux systems succesfully. There are no known issues with the setup utility that may cause the connection to be refused. If you are having problems connecting you should check and see if your environment is setup correctly.

    1. Make sure you have the cabling attached securely.

    2. Please make sure you are using the serial cable provided to you by Ultimate Solutions as the serial cable is not necessarily a pass thru serial cable and programming of the firmware may fail or the connection may not work.

    3. Make sure are using the right COM port.

    4. Make sure you have no conflict on the COM port.

    5. Make sure you don't have a terminal monitor tying up the com port in any way, quit HyperTerminal or minicom if it is open.

    6. Make sure the Target JTAG cable or the Ethernet cable is not connected to the BDI as it can interfere with the serial port.

    7. If you have defined SIO in the config file then connecting to the Setup Utility will fail. Disable this feature in the config file or disconnect from the LAN, then reboot the BDI.

    8. Check the BDI LED codes to make sure the BDI is operating correctly. (See KB00021 for more details).

    Hits : 315
  • KB00085 - Error Msg - Cannot open file on host

    Question:
    Error Msg - "Cannot open file on host"

    Answer:
    You will get this error when the BDI tries to access a file on the TFTP server and the file either does not exist or it cannot communicate with the TFTP server.

    1.) In your config file, when you define the file in question, make sure you use the absolute path of the file if your host system is running windows. For Linux, use the path from the TFTPBOOT directory.

    2.) In the [HOST] section of the config file please make sure that the IP address points to the computer where the TFTP server resides.


    3.) The file needs to exist and have the proper write permissions before the BDI can access it using TFTP.


    4.) When using the TFTP server on windows please use the "w" option to enable write access to the TFTP server.

    5.) Make sure that your firewall has been disabled to prevent the firewall from blocking the communications between the BDI and the TFTP server.

    Hits : 468
  • KB00072 - Error Msg - check stop state

    Question:
    Our 7xx, 74xx processor has entered “check stop state”, what does this mean?

    Answer:
    If for some reason memory access fails on the 7xx, 74xx during startup, the processor enters check stop state and all the clocks are stopped.

    If this happens during startup then some hardware issue is causing initial memory access to fail. If the MPX bus for instance hangs during startup you will get this error.

    After system startup some other error, hardware or software has caused the processor to enter this state.

    If you try and access non preset memory and then TEA is asserted then you can enter this state.

    If MSR[ME] is not set then this could cause the processor to enter check stop state.

    The chip selects to the target memory are not properly configured.

    Hits : 236
  • KB00047 - Error Msg - Communication with debug handler failed

    Question:
    My BDI probe is telling me: "Communication with debug handler failed" and I don't know why.  Any suggestions?

    Answer:
    Normally this error occurs during target startup. First of all make sure that the Debug Handler is located in the Mini IC. Be sure to add the line DBGHANDLER into the [TARGET] section of the config file and point it to the Mini IC. Pointing it to an invalid location will result is this error.

    1. Remove the BDI from your board and make sure that it is coming out of reset properly. You have to make sure the board is fetching the boot vector. Try and put a loop into the boot flash and see if this loop is executed.

    2. If your Board Initialization is not done correctly in the config file, or some target error occurs that results in hanging the memory controller on the target, then you can end up with this error as the communication channel dies. A watchdog timer that is not shut off can result in this sort of an error.

    3. Make sure that the Endianess is set correctly in the BDI Config file [TARGET] section. An incorrect Endian setting will result in communication with the debug handler failing.

    4. Add a WAKEUP 4000 delay to the [TARGET] section of the config file. If this does not work then reduce the JTAG clock speed to a setting of ‘4.’ This will give reset more time to clear before the BDI tries to communicate with the processor.

    5. Make Sure that TRST and RESET are independent of each other as if they are not you can result in this sort of a problem. Normally this issue is hard to track down because basic communication with the Target is working. As far as the BDI is concerned it loaded the Debug Handler into the board, but communication with it fails after Reset Is released.

    6. Debug Handler Failure during startup is normally because of reset issues. The best thing to do is assume that the BDI is operating fine. Scrutinize the Reset circuit; pay special attention to what is generating the resets and any device that can drive reset.

    7. The BDI puts all other devices on the JTAG chain into Bypass mode. If the RESET lines are being driven by another device it is possible that when put in Bypass mode this device may be driving the reset signals incorrectly. This issue has been noticed with some configuration CPLD’s. Removing the CPLD from the JTAG chain will result in proper JTAG communication.

    8. Check with an Ohm Meter the Pull-ups on TDI, TDO, TMS and TCK. They should be greater than 2K otherwise the BDI will not be able to provide enough current to drive these signals and will result in unpredictable errors.

    9. The IXP2400 and 2800 have a feature where they do not generate an exception when you try to access invalid memory. They simply hang resulting in the debug handler hanging since memory is now inaccessible. This results in a constant looping “Communication with Debug Handler Failed” message on the BDI. Clear the [INIT] list in case there is an invalid instruction that is hanging up your processor.

    10. If you are single stepping and getting a message saying “core#0: Invalid debug entry message 0xffffffff” before the debug handler crash, then this indicates a serious crash on the target. Normally when a debug exception occurs the debug handler is called and it writes a defined value (0x00000060) to the DBGTX registers. If the BDI gets a different value then something has crashed. A Value of 0xffffffff looks like the JTAG interface has been disabled or gets asynchronous and the TDO outputs are always 1’s.

    11. If your code tries to write something to the MINIIC make sure that it is not writing to the debug handler location. Otherwise it will overwrite the Debug Handler and communication to it will fail during program execution. You can change the Debug Handler location to elsewhere in the MINIIC by using the DBGHANDLER option in the [TARGET] section of the config file.

    12. If you are trying to access the CP registers in the IXP23xx or IXP28xx you have to make sure that you enable access to the CPX, in the config file you should have defined:

    WCP15 0x010F 0x00002001 ;Enable CP0 and CP13 access

    If this is not done that CP access might fail. CP15 access is always possible.

    Hits : 330
  • KB00028 - Error Msg - Config: cannot open (file name).cfg

    Question:
    After I installed the BDI firmware and start a Telnet session to the BDI Probe, I always get a message, "Config: cannot open (file name).cfg.

    Answer:
    There are several reasons why the BDI is unable to download this file from your tftp server.  Here are the steps we recommend you follow.

    1.  Be sure you have Configured your TFTP server properly on your Windows or Linux host.
    2.  Have your TFTP server configured to 'serve' files from the /tftpboot directory on your TFTP server
    3.  Place the (file name).cfg and other BDI Probe-related configuration files (*red, etc.) in the tftpboot directory of your TFTP server
    4.  Make sure that both the /tftpboot directory and files needed by the BDI have appropriate access permissions for your environment.
    5.  Make sure your BDI has been properly configured via it's serial port (using the BDI Update/Setup utility) to contain the address of your tftp server (Config - Host IP Address parameter in the Setup utility), it's own IP address (BDI IP Address parameter in the Setup utility) and proper netmask (Subnet Mask parameter in the Setup utility).

    Note:  You do not need to the supply the BDI with a gateway address.

    Hits : 481
  • KB00110 - Error Msg - Flash programming failed

    Question:
    Error Msg - "Flash Programming Failed"

    Answer:
    There are several reasons that flash programming could be failing. The most common one is that the config file is not setup correctly for flash programming. Since the BDI uses the processor to perform its flash programming, it is important the memory controller and flash be actually working before the BDI can be used to program flash. Therefore, the burden falls on the developer to customize the BDI config file to properly initialize his board so that flash is properly configured. As a starting point read related BDI Configuration Guide on how to make a config file. The following points can be used to analyze if the flash programming is failing because of a bad config file or a bad programming file. Please comment out the WORKSPACE line from the [FLASH] section unless otherwise stated in the manual. Always make sure you use the "load" command to write to memory and the "prog" command to burn into flash.

    1.) First of all you need to make sure that the [FLASH] section of the config file is setup correctly, please look at Flash Support and construct your [FLASH] section with the proper CHIPTYPE, CHIPSIZE and BUSWIDTH. You should also make sure that the CHIPSIZE matches the value defined in your processor chipselect initialization or Reset configuration. If only a portion of your total flash memory is initialized then the CHIPSIZE needs to reflect the size of the properly initialized flash otherwise programming/erasing will fail. Same is true for BUSWIDTH.

    2.) A very common mistake in making config files is to not have them write protected or not setting the correct bus width or flash size during the memory controller initialization. Please double check the config file [INIT] section and make sure the flash has been properly defined to match what is on your board.

    3.) Next we can try to see if basic communication is possible with your flash. From the BDI Probe use an "md 0x0f000000" and see if you can read back from your flash, where 0x0f000000 is the location of your flash. Use mdd for 64bit, md for 32bit, mbh for 16bit, and mdb for 8bit flash configurations. If this command does not read back flash, either flash is not located at this address or you need to go back and do more work to the flash initialization in your config file.

    4.) If you are using an Intel or AMD flash you can try and write the flash command strings into the flash using the "mm" command. See if you can erase then write values into flash. If this works and the displayed values using the "md" are as expected you have verified that your config file is setup correctly. The strings to write in for the erase unlock and write commands are given in your flash datasheet. Remember that this has to work before the BDI Probe will be able to program or erase the flash. If these steps work then you have verified that you can now use the BDI Probe to flash your chip and that your initialization of the flash is correct and working.

     

    For 2 16 bit Intel Strata Flash in a 32 bit wide bus try the following stings:
    Unlock a block:
    BDI> mmh 0x??000000 0x00600060 ; Block unlock at 0x??000000
    BDI> mmh 0x??f000000 0x00d000d0 ; Block Verify at 0x??000000
    BDI> mmh 0x??000000 0xffffffff ; Terminate Transaction
    BDI> mdh 0x??000000 ; shows the Flash data

    Erase a sector:
    BDI> mmh 0x??000000 0x00200020 ; Block Erase at 0x??000000
    BDI> mmh 0x??000000 0x00d000d0 ; Block Verify at 0x??000000
    BDI> mmh 0x??000000 0xffffffff ; Terminate Transaction
    BDI> mdh 0x??000000 ; shows the Flash data

    Program a 32 Word:
    BDI> mmh 0x??000000 0x00400040 ; Byte Write at 0x??000000
    BDI> mmh 0x??000000 0xabcd1234 ; Write abcd at 0x??000000
    BDI> mmh 0x??000000 0xffffffff ; Terminate Transaction
    BDI> mdh 0x??000000 ; shows the Flash data

    For a 16 bit Amd AM29LV Flash try the following strings:
    Erase the entire chip:
    BDI> mmh 0x??00AAAA 0xAAAA
    BDI> mmh 0x??005554 0x5555
    BDI> mmh 0x??00AAAA 0x8080
    BDI> mmh 0x??00AAAA 0xAAAA
    BDI> mmh 0x??005554 0x5555
    BDI> mmh 0x??00AAAA 0x1010 ; Erase Chip
    BDI> mdh 0x??000000 ; Shows the status, analyze it

    Erase a sector:
    BDI> mmh 0x??00AAAA 0xAAAA ; Command Sting must be
    BDI> mmh 0x??005554 0x5555 ; entered at a predefined
    BDI> mmh 0x??00AAAA 0x8080 ; address ending with AAAA or
    BDI> mmh 0x??00AAAA 0xAAAA ; 5556 as shown. You finish by
    BDI> mmh 0x??005554 0x5555 ; specifying the address of the
    BDI> mmh 0x??000000 0x3030 ; Sector to erase.
    BDI> mdh 0x??000000 ; Shows the status, analyze it

    Program a 16 word:
    BDI> mmh 0x??00AAAA 0xAAAA ; after the command string you
    BDI> mmh 0x??005554 0x5555 ; can specify any 16word
    BDI> mmh 0x??00AAAA 0xA0A0 ; aligned address to write to.
    BDI> mmh 0x??000000 0xabcd ; Write abcd at 0x0f000000
    BDI> mdh 0x??000000 ; Shows the status, analyze it
    BDI> mmh 0x??00AAAA 0xAAAA
    BDI> mmh 0x??005554 0x5555
    BDI> mmh 0x??00AAAA 0xA0A0
    BDI> mmh 0x??002000 0xabcd ; Write abcd at 0x??002000
    BDI> mdh 0x??002000 ; Shows the status, analyze it

    The Spansion S29GLxxxM Flash does not support single byte programming. In 8-bit mode, programming is only possible via the write buffer. Therefore programming work only with workspace. The BDI does not support programming via write buffer without a workspace. It uses singe byte programming in this case. You may manually try to program some bytes via the write buffer. For example 4 bytes at 0xff801000:

    BDI> mmb 0x??00aaaa 0xaa
    BDI> mmb 0x??005555 0x55
    BDI> mmb 0x??001000 0x25  ;write to buffer
    BDI> mdb 0x??001000 3     ;bcnt - 1
    BDI> mmb 0x??001000 0x12  ;data 0
    BDI> mmb 0x??001001 0x34  ;data 1
    BDI> mmb 0x??001002 0x56  ;data 2
    BDI> mmb 0x??001003 0x78  ;data 3
    BDI> mmb 0x??001000 0x29  ;program
    BDI> mdb 0x??001000

    As mentioned, please refer to the flash data sheet for the exact command strings to use.

    If the command strings fail to program flash then you need to make sure that the flash is initialized correctly. Also, make sure to account for any bit reversal or byte swapping when typing in the command strings.

    5.) Once you have verified that writing to Flash is possible, try and erase some sectors on your flash using the "erase 0x0f000000 0x20000 1" command, where 0x20000 is the sector size as given in the flash datasheet. If you have multiple flash chips connected in parallel, the sector size will then be the sector size of one chip multiplied by the number of flash chips in parallel. If you get the message "erasing flash failed", then this indicates a problem with the [FLASH] section of the config file or that your flash is write-protected. For Intel flash unlock the flash by either writing the unlock command through the config file, the "mm" commands or using "unlock". A common mistake is to not have the correct buswidth selected. Please recheck the BRO/ORO or flash initialization to confirm that the proper BUSWIDTH and CHIPTYPE are used.

    Also, make sure there is no bit reversal or byte swapping on the flash data bus, which can also cause programming to fail. The BDI's programming algorithm needs to be told to account for your flash configuration.  

    6.) Most flashes need to be erased before they can be programmed. To test that you can program the flash, create a sample binary test file; write in "abcd" into it and save it. This creates a 4byte binary file. Now program it into the flash thru the BDI "prog 0x0f000000 abcd.bin BIN" where 0x0f000000 is the location of your flash. If necessary create bigger and bigger binary files to test programming of multiple sectors to make sure all sectors of the Flash are programmable. If this works and you verify that the flash is written properly with the "mm" command then everything should be setup correctly for you to burn in an image to your board.

    7.) If upon reading back the "mm" command you see corrupted data you need to go back and recheck the flash initialization in the config file, and make sure that the Flash is connected to the processor in a supported manner. 

    8.) If you have verified that you can program in the sample file correctly, but your own custom file fails then most likely there is a problem in the file you are trying to program. Try and change into a binary file format and try programming the file. Srec's and ELF file formats have some internal offsets built in. You have to understand how the offsets work, for an ELF file for instance you cannot program it by specifying in an initial offset of your own during programming. Doing that will move all the built in linker pointers and will make the ELF file useless. The info of where to program is built directly into the ELF file when it is created, the BDI will program the ELF file based on this information, no additional offset is required by you. To see where the ELF file is being programmed or loaded you can do an object dump from a Linux prompt, "[linux#] objdump -p -h -f yourfile". This will give you all the header and section information. If you find that some sections are being programmed to the wrong address you will need to change the linker script that creates the ELF file to program the header information correctly. The BDI displays a message saying "programming file to offset 0x0010000", if you find that the address displayed during programming is not correct then this points to your file not being built correctly for programming flash .

    9.) If you are having trouble where flash programming seems intermittent where it fails sometimes and other times it passes, this maybe an issue with flash timing. Try adding more wait delays in the flash initialization in the [INIT] section of the config file.

    Hits : 597
  • KB00111- Error Msg - Flash Programming Failed

    Question:
    Error Msg - "Flash Programming Failed"

    Answer:
    After programming the first 512 bytes into flash the BDI2000 gives an error and stops programming. Same thing happens when we run a verify. When we read back the flash it appears to be programmed correctly.

    The BDI Probe runs a check using the md command after every 512bytes are programmed to verify that it has programmed correctly. If there is nothing else specified, the BDI uses 64 bit accesses to dump the memory content. The default number of CPU clocks the BDI uses to get a 64bit value may be too small if there is an 8bit memory (needs 8 read cycles).

    Try the following:

    1) Increase the number of clocks the BDI uses for a memory access: MEMDELAY 4000; additional memory access delay or:

    2) Force the BDI to use smaller accesses to the flash range: TSZ1 0xFFF00000 0xFFFFFFFF; ROM space


    The second solution will slow down read access to the flash via JTAG by a factor of 8. Therefore the verify part within the algorithm takes more time.

    Hits : 490
  • KB00031 - Error Msg - JTAG exits check failed message

    If you get a JTAG Exits check failed message after a JTAG Bypass check message then it means the JTAG Chain is disabled for some reason.

    If you get a JTAG Exits check failed message after a JTAG Bypass check message then it means the JTAG Chain is disabled for some reason. The BDI tries to read the bypass register but can't. The message will appear in this sequence In the BDI Telnet prompt.

    > - CONFIG: loading configuration file passed
    > - TARGET: processing reset request
    > - TARGET: BDI asserts TRST and RESET
    > - TARGET: BDI removes TRST
    > - TARGET: Bypass check 0x000000001 => 0x00FFFFFF
    > - TARGET: JTAG exits check failed

    There are several reasons this may be occurring. When you get a message saying Bypass check 0x000000001 => 0xFFFFFFFF, it means that the JTAG is disabled and the BDI cannot find any device on the JTAG chain. A message showing => 0x00000001 or any other number shows the number of devices that were discovered on the JTAG chain.

    1) Start out by making sure the correct CPUTYPE is selected in the config file, the location of the bypass register can change with different processors and the BDI might be looking at the wrong location if an incorrect processor type is defined.

    2) Please verify that the TRST line is Pulled High by a resistor, if it is not then add the "TRST PUSHPULL" line into your config file. This command is not supported for XSCALE targets.

    3) If the reset from the JTAG connector is delayed for some reason (it might not be directly connected to the processor) then add a wake-up delay to reset line, e.g. "WAKEUP 10000". This does not work if your processor has a watchdog timer because the watch dog will trigger before the wakeup time is over. Possibly try and use a smaller wakeup delay.

    4) If the processor is not the only device on the JTAG Scan chain then you have to tell the BDI2000 the IR values of all the Devices on the Scan chain. USE SCANPRED and SCANSUCC to specify the correct values, see the user manual for more details.

    5) Check the JTAG circuit to make sure it is wired correctly on the board. Reference the manual at page 5 and make sure the JTAG connector is wired correctly. Use an oscilloscope to test the logic levels of the signals if need be.

    6) A message saying => 0xFFFFFFFF means that the JTAG chain is disabled on your board. Make sure that the JTAG chain is enabled on your board. If there is a mux or jumper on the JTAG chain make sure it is at the correct setting.

    7) Please check the power supply to the processor, make sure the power supply is clean and at the recommended level.

    8) JTAG is very sensitive to noise and adding resistors sometimes creates slow rising signals that don't meet their time window. For the most part pull-ups of >= 1K are ok with signal lines. The values below should be ok to use with the indicated signals.

    Signal Name Resistor Pullup/Pulldown Resistor Value TDI,TDO,TMS, TCK pullup >=2K RESET and TRST pullup 1K-3K TRST pulldown(ARM only) 1K-10K VCC <= 1k

    Signal Name

    Resistor Pullup/pulldown

    Resistor Value

    TDI, TDO, TMS, TCK

    pullup

    >=2K

    RESET and TRST

    pullup

    1K-3K

    TRST

    pulldown
    (ARM only)

    1K-10K

     

    Hits : 626
  • KB00068 - Error Msg - PPC Core timeout waiting for freeze

    Question:
    PPC Core timeout waiting for freeze.   COP freeze indicates that BDI is not able to put your CPU in debug mode. In simple terms when the BDI realizes that it can not access the debug registers it issues a COP freeze to halt the CPU.

    Answer:
    1.) If you are using a PPC82xx processor and are getting this error during the BDI startup sequence then possibly TRST and HRESET are wired together in some manner causing some unknown behavior resulting in a timeout. Please check the JTAG circuitry and make sure TRST and HRESET are not tied together.

    2.) For COP family processors it is necessary to actively drive the QACK signal low on the processor via a pull down resistor. If this is not done then you may end up with this error.

    3.) Sometimes long delays in the reset circuit can make the BDI think the PPCcore is not responding. Using a wakeup delay will let you get thru this problem. Add WAKEUP 2000, to the config file, if you end up with messages saying reset detected, then your watch dog is probably triggering, reduce the delay until you can pass the startup sequence.

    4.) If you get this message during startup of a PPC4xx core, then it means the BDI sets the HALT pin and the stop bit in the debug control register making the PPC4xx enter debug mode (freeze), but in this case it doesn't. Possibly the PPC4xx core needs more time to respond. Add WAKEUP 2000 to the config file and see if it fixes this problem.

    5.) If your PPC4xx core is embedded in the Xilinx FPGA you have to make sure that the SCANSUCC parameter is set properly. When this parameter is not defined properly the bdi cannot put all the devices into bypass mode and they interfere with the BDI.

    6.) For a PPC440 If you get this error along with a "core startup failed" message, disconnect the BDI and check and see if the 440 core is working properly. Monitor the signals to the Boot Rom, without the BDI connected the 4xx should try and access the Boot Rom. If this does not happen then check the reset and clocking of the 4xx core, there is a hardware problem stopping the core from starting up correctly.

    7.) If your PPC8xx is constantly failing to load the [init] list and doing an "info" reveals this message then its possible a hardware issue is causing the BB signal to be held low. For the MPC8xx BB (Bus Busy) maybe sampled at startup to determine when an external master has released the bus. This can block fetching the bootvector and freeze the processor.

    8.) If you get this error on a PPC85xx while debugging, try using MEMACCESS CORE in the config file as this will sometimes give better behavior as SAP memory accesses can get tied up at times.

    9.) Trying to access or write to a memory location that does not exist can result in this type of a problem. If you get this error right after doing a prog or load then double check to see if the target memory area is accessible and exists.

    10.) If you get this error when you try and halt the PPC8xx/5xx/4xx/82xx core thru the BDI it indicates another problem altogether. From the JTAG point of view this message indicates that the PPC does not enter debug mode because the PPC core has stopped responding. BDI asserts the HALT pin on PPC4xx but the PPC4xx does not respond. For other PPC's it means the BDI told the PPC core to stop but it did not.

    i.) It is possible the PPC is tied up in an un-terminated memory transaction that will never end, making it impossible to respond to JTAG commands. A device on the PPC bus making accesses to the PPC memory while the BDI is trying to communicate can cause this.

    ii.) Make sure that any device on the PPC bus or the PCI bus is not triggering the JTAG reset line. This may cause the BDI to lose communication with the PPC.

    iii.) Make sure that PPC bus or PCI bus activity is not creating noise on the JTAG circuit in any manner.

    iv.) The best way to debug this sort of a problem is to check bus activity on all PPC and PCI devices to see if any of them is trying to access memory or is otherwise sending write or reads to the PPC

    Hits : 475
  • KB00102 - Error Msg - Program received SIGSTOP

    Question:
    I keep getting the error message in GDB saying Program Received SIGSTOP

    Answer:
    If the program being debugged has stopped responding then GDB comes back and displays this message. It is not uncommon to receive this message in GDB while debugging a Linux kernel and normally points to a problem in your Page Table entries. First of all make sure the Page Tables are write -able; set the CONFIG_BDI_SWITCH in your Linux kernel, then check pgtables.c for a line saying:

    #if defined(CONFIG_KGDB) || defined(CONFIG_XMON) || defined(CONFIG_BDI_SWITCH)

    /* Allows stub to set breakpoints everywhere */ f |= _PAGE_WRENABLE;

    As a test do instruction-by-instruction debugging using GDB and track to the instruction before you actually receive the SIGSTOP message. Then from the BDI check the PTBASE values and make sure the page tables are setup correctly; md 0x000000f0 (or where ever the PTBASE is). Sometimes the PageTables are not updated and can have data that is old resulting in this error. head.s will need to be modified to update the Page Tables to keep the BDI from failing during debugging. Normally adding the BDI_CONFIG_SWITCH will take care of this issue. Please take a look at section 3.3.6, "Embedded Linux MMU Support" in you BDI Probe user manual.

    1.) When you activate DCACHE FLUSH in the BDI config file, the BDI will use the workspace to perform its swapping operations. If the workspace is close to the PTBASE pointer then an overlap can occur and you will get a corrupted page table and GDB will get this error.

    2.) On a 750FX/GX it is recommended that you set DCACHE NOFLUSH from the config file, otherwise the BDI can display the wrong data and software breakpoints are known to also fail.

    3.) On the PPC8xx, a limitation of the JTAG interface is that a JTAG breakpoint is considered to be an interrupt. Hence, we cannot debug interrupt requests like an RFI instruction as this will result in an error.

    4.) On a PPC4xx you can get this error when accessing the MSR or other registers. This points to a serious error and maybe the result of eprom not being configured correctly. The PPC4xx gets its power on chip defaults from the eprom and if that is not configured properly the software debugging can be unstable.

    Hits : 125
  • KB00084 - Error Msg - PVR not supported

    Question:
    Error Msg - "Target not supported" or "PVR not supported"

    Answer:
    Please contact your Ultimate Solutions FAE to confirm that the processor is supported by the current firmware you are using.

    Below are some known issues why your COP target may be getting this error message.

    If the board has an invalid HRCW then it will sometimes display error messages saying "Target not supported" or "PVR not supported ". In the case of an MPC82xx target, pull the RSTCONF (Pin X.45 on TQM8260) pin high and bring up the board with a valid config file from the BDI Probe. Keep in mind to turn off the watchdog and adjust for the default IMMR which is now located at 0x00000000. You will then have to set up the config file to let you program a valid HRCW. You can flash uboot into the TQM8260 to program a valid HRCW. The procedure to program a valid HRCW is different for different targets. Put RSTCONF low again and now the board should be working fine.

    If you are also getting the error saying, "Check LSRL Length Failed", then add a wakeup delay line to the TARGET section of the config file, "WAKEUP 2000". This error occurs because the BDI might try to initialize communications with the target too soon after HRESET is released.

    Hits : 234
  • KB00105 - Error Msg - remote packet too long

    Question:
    When I try and connect GDB to the BDI, I get the error message saying “remote packet too long”

    Answer:
    If you try and use the default GDB on your host system to connect to the BDI you will get this error. This is because GDB on your Linux or Cygwin system is trying to read x86 registers from the target, your target is not X86. You have to get the cross-compiled GDB for your target system to establish communication with the BDI. Download GDB from http://www.gnu.org/software/gdb/. Please read http://www.ultsol.com/pdfs/Tool_Talk_03-001.pdf. You can also download free development tools from www.denx.de, www.mvista.com or www.timesys.com that come with a pre-built version of GDB.

    Hits : 137
  • KB00017 - Error Msg - Target Access Error

    Question:
    I can't seem to access my target hardware

    Problem Resolution:
    There was a hardware problem on the board.   The JTAG Reset was tied high at one point.

    Note:
    This error is very common and one we have a problem providing a single answer to.  If you having this problem, Contact our Tech Support Staff at support@ultsol.com and send us a copy of your JTAG layout so we can review it against the one published by the specific CPU vendor.

    Hits : 363
  • KB00092 - Error Msg - Target reset detected, restarting target

    Question:
    Why does our Target board keep resetting? It says "Target reset detected, restarting target"

    Answer:
    There are several reasons that the target can get stuck into constant resetting pattern.

    1. The most common reason is that the TRST and HRESET are tied together in some way. If TRST and HRESET cannot be asserted independently, the BDI detects HRESET after asserting TRST and will get stuck in a loop of resetting itself. There is no way around this but to redesign the circuit so that HRESET and TRST are not dependent. On ARM CPU's you can still debug by setting RESET NONE and STARTUP RUN, then resetting the CPU manually from your board.

    2. Check the pin outs of your board header and make sure they are the same as indicated on page 5 of the BDI manual, make sure all the listed signals are present on your header and are at the right pin locations.

    3. Another common reason is that the watchdog timer is not shutoff. Make sure that you have it shut off if your CPU has a watchdog timer. If internal register space is moved then be sure to point to the correct register to shut of the watchdog.

    4. Similarly if your processor has a watchdog timer and you define a WAKEUP delay in your [TARGET] section the board might get stuck resetting itself. The BDI first processes the WAKEUP delay before it processes the [INIT] list, hence if you turn off the watchdog in the [INIT] section, the watchdog may still be triggering because the BDI waits for the WAKEUP delay to finish before it turns off the watchdog. Your watchdog may expire before the WAKEUP delay finishes.

    Hits : 329

Ultimate Solutions, Inc.
10 Clever Drive
Tewksbury, MA 01876 USA
Phone: 978.455.3383
Fax: 978.926.3091
Email: info@ultsol.com
 
 
 
Quick Link to Support & Resources:
 

      

Twitter Button  

Latest News

Abatron adds support for AppliedMicro's X-Gene™ processor
More Info


USI acquires Zylin ZY1000 product line
Click Here


Available NOW for an introductory price!
Embedded Linux BSP Program from bootbits
Click Here...

Ask about new Boundary Scan capabilities with the ZY1000!
Click for more info

Info

An Easier Way to Debug Linux - Download the Pre-recorded Webinar

PODCAST

Hardware Debuggers (Episode 29) Interview with Fahd Abidi  Download Here

USI ToolFinder

Use our Toolfinder to find Development Tools available for your processor family! Click Here...

USI Blog

Feel free to leave a comment or idea! Click Here...