Seems like CodeWarrior doesn't recognize 32-bit data bus

[Neptune_1]

We made simple board based upon MPC8245. Flash and SDRAM both connected to 32 bit data bus MDH[0:31]. MDL[0:31] is disabled at reset by on-board logic (using MPC' configuration signals). For debugging purpose we use CodeWarrior Power Architecture 8.7.1 Patch Build 70802 (latest verson downloaded from freescale site) + CodeWarrior USB TAP CWH-UTP-PPCC-HE. When I try to read and write memory, I can easily do it with each even word, whereas each odd word is inaccessible. Flash region looks like 0xFFF00000: 0xFFFFFFFF 0x00000000 0xFFFFFFFF 0x00000000 ... This is not correct, because _every_ word must be 0xFFFFFFFF. When I download program to memory (via JTAG) each odd instruction becomes 0x00000000 - illegal instruction. Program refuses to start. Next, I put a simple loop program in FLASH (at 0xFFF00100), using Wiggle+UrJTAG without connecting to on-chp debug core. Program works normally after reset, no exception 'Illegal instruction' or 'Floating point unavailable' occurs. So I'm convicted it is CodeWarrior problem. I have only 12 days of evaluation period left :\. Any ideas?

[xuchaoli]

Today I  was trubled by same quessions of you . So ,Can you tell me what is the reason of this problem? and how solve it？

[Neptune_1]

I tried different variants of init.cfg - all in vain

I don't think that it's initial system configuration that causes all troubles. System must start up somehow without JTAG USB TAP and init.cfg.

If the MPC8245 would have seen flash region 'band-like' at power-up by itself it could not start up at all.

But it starts. When I program flash with u-boot located at reset exception vector I can see initial 'Hello world' printed to console. (Futher on system freezes but it doesn't matter, it's u-boot issue).

Another experiment:

When I try to address 'empty' (odd) SDRAM memory words using CodeWarrior hardware diagnostics, I don't see any bus activity with osciloscope.

When I configure MPC to 64-bit data bus width (pulling MDL[0] high at reset) I can see bus activity both for even and odd words. Even words are accessible to read/write. Odd words are inaccessible because there's no physical memory at MDL[0:31]. Yet I can read the manually asserted contents of MDL[0:31] with CodeWarrior.

Thus in 64-bit mode CodeWarrior works OK, regardless init.cfg, whereas in 32-bit mode it refuses to 'undestand' odd words. There's something wrong with address translation between CodeWarrior software and system MMU.
Maybe, on-chip debug core must be configured somewhat differently? Is there any way to test it?

PS. Sorry for my nasty English

[Black]

I recommend using a JTAG configuration file for the hardware reset configuration word. You can specify a hardware reset configuration word in project settings Remote debugging->Connection (for example CodeWarrior USB TAP)->Edit Connection->Use JTAG configuration file, with examples and guidelines available in the <CodeWarrior Power Architecture installation folder>\PowerPC_EABI_Support\Initialization_Files\jtag_chains.

There is a known issue that CW 8.7 Flash Programmer does not support multiple-device scan chains. The CW PA 8.7 can't connect to MPC8245 on 2-device scan chain, so please use only the MPC8245 on the JTAG scan chain and have a hardware reset configuration word in the JTAG config file. For the standalone version of your project the hardware reset configuration word must be stored in some board ROM memory.

Then I suggest reviewing your board design and initialization sequence together with a hardware engineer (the board designer if possible).

If the problem continues please create a service request here with the Category Technical Request and topic Design Question.

Thank you.

[Neptune_1]

Thanks for hints!

Where can I find JTAG configuration file syntax description?

Unfortunately I couldn't find any reasonable guidelines in ...\PowerPC_EABI_Support\Initialization_Files\jtag_chains : (

[Black]

Usually for the Hard Reset Configuration Word writing through JTAG the syntax is like : processor core () (RCWH) (RCWL), where RCWH is the Reset Configuration Word High register and RCWL is Reset Configuration Word Low register, like in the following example: E300 (1 1) (2 0x04040006) (3 0x94600000).

The meanings of the parameters inside the JTAG configuration file are:
    Config template index 1 - Boolean value that turns the overriding on and off
    Config template index 2 - Value for Reset Configuration Word Low in format of RCWLR
    Config template index 3 - Value for Reset Configuration Word High in format of RCWHR
Note:
    If index 1 is set to '1', next time reset_to_user or reset_to_debug commands will be
    issued, the core should come up with Reset Configuration Words overridden. It is not enough
    to set index 1 to zero to turn this feature off - power on reset should be issued.

Looking in more details in the MPC8245 processor reference manual I did not find such Reset Configuration Word registers so this procedure will not work for MPC8245 . The G2 core is quite an old core and this feature is not present, it takes the reset configuration word from pins.

I recommend reviewing your board design and if the problem remains please submit a Freescale service request as indicated previously.

Thank you.

[Black]

I looks like your board and SDRAM is not properly initialized.

As a first step you must to be able to debug a project in RAM using a board-specific init.cfg file. Furthermore, "Verify Memory Writes" must be checked in the project's EPPC Debugger Settings panel. Once the debugger can step and run through the main code on the board with Verify Memory Writes on, you can build the ROM version of the project and program the flash.

For a custom board, you will have to write your own init.cfg file with a minimal register initialization to properly configure the board's CPU and peripherals. For a starting point, you can study the init.cfg files from the CodeWarrior support directory (CodeWarrior installation folder\PowerPC_EABI_Support\Initialization_Files). Make a copy of the init.cfg file that's the closest match to your board's hardware configuration and name it my_custom_board_init.cfg. Edit this file to match your board's settings (clocks, RAM, flash, register initialization, memory initialization, and so on) exactly. Now perform a Debug->Connect command with the modified init file selected. To have the Debugger use the modified file, in the EPPC Debugger Settings panel choose Use Target Initialization file and navigate to my_custom_board_init.cfg. Then (if your SDRAM was correctly initialized), you should be able to perform debugging operations on the board.

The same board initialization has to be done in the stand-alone version of the project (ROM version), but from within source code. The my_custom_board_init.cfg file is only executed on the target board at the beginning of a debug session.

You can use the Hardware Diagnostics tool (CW menu Tools->Hardware Diagnostics) with your Target Processor, Connection, and my_custom_board_init.cfg file selected in the Hardware Diagnostics -> Configuration panel when testing RAM memory accesses on the board.