I'm likely not smart enough to use st40load.
I always get "Abnormal termination error".

Hi guys.
YLG80 wrote:

QUOTE:
I'm likely not smart enough to use st40load.
I always get "Abnormal termination error".

Eheheheheheheh, take it easy @YLG80. You're doing a fine job. Please, do not give up...
Although not participating, I'm following this thread with great interest and would not like to see this one having the same faith as "mine": - stand still... (for now!)

Best regards.

Interesting ...

QUOTE:

The ST40 User Debug Interface (UDI) conforms to the IEEE 1149.1 standard and uses all five signals defined in the standard (TCK, TMS, TDI, TDO, and NOT_TRST) plus NOT_ASEBRK/BRKACK which is an additional signal specific to the ST40 UDI debug emulation function.

As that pin is an I/O pin (connected to pin7 on my 20 pin connector), the CPU is perhaps waiting for something to switchover from boundary scan mode to TAP debug mode.

[ADDED]

That pin is likely used for break / ack between the DCU tap and and external debugger.
It has nothing to do with TAP mode.

Hi YLG80,

I have found a JTAG flash program (FlashWriterEX) for the SH-4 CPUs, and because the STi71XX based at the SH-4 core it could be useful:

apnet.co.jp/product/superh/flash-ex.html

apnet.co.jp/support/man/fw-ex.pdf

apnet.co.jp/trial/fwex/fwex_tri.lzh

The trial version of FlashWriterEX can only program the first 32k flash addresses and it can be used with the HJ-Link LPT-Port/JTAG adapter, which ist similar the Altera ByteBlaster II:

apnet.co.jp/product/superh/hj-link.html

apnet.co.jp/support/man/hj-link.pdf

Regards

Daggi_Duck

hi YLG80,

i have a bricked fortis based stb. it has mb422ref type pcb. when i run uctap having connected to the board with the recommended "tomas vlad" unbuffered jtag it reports that the cpu is Sti7109cut1x.

what i have noticed that when uctap is started later than few seconds after the stb is powered on then the uctap will report that the cpu is not recongnized. so, it looks like the udi can be used during just few seconds since the stb start and something must be done during this time.

i tried to connect to uctap using few st toolset versions, including st20 and st40. when i used the sh4gdb from st40r2.05 to connect the uctap i got a message like:

The Adaptor code was loaded but has not started.

the uctap window showed some data exchange messages ending with "closing port 9735".

i also tried to replace the adaptor.rcu file from that archive coming with st40load mentioned here few posts above. the result was the same.

st toolsets contain some datasheets and manuals for the development platforms where i saw this:

2. When using the JTAG diagnostic port:
• connect the diagnostic cable to the DCU interface connector (CN1) on the rear panel,
• ensure that the STx7100 processor boots from link mode.

what is that "link mode"? where to ensure? how? this questions are unanswered for me. any ideas?

now i am looking thru this doc http://documentation.renesas.com/eng/products/mpumcu/rej09b0366_7750hm.pdf

it's about the renesas sh7750. it is also based on sh-4 architecture and must be also similar (if not the same) to the STi71xx regarding the udi.

Thank you for your post.

I've also tried to use old toolset versions. No success.
I came to the conclusion that ucTAP is the cause, because it cannot handle the UDI registers.
ucTAP cannot be used with TSi71xx CPU's. (As other posters, I've disassembled that utility and compared it's structure with the toolset ethernet drivers.)

I guess that what the "link mode" is the UDI link mode equivalent to the ST20 TAP link mode.

The CPU can likely enter into this mode if we correctly configure the UDI registers which is not the case with ucTAP.

As I have seen at the AN802 for the FlashWriterEX, many SH-4 cores have a ASEMD or ASEMD0 signal, which is connected at the JTAG interface:

apnet.co.jp/support/an/an802.pdf

Because the pin 8 of the JTAG connector at my STi71xx based receiver, I guess this could be a ASEMD/ASEMD0 signal too. I don't know the meaning of this signal, but it could be important for the JTAG connection.

That pin does not seem to exist in the Sti71xx.

This technical update on bypass mode is likely important (SH-4 H-UDI TAP setup) :

QUOTE:

When using bypass mode of SH-4 H-UDI function, pay attention to the following item:
1. Contents
In IEEE Std 1149.1, there is prescription on the bypass mode as follows.
When the TAP controller transfers to Capture-DR State, the bypass register is set to logic 0.
On the other hand, in SH-4,
When the TAP controller transfers to Capture-DR State, the bypass register has an
undefined value.
2. Workaround
Do not transfer the data expecting the fact that the bypass register is set to logic 0 when the
TAP controller transfers to Capture-DR State on bypass mode.

I broke Opticum9500 sti7101 device by overwriting boot loader, so Im looking for JTAG too,
found some sti files may be it can helps, especialy globo.rar
hxxx://groups.google.ru/group/sti71xx/files

Thanks for that valuable information.
An unexplored path is to use st40load (old version with ucTAP - see post above)
But I've not been able to run that application.(I get always parameters errors)

i did manage to run that st40load and it produced the same results like other stm toolset versions that i downloaded before they shut the door for anonymous access to their ftp.

to run st40load you have to specify correct parameters otherwise you get that "abnormal termination..." message. another thing is that when you use any of the tools you have to do it quick. that is you have to power on your stb, run the uctap server and the tool one by one and within 3-4 seconds.

i did manage to connect to my stb with st20run with no errors allowing to issue the toolset commands. i tried for example to put the u-boot elf image to the RAM memory using the "fill" command. it also passed with no errors but it did not produce the expected effect.

Very interesting.
have you tried what I mentioned in a previous post :

QUOTE:

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.

Perhaps, if you do that, you will have time to run all commands.

That line is always being used with debuggers (see docs link from Lovec47)

what do you mean saying "does not boot"? isn't your box in coma like mine?

Not at all.

That line activation just prevent the stb to boot from flash after a cold reset.
I've tried that just to insure that the bootloader was not disabling the jtag port.

But perphaps that line has also other effects on the jtag port.
I did not realize that the reset timing was so critical.

that's cool. i just destroyed my cable going to rewire it for use with another tool. now i am gonna get it back and try to ground that line. hope it won't be useless.

before i start... does uctap get/report the correct deviceid when loading whith the grounded aserbrk?

Yes, ucTAP reports the correct CpuID.
Please note that you have only to pulse that line down immediately after a cold reset.
I did that manually.
The stb does not boot until you cycle the power off and on

i tried that and did not manage reproduce the said effect. just to make it clear: just after powering on the stb i shortened the line 7 to the ground and released. it did not change the behaviour of the uctap. that is if the uctap started within couple of seconds after the cold reset then it would be able to get the deviceid and it would not otherwise.

after this failure i reviewed the docs and this thread and got totally confused. it is clear that to reproduce the behaviour that you described i have to provide the same conditions. we have the same software, now i have to ensure that i used the same wiring as you and that you have the same jtag interface pinout. so, following your posts i see that you could change the original wiring (the 1st post). it is also inconsistent with the docs... could you please show your exact pinout?

I have used the same wiring as the one recently (one or two day's ago) posted by Slugworth in the other thread related to the Sti5517.(see picture)

What I did is the following :

1 - STB OFF
2 - STB ON
3 - immediately pulse down the ASEBRK line (this was stopping the boot - black display)
4 - Start ucTAP - did correctly identify the CpuID.
5 - tried to launch a toolset test session - no success.

As I did not know that problem with the 3 seconds, I did not do that as fast as I could.

According to pages 361 (382) in ADCS+7153464.pdf I was looking to find same document for ST20 architectore to find diferneces in JTAG between them, and I found this
http://www2.lauterbach.com/pdf/debugger_sh4.pdf

may be it can help too