Re-flashing the P3041DS

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Re-flashing the P3041DS

No ratings

Re-flashing the P3041DS

I showed in a previous posting, how to update an SDK image from within U-boot. In that example, however, I didn't heed my own advice, and initially I burned the FMC uCode image to the wrong place in flash. Upon rebooting, I no longer had Ethernet connectivity, and needed to re-flash the FMC code through my debugger, Codewarrior. In this posting, I'll attempt to walk through what I did to recover, to give you an idea of how to re-flash the P3041DS, or even a bare board through a debugger.

First, we need Codewarrior. I'm currently using version 10.2 on a Windows host, though it looks like Codewarrior 10.3 is the latest available at this time. You also need a hardware TAP, either a USB Tap, Codewarrior TAP, GigaTap or Ethernet Tap. For the P3041, this needs a COP interface 16-pin header. My USB tap is loaned out, so I'm using an Ethernet TAP, which provided the added convenience of being accessible over a LAN.

For the purposes of this article, I'll assume I've blown away everything in NOR flash (including the RCW). This will be a similar scenario to a blank board back from the factory. In this case, in order to connect with a debugger we'll need to set a hard coded RCW. From the P3041DS documentation, I see that DIP Switch SW1 configures the RCW_SRC


I need a hard coded RCW option, so I'll look through the P3041RM to find out what cfg_rcw_src should be set to.


From this, I determine that I want to set cfg_rcw_src = 1_0010, so I set SW1 on the DS appropriately.


Note that on the DS system, "ON" = '1'

After reconfiguring SW1 to a hard coded RCW option, I plug in my Ethernet TAP probe tip into the COP header.


Note the pin1 location, and line up the probe tip appropriately.

Now, it's time to fire up Codewarrior. Codewarrior is eclipse based. I won't go through a large eclipse tutorial - but I'll demonstrate some of the basics. One of the first things Codewarrior does, is ask you for a workspace location. A workspace is a containing folder for any projects you might have. In this case I created a new folder called workspace_community.


I'll create a new project for this. A project contains files I might compile and download to a bareboard, initialization scripts, and settings for how to connect to the board. Select FILE / NEW / Power Architecture Project

I'll name my project P3041DS and click Next.


Next, select the appropriate processor


Build settings would be used typically for building code, in my case it's really a don't care.


I'm only using Core0, so I press NEXT, and then finally I select my TAP connection. In my case, I'm using an Ethernet TAP with IP address


I'm not planning on using trace, so I can click Finish on the next screen and am now presented with a Codewarrior coding prospective. I'm not interested in writing any code, so I'm going to set up my debug connection. To do this, I click on the small downward pointing arrow next to the bug on the toolbar, and select Debug Configurations.


There are three ways to connect to a target:

  • Attach will attach the debugger to a running target
  • Download will reset the target, initialize it, and download code to the target
  • Connect with reset, initialize the target and pause

Note that the reset and initialization are optional and can be configured.

I'm going to use Codewarrior Connect, and I'll select that option for my project. To configure my connection, I can select Edit, next to the connection.


Here I see my connection type is Ethernet TAP with the correct IP address, as I previously selected in the new project wizard.


If I wanted to change my initialization script I would select Edit, next to the Target.


This brings up a screen with options for connecting to the specific target. You have the option to reset the core, or not, as well as the option to initialize the target with a script. The default scripts can be used as a reference for a custom board. They initialize parameters such as DDR, MMU, local bus in order for the debugger to gain access to these peripherals. Again, I won't go into details. There is Codewarrior documentation included in the installation, typically found within the C:\Program Files\Freescale\CW PA v10.xx\PA\Help\PDF directory.

In this case, I am using the standard P3041DS system, and will just go back to the main debug "Debug Configurations" screen and click debug. This will initiate a connection to the target via the Ethernet TAP, and change the eclipse prospective to the debugging prospective.


I see my target has stopped at the reset vector of 0xFFFFFFFC. In the bottom right I have a debugger shell. If it isn't present in your view, you can enable it through Window / Show View / Debugger Shell

Within the debugger Shell, I can type in commands directly to the debugger. For example, to read and verify that DDR works, I will dump  20 locations startion at address 0x0

mem 0x0 20

This should return 0xdeadbeef on the default project, since that's the value flash is initialized to in the initialization file. I can do the same to flash:

     mem 0xe8000000 20

And this should return the first 20 locations of flash, which is where my reset config word should be stored. If both of these return data, we are ready to burn flash.

The codewarrior flash burner is run through target tasks in Codewarrior 10.x. A target task defines the flash interface, addresses and images to be burned. Within to target task view, click on the green plus icon to add a target task.


This will bring up a window where we can name the task. Task type should be flash programmer. The Hardware Diagnostic task type is useful for running memory tests, but that is discussed in the Codewarrior documentation. Run Configuration describes how we connect to the board. Since I am already connect to the target through a project, I select Active Debug Context.


A view should show corresponding to the task created. At this point, we need to add the flash device. YThe flash base address is ou can change the organization by clicking to the right of the organization within the Add Device window. This will show a pull down menu with the various organizations.


Base address is configured through the initialization script. By default this is set to 0xE8000000. Target RAM defines a buffer on the target for the algorithm to use. And towards the bottom of the view, one can add Flash Programmer Actions, which describe what is to be done. Examples include erase, or progam a file. It's possible to set up multiple actions, such as erase the entire flash, program the RCW, FMC uCode and Uboot.

In this picture, I am adding an action to program the RCW, which is contained in a bin file, to location 0xe8000000. Since a binary has no offset, I need to apply address offset of 0xe8000000 to the file. I instruct it to erase sectors before programming as well, and restrict the actions to the sectors affected.


When I've added everything needed, be sure to save the target task. Below is a screenshot of my target task to update the RCW and Fman UCode.


I'll save it to the framework, which means it's part of the project.

Then, to run the flash programmer, simply click on the green "play" arrow in the target tasks view. The programmer should run and if sucessful, will print out a message in the Codewarrior flash programmer console.


You may now disconnect codewarrior (red stop button icon), and try to boot up your system. Remember the DIP switches are still set for a hard configured reset config word, so I'll be sure to change them back first.

Labels (1)

Hi Paul,

Thanks for the useful document above. I have a few questions hopefully you can give me some hint:

1) You show in the document on how to flash rcw and fman ucode into the flash. So the process of flashing u-boot is also similar?

2) How do we debug u-boot (compiled in yocto environment) with code warrior and USB Tap? Is there any documentation on this process?

I am also interested in the flashing of u-boot. If there is it would be nice.


The u-boot at P3041DS must be written in the last 512KB of the NOR flash. Yes, the process is similar, just please use the start address from 0xeff80000.

For u-boot debug please take a look in PA\Help\PDF\Targeting_PA_Processors.pdf about

<5.4.6 Debugging U-Boot from NOR, NAND, SPI, and SDCard/MMC flash devices> chapter.



I will make just a small specification about Flash Programmer routine. It's very simple to use the "already prepared" flash programmer target task instead of making some new ones.

Just right click and import the desired FP target task for your board. The best part with these provided target tasks comes from the fact that they are already built with all necessary flash devices and memory setups.



Hi Marius,

I have reinstalled the latest CW and manage to find the document Targeting_PA_Processors.pdf.

The document mentions that we have to build u-boot with Code Warrior Debugger support or build u-boot elf file. It is talking about the folder iso/help/documents/pdf where I can find steps on how to do these but I have no idea where this folder is.

How do I build u-boot elf or build u-boot with CW support in yocto build environment?

Anyway I think I find the answer to this. It is inside the QorIQ_SDK_Infocenter.pdf document. There are steps on how to build u-boot to support CW. 

Is it correct these steps are also for generating u-boot elf file?

Q: How to build u-boot/kernel with debugger (CodeWarrior support)?

A: For u-boot:

1. $ cd <yocto_install_path>

2. $ bitbake -c cleansstate u-boot

3. Modify the file and add following content:

• $ cd meta-fsl-ppc/recipes-kernel/u-boot

• $ add 'EXTRA_OEMAKE += "CONFIG_CW=1"' in file

4. Rebuild u-boot:

• $ bitbake u-boot


I am a hardware engineer and am confused by how to associate the cfg_rcw_scr(0:4) to the actual Hardware Signals. The confusion results in not being able to determine the most significant bit for the cfg_rcw_scr bits.

For your hard coded table shown above, Table 4-32, for a 1_0010 equating to cfg_rcw_src(0:4), what is the most significant bit, cfg_rcw_src[0] or cfg_rcw_src[4]?

For the LGPLx hardware signals shown below, it is ambiguous which is the msb when you write cfg_rcw_src(0:4) = 1_0010. Hardware convention suggests that the left most digit is the msb and it is cfg_rcw_src(0).


Cfg_rcw_src[0] = LGPL0


Cfg_rcw_src[1] = LGPL1


Cfg_rcw_src[2] = LGPL2


Cfg_rcw_src[3] = LGPL3


Cfg_rcw_src[4] = LGPL5


Can you clarify the ambiguity?



The bits (on Power Architecture, at least) are typically written MSB to LSB (left to right). So, in the case of cfg_rcw_src[0:4], crg_rcw_src0 is the MSB. This corresponds to LGPL0.

So, when writing cfg_rcw_src[0:4]=1_0010:

cfg_rcw_src0 = lgpl0 = 1

cfg_rcw_src1 = lgpl1 = 0

cfg_rcw_src2 = lgpl2 = 0

cfg_rcw_src3 = lgpl3 = 1

cfg_rcw_src4 = lgpl4 = 0



Thanks for getting back to me. I have a followup question.

Why are the bits displayed showing a  underscore “_” between bit 0 and 1?


What is the significance of the underscore… is it just to break up a nibble for easier viewing?

Based on this response, we have been misinterpreting the Hard Coded POR Config inputs as well as the non-hard coded POR Config.

What happens when you go to a reserved value?

Our board was designed a couple of years ago but we continually get strange behaviors.



The underscore just makes it easier to read - nothing else. It's sometimes used to break up a nibble.

The reserved values could be anything. Sometimes they're blank - and they mean nothing. Sometimes they're internal test modes, etc...

For most of these QorIQ parts we list things MSB to LSB. For example I have the P3041RM open right now.

LAD[0:15] - LAD0 is the MSB

LCS[0:7] - LCS0 is the MSB

EC1_RXD[3:0] - RXD3 is the MSB

Version history
Last update:
‎05-06-2013 08:08 AM
Updated by: