request to support dct-6412 phase2

[merkin]

thank you donors!

Here is screenshot of tap control in NT


0xFFD7FFF8 = 11111111110101111111111111111000

It is the last 32 bits of the BSR and matches output from my other adapter.

"DETECT" is 0x0 because it is reading the BYPASS register which is loaded on tap reset because this CPU has no "real" IDCODE register.

[usbbdm]

try tap 2 and tap 3. tap1 is ID code. Tap 3 is IMPCODE. You need to know, however, if your IRLength is 5 bit or 8 bit.

[merkin]

go to chat

[merkin]

tap 2 is the DM_SYSTEM register
tap 3 is the DM_CONTROL register


NEC uses PROCTYPE instead of IDCODE
tap 4
-tap 4
Eco :00215520

We need to conrtol the CPU by MON_INST MON_DATA registers

IR LENGTH = 5

[usbbdm]

I see no evidence this is MIPS target.

[merkin]

I see no evidence this is MIPS target.

This would be a whole lot easier is you would just download the datasheet.


You have doubted me this whole thread.

What else should I prove?

[usbbdm]

I have no idea where to download the datasheet. Even it is MIPS if the JTAG port does not follow MIPS standard, it still will not work.

[merkin]

I have no idea where to download the datasheet.

Been posted here many times..... http://web.archive.org/web/201008211120 ... V0UM00.PDF

Check the zip attachments here also. http://www.usbjtag.com/vbforum/showpost ... stcount=19

Even it is MIPS if the JTAG port does not follow MIPS standard, it still will not work.

What do you mean by "MIPS standard" for JTAG port??? (Do you mean EJTAG?)

The facts are in. This is a MIPS CPU supporting instruction sets I-IV with 100% compliant 1149.1 JTAG port.

So I think you should make clear on webstore that you do not plan to try to add support for new mips targets, unless the target has EJTAG port...JTAG port is not sufficient enough for NT.

Meanwhile much effort is spent supporting other cores such as ST40 eventhough NT is sold first and foremost as a mips tool, right? This is disappointing to say the least.

Even if target does not support so called "mips jtag port", then this is still excuses. We both know its also possible to read/write flash by manipulating the boundary scan register. It will be slower, but BSR is only 125 bits. And slow support is better than no support.

Good Luck. Do whatever you feel is best for usbjtag.com. I am getting off this particulair ride.

[usbbdm]

Your first post was made while I was out of town and I never had a chance to look at that post. I will take a look of the datasheet. It does not look like an simple fix as other MIPS target. I would be more interested in support more SPI or even NAND on MIPS target.
One at a time. Some target takes longer than others.

[merkin]

Please try better to answer future and previous direct questions with direct response. And all this time you see me post screenshot of datasheet, but never once ask for a copy. In reality maybe you are not really interested. If that is the case then just say so.

Your first post was made while I was out of town and I never had a chance to look at that post. I will take a look of the datasheet.

I take no credit, it was linked here first in 2009.....and a few times since.
http://www.usbjtag.com/vbforum/showpost ... ostcount=4

It does not look like an simple fix as other MIPS target.

Why do you come to these conclusions before you even get a target donation? Have you even accepted the donation?
Here is quote from one of the datasheets:

The following example describes the steps for downloading data into external
memory using the N-Wire Monitor instruction and data resources. To do this, use
the following sequence:
1. Break into Debug mode with the debug module enabled (DINIT bit cleared).
2. Scan the download data into the MON_DATA register via JTAG.
3. Scan the MFDR instruction into the MON_INST register via JTAG.
4. Set the MON_INSTEXEC bit in the DM_CONTROL register via JTAG. This
causes the processor to execute the instruction in the MON_INST register,
thus moving the data from the MON_DATA debug register (same as debug
register DR2) into a general-purpose register in preparation for a store
operation.
5. Check for completion by checking the MON_INSTEXEC bit via JTAG.
6. Scan a Store instruction into the MON_INST register via JTAG.
7. Set the MON_INSTEXEC bit via JTAG. This causes the processor to execute
the Store instruction in the MON_INST register, thus storing the data from
the general-purpose register into memory.
8. Check for completion by checking the MON_INSTEXEC bit via JTAG.
9. Repeat steps 2&#8722]

I would be more interested in support more SPI or even NAND on MIPS target.
One at a time. Some target takes longer than others.

But who is asking for SPI, NAND, ST40, ARM7/11?
And what gives the idea that this target is harder for you than any previously supported target? It seems more documented than any currently supported target.

More members would be interested in vr5532a support than any/all of the above combined! vr5xxx cpu in DC2 cable/satellite boxes.

Now is the time to speak up members.

[usbbdm]

OK here is my answer to your question.
1. I have many request all over the world asking for ST40 target support and I have already spent big amount of time on it. It is close to finish. I have collected quite a few of them already. Even I got donation of several ST40 targets.
2. Over the years I have collected my self several ARM targets. Remember all the new toys (ipads and cell phones) are all ARM based.
3. The target you are talking about has not yet caught my attention and it looks at least the same complexity as MIPS EJTAG (I think MIPS does not licence the EJTAG to MIPS). Remember it took about half a year to implement the initial MIPS EJTAG and I would expect the same amount if not more on this target. Only one person had so far asked for support this target so far and you expect me spend half a year on it?

4. I do not have a target and not yet even get one in hand to play with.

So this target is not on the priority list yet unless there is more demand to support it.

There are more demand of SPI for MIPS simply from the router (dd-wrt) community. DCT6412 phrase 2 is simply too old.

However the N-wire might be of some interest and I would see if there are other devices will use it.