P4080PCIe evaluation board debug with CodeWarrior USB TAP

[stanislavperep1]

Hi All,

If someone have tried to connect CodeWarrior USB TAP to P4080PCIe board share your experience, please.

P4080PCIe board is quite popular for low price, but there is lack of documentation. For example, connecting to CW debugger is not covered at all.

First, to start downloading I need to know what platform is preferrable for CodeWarrior for PA, version 10.1.2 or newer?

[marius_grigoras]

Hi,

We just released last week the CW SP4 (P4080PCI board support is included) for CW PA 10.3 [1] (Updates and Patches (3) tab)

Regards,

Marius

[1]  http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=CW_DSPA&nodeId=0152102726E4C7E4CF&fps...

[stanislavperep1]

Ok! Great! I've dowloaded CodeWarrior for PA 10.3 and installed it.

My anti-virus software starts complaining about <...>/ccs/bin/libcrpedl.dll

Type:	File
Source:	C:\Program Files (x86)\Freescale\CW PA v10.3\PA\ccs\bin\libcrpedl2.dll
Status:	Infected
Quarantine object:	5488b54e.qua
Restored:	NO
Uploaded to Avira:	NO
Operating System:	Windows XP/VISTA Workstation/Windows 7
Search engine:	8.02.12.120
Virus definition file:	7.11.102.196
Detections:	TR/Crypt.ZPACK.Gen
Date/Time:	16.09.2013, 18:46

Is it OK or something goes wrong?

[marius_grigoras]

Are you sure your antivirus program is ok and is up to date? We never got this error. I attached my dll file if you want to compare the files.

Regards,

Marius

[stanislavperep1]

The installer was downloaded on 23.05.2013, Please note, anti-virus actually complains about libcrpedl2.dll

[marius_grigoras]

same status for this dll - no issue.

[stanislavperep1]

Avira immediately pops up with red alert on your file too!  I'm sure it is up to date and it saved my computer for many times. Think now it is false-positive detection.

[stanislavperep1]

Regardless of problem shown in previous post CW-10.3 for PA patched successfully with latest update.

Moreover, I've managed to open "Project Stationery" (RAM configuration) for P4080PCIe. Now my most important problem is solved: debug session starts without errors and I can enjoy source-level debugging.

Now I want to be able to debug ROMable application. I'm worry about FLASH banks. I want to preserve Bank0 as recommended in P4080PCIe user manual.

Can anybody suggest the safe approach how to debug ROM application in FLASH Bank4 (this bank recommended for experimental things by manufacturer)?

[marius_grigoras]

Hi,

Is not mandatory to switch the bank (basically this is recommended only  if you want to have a "nice" method to recover the board in case if you made something bad when you'll write the ROM application. More exactly you can switch to bank4 (make it the default one using the DIP SW Settings), write your RCW and the ROM application and after that, if somethings goes bad just switch back to bank0.

We already discuss about this here [1].

About ROM application, you'll need to build the ROM target and just write it using FlashProgrammer in the NOR flash (don't set any offset, and please select and the erase operation). Also, if you'll choose to switch the bank is mandatory to write and the RCW in that bank, but before switching it (the RCW is needed by SoC when boothing/starting up).

Regards,

Marius

[1] https://community.freescale.com/message/331544#331544

[stanislavperep1]

It's that what makes me worry, there is no DIP switches on P4080PCIe board. Bank change managed with help of CPLD by applying inverted or direct 26-th bit of LA-bus. So I'm asking about correct way to setup Flash Programmer. At least I want to know if something goes wrong during debug can I recover board using CodeWarrior USB TAP and FlashProgrammer software?

[marius_grigoras]

Sorry for that, you're right. My reference related to DIP SW settings is applicable to P4080DS.

For P4080PCI (where there are no DIP SWs), the bank can be switched using the CPLD. You can use the SYS_CFG register (bits 0-2 -> FBNK[0], FBNK[1], FBNK[2]).

Upon power up, these bits are programmed from the levels of CPLD_SPARE[2:0] signals. The software can reprogram them and then generate a POR (Power-on-reset) by writing a 1 into bit 6 of the RST_CTL

register.

Also you can find details about how can you make this bank switching via u-boot here [1]

Having no DIP SWs, is pretty hard to make this from application level, so for that my best approach is to make 2 dump files (using the dump operation from  FlashProgrammer):

- first one for the first NOR flash - here is located the RCW (very important for SoC booting up)

- second one for the last 4 sectors (512KB) - here is located the u-boot code

Now, let's say that somehow you'll break the first sector, in this case the SoC in unable to boot-up and also the CW debugger cannot connect to the SoC. In this case, you can use (and I strongly recommend it) the JTAG override feature (this is a CW debugger capability to recover the bad RCW to register level), in this mode you can start the debug operation again and write  the RCW in the first sector, using the FlashPRogrammer. Full details here [2].

Regards,

Marius

[1] http://cache.freescale.com/files/32bit/doc/user_guide/P4080_PCIE_UG.pdf

[2] https://community.freescale.com/message/340148#340148

[stanislavperep1]

I have tried the following:

1. I have booted the board with factory provided u-boot and issued command =>n710_reset altbank. I think, it inverts address bus bit26 in hardware.

2. After that I inserted USB TAP head and started Flash programmer with intension to flash my software under debug

3. Set some Connection designated to my USB TAP and Flash Configuration file "P4080PCIe_NOR_FLASH.xml"

4. Hit the button "Erase and Program"

How what I can see in console:

fl::target -lc "LC for Simple Flash"

fl::target -b 0x2000 0x30000

fl::target -v off -l off

cmdwin::fl::device -d "S29GL01GP" -o "64Mx16x1" -a 0xe8000000 0xefffffff

cmdwin::fl::image -f "<.. deleted ..>\\boot-core0\\ROM\\boot-core0.elf" -t "Auto Detect" -re on -r 0xe8000000 0xefffffff -oe off

cmdwin::fl::erase image

Beginning Operation ...

-------------------------

Auto-detection is successful.

  File is of type Elf Format.

Performing target initialization ...

Downloading Flash Device Driver ...

Reading flash ID .......

Error:  The algorithm was not able to run on the target or the flash is not configured properly.

Error:  Getting flash ID failed

Is it possible that inverted address line spoils communication between Flash Programmer and flash chip on board?

Address range mentioned in console output suggests they are about to treat flash chip "as whole". Thus using correct offset we can flash image to desired bank.

Is it correct idea?

Regards,

Stanislav.

[marius_grigoras]

Your scenario is valid in theory, but unfortunately is still not supported in CW, because the u-boot uses 36bits address for physical spaces and FlashProgrammer support still uses 1:1 memory translation between virtual-physical spaces (32bits). This flow will be supported starting with CW PA10.3.3.

Now, turning back with your scenario, you can enter in debug using the Connect target and simply write the desired bits from Debugger Shell (Window -> Show view -> Debugger Shell) to switch the bank.

1. Enter in Debug with Connect target.

2. Write your ROM image in bank4 (bank4 starts at 0xEB00_0000). Don't forget to use check <erase before writing>.

3. Set your desired bank using SYS_CFG register (in this case is bank 4).

	#get SYS_CFG register value
	set SYS_CFG [mem [CPLD 0x05] 8bit -np]
	#set bit2 which set FBNK to 4
	set SYS_CFG 0x[format %x [expr {$SYS_CFG | 0x04}]]
	mem [CPLD 0x05] 8bit -np = $SYS_CFG
	wait10

4. Reset using POR signal:

	#get RST_CTL register value
	set RST_CTL [mem [CPLD 0x08] 8bit -np]
	#set bit6 which generates a CPU POR
	set RST_CTL 0x[format %x [expr {$RST_CTL | 0x40}]]
	mem [CPLD 0x08] 8bit -np = $RST_CTL

5. After this step you should see your ROM application starting.

Please note that I didn't tested these steps, but should work (a same scenario is made in the tcl initialization file for a DDR work-around).

Regards,

Marius

[stanislavperep1]

I've been trying to setup "Connect" Debug session type.

In connection section.

I made use of /PA_Support/Initialization_Files/QorIQ_P4/P4080PCIe_init_sram.tcl

and

/PA_Support/Initialization_Files/Memory/P4080PCIe.mem

initialisation files

As a result Problem Occured dialog appears:

Error launching boot-core0_ROM_P4080

CCSProtocolPlugin::Could not connect to the requested corecore #0.

With another initialization files (I did not edit anything)

${workspace_loc:/boot-core0/CFG/P4080PCIe_init_core.tcl}

${workspace_loc:/boot-core0/CFG/P4080PCIe.mem}

The debugger "Connect" session ends up with error in JTAG configuration.. Why this happen?

I think I should ask how to setup Connection to properly connect to my target in ROM debug or Flash Programmer scenario.

[marius_grigoras]

You can simple make the Connection target using only the GUI. Please find below an useful image (is applicable as well and for your board):

[stanislavperep1]

Oh well, thanks! Created with help of wizard "Connect" Debug session type works nice! I need to investigate were I went wrong in my configuration, or wizard really cast some magic spell on debugger. So, it looks like I can do stepping in ROM and thus I can debug my boot code. Things could get better now!

[stanislavperep1]

Too early to celebrate. There is something in init which leads to exception. So next step after 0xFFFF_FFFC is jump to address 0x0000_0800, where Floating point exception vector situated. I have no idea why it could happen.

[marius_grigoras]

1. You have a custom ROM application or you're using the default one generated by CW?

2. However, you should use the ROM_Attach scenario + reset and not the P4080PCIe_init_core.tcl with Connect Target.

Try the 2nd step and let me know the results.

Thank you,

Marius

[stanislavperep1]

That was my fault, I've tried to execute ROM_Attach scenario with P4080PCIe_init_core.tcl

I can debug my custom ROM image with following setup:

1. My software-to-debug flashed to Bank4(0xEBxx_xxxx) using U-boot(started from Bank0)
2. Board forced to alternate bank using U-boot command "n710_reset altbank"
3. USB TAP head attached
4. CW imports software-to-debug.elf with new project creation
5. Debug configuration setup as ROM_Attach
6. Perform system reset using debugger reset button
7. Core starts from 0xFFFF_FFFC and you able to step thru the assembly instructions.

Et voila!

[stanislavperep1]

There is another confusing point: if somewhere in software-under-debug there is memory address translation, Disassembly window shows memory content without respect this translation. For example, software maps EA:0xEFF0xxxx to PA:0xFFF0xxxx and jumps to EA. In Disassembly window appears not defined memory area( filled with 0). How to setup Disassembly window to respect address translation?

[marius_grigoras]

This is the default behavior implemented right now in CW debugger. If you want to enable the translation, you'll need to add a memory file in the Memory tab (something similar we're using for u-boot debug - please find here an example -> PA\PA_Support\Initialization_Files\Memory\P4080PCIe_uboot_36_NOR_stage2.mem).

Please note that starting with next release, we'll make this dynamically via MMU Awareness feature and the 'translate' commands from memory files will be no longer required.

Regards,

Marius