Trying ucTAP Microconnect emulation for jtagging STi71xx systems.

Unbuffered Interface :

ucTAP utility v 0.2b with Sti7100 cut 3x CPUID in the cpu definition file.

ucTAP port opening window (connected to a STi7100 cut 3 CPU)(screen capture)
The DCU_CTRL and DCU_DEVICE_ACCESS_MASK are not correct ...but who cares.

Sti71xx resources file (to be used with the ST40 TS) :

That utility is for the mb411 board with an stb7109 CPU but can likely be recompiled for different boards. run.bat could also be modified for other platforms.



Flash chips handled by flashutil.c

Code:

M58LT256GT, M58LT256GT_ALT_ID, M58LT128GSB, M29W160BT, M29W160BB, M28W320CB, E28F640J3A, M58LW064Cx16, M58LW032A, E28F640J3Ax16, M29DW324DB, M29DW324DBx16, M29KW064E, M29W640DT, M29W640DB, M29W640FT, M29W640FB, M29W320EB, M28W640FSUx16, S29GL064A /*spansion*/

Here is a JTAG session start with ucTAP and the Homecast HS5001 CI (Sti7100) set top box.(using the ST40 Toolset R4.31)
This test was done just to see if the host can communicate with an ST40 target using ucTAP.
The target used with the sh4xrun run command is simply 127.0.0.1 .



The connection failed on an error :

Code:

[b]Connect to SDI server on STMC 127.0.0.1 failed - the target computer has expressly refused the connection.[/b]

I guess we need to better define the target with the use of the Target Pack by calling the sh4tp command. (using the Python file like mb411_mb442_mb448.py )

An other idea would be to use the STlinux tools and load the U-Boot code into the RAM of the receiver. With U-Boot you have a full flash chip support for reading, erasing and writing of NAND, NOR and SPI flash chips.

Thanks for your very usefull advice.
I'll give it a try.
Unfortunately, up to now I've not been able to use st40load to do that.
But I have made only a few trials.

However reading 'Installing U-Boot on the target, I'm afraid I will be again blocked by the TAP port issue :

QUOTE:

Installing U-Boot On The Target

First of all, it is required to connect to the correct serial port to the target board, (typically ST40 linux's /dev/ttyAS0) from a terminal emulator (running on a host system) with the following communications parameters:

baud=115200, data=8, parity=none, Flow Control=none

In another window on the host system, then use sh4-linux-gdb to download and run U-Boot on the target system, over the JTAG debug link. For example, for executing on a STx7111 Mboard (MB618), then the following would be appropriate.

The STlinux pack included some precompiled U-Boot files for some targets (ST reference boards) and the target definations. I hope that your (our) problem is not the ucTAP emulator and it is only a target board defination problem.

I believe that the antifuse is activated on my Sti7100 STB.

Here is a part of the config jumper for the development MB411 :

MB411 config jumpers :



These jumpers are likely connected to the two BOOTMODE pins ... under the BGA.

An other problem could be the LPT-JTAG connection. At first a passiv (unbuffered) JTAG adapter can give some signal problems and you should try an active (buffered) JTAG adapter. As I see, the TRST signal at pin 19 of the JTAG header could be not right. I have an Edison Argus with STi7100 and if I follow the PCB traces right, it seems that TRST is at pin 7 (has a pull-up 10k resistor) of the JTAG header. The PCB traces from pin 19 (has a pull-down 10k resistor) of the JTAG header are not clearly and therefore the function of this pin also.

Have attention for the STlinux U-Boot flash commands:
http://www.stlinux.com/drupal/u-boot/flash

What is the the write protection action? Is it an internal action of U-Boot or is it an action of the STi71xx core, which will be initiated with U-Boot? The examples for flashing U-Boot or a linux kernel using this write protaction action prior the flash erase ore write action.

Hello,
I'm using a buffered JTAG (PCBWIRE-MULTI) rewired so that it can be used with ucTAp.
I will try to see if I can trace some JTAG Header connections.

The antifuse is no very detailed (of course) in the Sti7100 DS.
It's a register that is not cleared upon a normal reset.
It prevents the TAP port to be used which could explain why the Micro Connect connection is rejected after the first handshaking sequence.

There is likely a state machine controlling the TAP interface.

Two BOOTMODE pins are polled and the antifuse register is checked to see if the access to the TAP port is allowed.
Perhaps changing the state of the BOOMODE[0:1] pins could change the TAP antifuse status.(When one of the Bootmode pins is set to 1, it resets also the ST231 and the ST40 does not boot.)

It would be nice if someone with an Sti7109 could test ucTAP, as that CPU seems not having an antifuse.
I'm doing tests on one of my stb's just for the fun and I do not want to spent too much time on that particular CPU.

You are right : pin 7 has a pull up and 19 a pull down, which is normal for nRST

Hi
In Uctapsrv use port 7600 instead of 9737
Regards

Yessss !
Thank you so much for that information.
Now it seems that the connection goes a step further:
Here is the error message received :

Code:

SDI [error] :: recv failed on handle 924 (shutdown by peer) SDI [error] :: Unable to receive SDI_INITIALISE acknowledge SHDEBUG [ERROR] :: unable to initialise SDI interface.

I guess that the problem comes now from the host that does not send the ack to the CPU. Perhaps I'm not using the right target spec. Thanks for your help.

The connect error "unable to receive SDI_INITIALISE acknowledge" is returned by the sh4sdi-ethmp.dll or by sh4sdi-server.dll.

YLG80 wrote:

QUOTE:
Thanks for your very usefull advice.
I'll give it a try.
Unfortunately, up to now I've not been able to use st40load to do that.
But I have made only a few trials.

However reading 'Installing U-Boot on the target, I'm afraid I will be again blocked by the TAP port issue :

QUOTE:

Installing U-Boot On The Target

First of all, it is required to connect to the correct serial port to the target board, (typically ST40 linux's /dev/ttyAS0) from a terminal emulator (running on a host system) with the following communications parameters:

baud=115200, data=8, parity=none, Flow Control=none

In another window on the host system, then use sh4-linux-gdb to download and run U-Boot on the target system, over the JTAG debug link. For example, for executing on a STx7111 Mboard (MB618), then the following would be appropriate.

At the STlinux mirrors you'll find an old ST40LOAD version from 2002 (e.g. stm-st40load-0.11-3-MSWin32-x86.zip at www.html.ps.pl/mirrors/ftp.stlinux.com/pub/st40load/ ) and it seems, that this version uses some ST20 toolset parts. This could be solve the problems with the ucTAP, which is designed for the ST20 toolset.

Thank you for that information. I've downloaded that old version.
Interesting, as it has, like you mentioned, the same target definitions like in the ST20 Toolset.
But I'm afraid it uses another dll (bkends4si.dll) than the JPI/JEI dll's.
I'm going to try to use it and will report the results.

YLG80 wrote:

QUOTE:
Hello,
I'm using a buffered JTAG (PCBWIRE-MULTI) rewired so that it can be used with ucTAp.
...

Are you sure that you rewired the buffered JTAG adapter right? The LPT pin 12 is the PaperEnd status signal input and not an output signal! This signal comes from the JTAG pin SRST (system reset) and will be monitored for the right TRST timing.

Yes, my interface works perfectly with the ST20 TS on a STi51xx STB.
But you are right with that pin 12 question. It' s not consistent.
I've made trials on a different congiuration bu I finally returned to the original ucTAP wiring in order to use the same configuration as Slugworth when we were doing tests.

This is what I posted on ftatalk a few months ago :

QUOTE:

YLG80
03-18-2009, 02:19 AM
I'm still questioning myself on the ucTAP interface configuration with pin 19 of the JTAG connector being connected to pin 12 of the LPT DB25 connector.

I've made tests with that configuration and it does not work with my STB, although moving pin 19 to pin 17 on the JTAG connector looks correct.
Thanks to that mod on pin 17, the STB can be reset via the inferface w/o having to cycle power while launching ucTAP.

Connecting pin 12 of de DB25 to pin 19 of the JTAG connector means connecting two inputs together with no signal to drive them.
nTRST is an input to the DCU and DB25 pin 12 is also an input to LPT status port register.
This is not consistent.

I would assume that pin 19 (nTRST) of the JTAG connector should be driven by another LPT output pin.
-----------------------------------------------------------------------------------
YLG80
03-18-2009, 05:02 AM
I've probed the pins with a scope while launching JKEYs and ucTAP.
Pin 6 of the DB25 LPT interface is used by ucTAP and not by JKEYS.

When starting JKEYS, pin 6 goes to LOW and remains LOW even after stopping JKEY's.
ucTAP raises that pin HIGH first and then triggers that pin low (short pulse) which leads me to conclude that this pin should be used to drive pin 19 of the JTAG connector.
I've again modified my buffered JTAG in accordance with that conclusion.
Now it runs OK but with one condition :
running JKEYS once before running ucTAP. (When launching JKEYS, the reset signal is released and the STB becomes operational. When quitting JKEYS, the STB returns to reset state. Thus this pin signal should be inverted)
ucTAp can run OK because JKEYS resets pin 6 to LOW prior to run ucTAP. ucTAP alone leaves that pin HIGH when we quit the flash program.
To fix that issue, the signal going from LPT DB25 pin 6 to pin 19 should be inverted for example by means of a transistor driver or a simple logic inverter.
The beauty of that configuration, is that ucTAP properly resets the STB.
I've scoped a full ucTAP/flashprg session (verify) and it shows that pin 6 is used to reset the STB upon starting the flashprg verification.

An additional information on the UDI /TAP interface.
I've read tons of docs on the SH-4 / ST40 CPU's in order to find more info on the JTAG question.
There is an additional signal on the JTAG connector : NOT_ASEBRK which is wired to pin 7 of my JTAG connector. That line is pulled up.
This is an ST40 debugger breakpoint I/O line.

If I connect that line to the ground while doing a cold reset, the STB does not boot even if I let that line rising to a high level after the cold reset.
The STB needs to be reset again while leaving that line high in order to boot normally.