KB00055 - JTAG Clock selection between BDI2000 & BDI3000JTAG clock selection:
The BDI3000 is compatible with the BDI2000 configuration files except for the JTAG clock selection. The same JTAG clock number selects a faster clock on the BDI3000 than on the BDI2000. In most cases, you can run with the faster JTAG clock.
Increase access delays:
Because the BDI3000 executes its code much faster, it maybe necessary to increase or add access delays where possible.
For MIPS targets you may add a JTAGDELAY entry:
JTAGDELAY 6 ;48 TCK's access delay
For Cortex-A8 you may have to increase memory access delays:
MEMACCESS CORE 10 ;memory access via core (80 TCK's access delay)
MEMACCESS AHB 8 ;memory access via AHB (64 TCK's access delay)
Add a wakeup delay:
If a reset sequence fails that worked with a BDI2000, try to add a wakeup delay. This maybe the case if there
is a slow rising reset signal on your board.
WAKEUP 100 ;give reset time to complete
PPC4xx: Let PC point to fast memory:
During download/programming the BDI does not check if the previous store instruction has completed. This in order to get a fast download rate. It seems that the 4xx core does always a prefetch to the current PC and if the PC points to slow memory (boot flash) the BDI3000 overruns the 4xx core. In order to prevent this, add an entry to the BDI init list that lets the PC point to fast memory.
For example to SDRAM or internal SRAM.
; Setup TLB
WTLB 0xF0000095 0x1F00003F ;Boot Space 256MB
WTLB 0x00000094 0x0000003F ;SDRAM 256MB @ 0x00000000
WTLB 0x80000095 0x0800003F ;internal SRAM 256KB
WREG PC 0x80000000 ;let PC point to fast memory
...Hits : 671
KB00042 - The BDI probe is displaying the wrong PVR value
Why is the BDI is displaying the wrong PVR value?The BDI is displaying the wrong PVR value for my board, It should be 0x80811014:
> - JTAG exits check passed
> - Target PVR is 0x80911014
> - COP status is 0x01
User's of older revisions of the firmware often times see "0x00100000" gets added to the PVR. Contact Ultimate Solutions to verify if a newer version of the firmware is available for your BDI2000. Users of the BDI3000 will not see this problem as it was fixed prior to its release.Hits : 460
KB00045 - Can't connect to BDI Loader
The BDI setup utility has been run on countless windows and Linux systems and has been known to work. 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. Make sure you are using the serial cable shipped with the BDI probe. Note that the serial cable is not necessarily a pass thru serial cable and programming of the firmware may fail or the connection may not work if you use an unknown cable.
3. Make sure your 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 anyway. 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 interfer with the serial port communication.
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. Refer to KB00022 for more insight.Hits : 550
KB00046 - My BDI fails to connect to my targetQuestion:
My BDI can't seem to connect to my target. I get the following output from the BDI Telnet prompt during startup. What can I do to resolve this conflict?
BDI Telnet Output:
- TARGET: processing reset request
- TARGET: BDI asserts RESET and TRST
- TARGET: BDI removed TRST
- TARGET: Bypass check: 0x000000001 => 0x00000001
- TARGET: JTAG exists check passed
- Core#0: ID code is 0x69264013
- Core#0: BDI sets hold_rst and halt mode
- TARGET: BDI removes RESET
- Core#0: BDI loads debug handler to mini IC
- Core#0: BDI clears hold_rst
- TARGET: resetting target passed
- TARGET: processing target startup ....
# TARGET: core #0 startup failed
# TARGET: timeout while waiting for debug mode
# TARGET: processing target startup failed
# TARGET: timeout while waiting for debug mode
- TARGET: target will be restarted in 10 sec
After loading the debug handler into the Mini IC the target is started. Now this debug handler should start communicating with the BDI via JTAG. But this does not happen on this target because the Target could not complete its reset sequence correctly. The Target was still in reset when the BDI started to communicate to the XSCALE core.
1) If you have a reset chip on your board that takes a long time to complete the Reset sequence then you will need to tell the BDI to delay communication to the processor until after the reset has finished. Adding a WAKEUP delay of about 4000ms is normally enough to do this.
2) This problem can be a result of JTAG communication not working properly on your target. Please check the JTAG circuit, try and increase the Vcore on the target to make sure JTAG communication is working properly.
3) Please make sure the processor is coming out of reset properly. If it is not then there is some hardware problem preventing your board from coming out of reset.
4) IXP23xx and 28xx Devices have a feature where if they are configured to boot from the PCI bus they will hold the XSCALE core in reset causing this problem.
5) If The board has an invalid HRCW then it could also get stuck in a resetting pattern. Sometimes the following error messages are displayed; "Invalid PVR" or "Unsupported Target". In this case pull the RSTCONF pin high and bring up the board with a valid config file from the BDI. Keep in mind that you may have to turn off the watchdog and adjust for the default IMMR.Hits : 1143
JEFAQ Pro 1.5.1 - Joomla FAQ Extension
Hardware Debuggers (Episode 29) Interview with Fahd Abidi Download Here