CW TAP custom JTAG chain

[azdem]

Hello all,

I have been trying to connect to a custom board, having 2 FPGAs and a P2010 QorIQ processor on the same JTAG chain, using CW TAP.

How/Where can I define this custom chain?

There is very little documentation within the CW Studio help. However, all the multi-device-chain examples are all Freescale devices. I can not find any documentation on defining a non-freescale device. 

I have both tried the board bring-up procedure with GDBProxy and the CW Studio. Any clue on this subject is welcome.

Best regards,

Aziz

[nishad_kamdar]

Hello,

I too have a custom P1022 Board.

I am facing the same error as you were.

Error launching Code_1-core0_RAM_P1022_Download

CCSProtocolPlugin : Failed to reset the target

[CCS last error: Draco/m HIP8: ELF is not in expected HALT mode ]

Could you specify exactly what changes did you do to get rid of the error?

Thank you for your time.

[azdem]

Thank you again Heinz!

I have somehow managed to connect the HRESET & CKSTP0 correctly, as recommended with "must" & "should".

So, I am one step further, now. CW Debugger can reset the CPU and read some registers, as far as I see from thee CCS log.  However, I consistently get some error messages, which say:

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

CCSProtocolPlugin : Error reading memory

[CCS last error: cannot start SAP transaction ]

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

CCSProtocolPlugin : Error reading memory

[CCS last error: Core not responding ]

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

CCSProtocolPlugin : Error writing memory

etc.

We have already checked the related pull-up/down connections etc. They seem ok.

Next, I should probably edit the given init.tcl script according to our board. You have recommended starting with a minimalistic script at another post. Do you have any examples, for that?

Regards,

Aziz

[hwrobel]

Start with something like our CodeWarrior P2010DS_init_sram_flash.cfg scripts. The SRAM based scripts are fairly easy to adapt to new boards, as DDR setups on new boards usually take some time. The SRAM based scripts also provide a good starting point for testing a board or for flash programming as the internal L2 SRAM is a reliable type of memory from the start. Study the script well and also study what CodeWarrior memory configuration files do.

If transactions happen to invalid memory areas that are not configured/decoded, the transactions may not be able to complete, which leads to SAP transaction issues. Remember that the debugger does transactions much like the CPU or DMA channels, so bad references from the debugger can also mess up the target.

The “SAP failing” scenario is only effectively recoverable through a reset, which is why you would want to study the script and memory config files well to go step by step on your board.

Also, it is better to start with “Connect” rather than “Download” to do basic memory and register checks initially. One step at a time. Downloads should only be done if you have made sure that you have valid memory to download to.

[azdem]

I can't see any *.cfg files, can it be *.tcl? or are there some other config/init files somewhere else?

By the way, would that QCS (QorIQ Configuration Suite) be helpful to generate some bare metal relevant config/init files? or is it only useful with uboot & Linux kernel?

Thank you very much & best regards

[yipingwang]

There should be DDR controller initialization problem on your target, please try to use P2010_init_sram_flash.cfg in <CW PA v10.x\>PA\PA_Support\Initialization_Files\QorIQ_P2 to connect to the target.

QCS can assist you to configure DDR controller according to your target.

[azdem]

Hi again,

we are a kind of stuck, although the CW TAP & the CW debugger seem to work properly. Without an init file, we can connect to our target board and read out some of the internal registers. We can even change the values of these registers afterwards. However, some registers can not be read or written at all. For example, we firstly want to set the L2CTL register, in order to configure the L2 cache as SRAM, as described at AN3646 and we get "SAP transaction" or "ELF is not in expected HALT mode" error messages.

I have one concrete questions at this point:

Is it normal that the TRIG_OUT/READY_P0 signal goes high and the ASLEEP goes low, after releasing the HRESET (as shown on Figure 4-5, P2020 reference manual), although the cfg_cpu_boot has a pull-down, which should make the CPU hold off? How can I check that the processor do really hold off, till I connect over the TAP?

Thank you again & kind regards

[hwrobel]

Do not ever trust pull-ups or downs just because they are there on the PCB, especially if anything else is connected to the very same pin(s).

Many things can be on such pins externally, e.g., on the local bus or PHY interfaces, and depending on loads or internal pull-ups/downs in such devices, it can change what is actually on the line. FPGAs could pull this way, PHYs could pull that way, reset sequencers triggering external devices could actually change that behavior even while the P2 stays in reset. All sorts of things are thinkable.

Keep the board in reset (A simple push button or jumper will help there) with the clocks active(!) and then measure every and all pins that have a footnote in the EC to make sure that all have their intended value without any doubt during reset. I state “all pins with a footnote in the EC” instead of “all config pins” and I mean it. Really.

Differentiate between core registers and memory mapped internal registers. Core registers require less from the setup. If you can read and write them well, not all is bad and your physical debug link likely isn’t so bad. This does NOT mean that the core(s) will run well or at all if the config pins are not as they should be.

Memory mapped addresses, registers or not, will only be available if no SAP transaction issues have happened before and if the access path to such registers is configured well. Only the CCSRBAR space and the boot source are readily accessible after a reset unless appropriate measures in the init script or boot software are taken.

Internal memory mapped registers will only be accessible if the debugger init script did not access any unmapped location anywhere and if the debugger does not have any open memory windows targeting currently unmapped spaces and if the core’s SP is set to an odd value in the init script so that the debugger does not try to find a stack backtrace … which all would also cause SAP issues immediately if that memory is unmapped. Our SRAM/Flash based init scripts in CodeWarrior show how to do some of this right.

A SAP transaction problem is usually unrecoverable without reset, so avoid generating them by not trying to be too creative with the debugger until the system has been set up. Broad configurations of memory configuration files in CodeWarrior can help to avoid unmapped transactions, though they are just a protection against unsafe behavior on the user’s part typically.

Hope this helps

[azdem]

Once more thank you very much for your kind answer.

All pins with footnote have been checked, with oscilloscope, for real; but (un)fortunately still no HW bug has been discovered. We have also analyzed all the e500v2/P2010/P2020 relevant init scripts.

A few concrete questions about them & CW debugger:

You are right. We are able to read only the core registers, which do not require a memory mapping setup. When I connect (no dowload) to my target, using only reset & without setting any init file, I do not get any explicit error messages. However, a lot of ccs_in transactions take place on the background and I see a periodical (every 500ms) JTAG activity using oscilloscope. First, I have assumed that, it is the auto-update of register & memory, but it still exists when I disable the auto register/memory read out.

In the end, these ccs_in operations usually return a SAP or ELF error on the CCS logging console and I get to reset the target again. I think I have to disable this functionality somehow, so that I do not get any SAP transaction error in the beginning. Is that possible?

Actually, even if they do not return any errors, which happened only a few times, I was unable to access the CCSRBAR register, although I could set IVPR, DBCR, IAC, etc. without getting any error messages.

On the other side, all the related init scripts try accessing the CCSRBAR register, right after applying the e500v2 workaround or even before, in order to map the CCSR space. Either way does not work on our target. Are we missing something in between?

Best regards & happy new week,

Aziz

[hwrobel · Accepted solution]

Now is the time to take the CodeWarrior version, the minimum init script you are using, the CCS log corresponding to a Connect with that script, a description of any actions taken until an error occurs, and the board schematics and open up a Service Request on the Freescale web.

Seems that whatever the issue is, it is a bit too tricky for a simple discussion.

Once the S/R has been resolved, it would be nice though if you could post what the issue finally was,

Thanks,

Heinz

[azdem]

It may seem unbelievable, but the Service Request is still open. (We doubt that our SR contact reads the log/diagnostics files, that he wanted from us. He seems to be badly overloaded, that he can contact us only once a few weeks) We are unfortunately a bit disappointed about the Freescale Support. So, no improvement on the CodeWarrior side.  

On the other hand, the free/open-source GDB solution, which was recently offered by Freescale, works on our HW, just as expected. So, we could absolutely verify that the HW is ok.

[jorge_plascencia]

HI Demirezen,

Did you get the solution from this issue on your SR?

Regards,

[hwrobel]

In an older CW release, we write:

In addition, you can specify other chips to debug on the JTAG chain. To do so, you use
the following syntax to specify the chip as a generic device:

Generic <instruct_reg_length> <data_reg_bypass_length> <JTAG_bypass_instruction>

Having written that, I have no HW means to test if this [still] works exactly the same, but it is certainly simple enough to be worth an attempt.

[azdem]

Dear Heinz thank you for your answer!

I have defined it as below

=========================

P2010

Generic 10 1 0x3FF

Generic 8 1 0xFF

=========================

However I  consistently get the following error message, doesn't matter I comment out the generic devices or not. I can't figure out the reason. 

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

Error launching bring_up_v0.0-core0_RAM_P2010_Download

CCSProtocolPlugin : Failed to reset the target  [CCS last error: Draco/m HIP8: ELF is not in expected HALT mode ]

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

By the way, my JTAG chain seems to be intact. I mean, I can scan the chain with two different tools and read the IDcodes correctly.

Best regards,

Aziz

[hwrobel]

Let me suggest that you contact your local Freescale support or open an S/R with us that includes a precise definition of your chain and the devices attached, possibly also the P2010 related schematics.

If the board is known to work, it seems likely that it is only a JTAG config file issue and our CW experts should be able to help given detailed information.

If the board is new, it could also be different problem keeping the P2010 from being accessible. In classic single chip JTAG setups, what you see usually indicates some incorrectly wired pins that allow JTAG to function but prohibit the more complex debug access. Just to be sure, please check all pins of the EC doc that contain a footnote and ensure they have the right voltage during reset.

[azdem]

One last question:

Are all COP signals (HALTED. SRST, HRST, QACK, CKSI, CKSO) needed for CW Debug or the standard JTAG signals are sufficient alone?

I have used & I can use only the JTAG signals. That may be the reason for that "Failed to reset the target" error.

If so, are these signals also needed for gdbproxy connection? Is it possible at all, to connect to the debug interface with only JTAG signals?

Regards,

Aziz

[hwrobel]

Follow the JTAG recommendations in AN4309. The debugger will not be able to control the target without separate control of TRST and HRESET.

[azdem]

That's a kind of bad news.

As I understand, this is valid for all CCS-based connection. So, the CW TAP won't help us much.

[hwrobel]

No JTAG based debugger from any vendor will help you if you do not have the debug connector hooked up correctly.

JTAG signals alone will never be sufficient, they are just the foundation. HRESET on the connector per the appnote is the bare minimum of additional necessity, and depending on the debugger used, more signals or at least their default state on the connector may be required.

This has nothing to do with CCS or CW TAP. It is a generic requirement for debugging to have the debugger connector to spec.

See also the CW TAP manual pdf, Table D.2 for additional information and check for “Must”, “Should”, and “May”.