My question was precisely about schematics and the reset. You say jRST must be connected to RST when in fact many schematics have them connected via some transistor circuit. By reference to RST do you mean RST on the STR71?? Is RST on the STR71 required to connected directly tot eh 20 pin JTAG connector?

Are the only signals used by RLIN the JTAG JRST, JTDI, JTMS, JCK and JTDO ??? and nothing else?

We have tried several fully functional embedded boards with same results. All JTAG lines have 10K Pull up except JTDO. The STR712 are massed programmed from vendor. We have also tried with embedded boards and blank STR712. Processors are set to boot from Internal FLASH (BOOTEN = 0)

Hi,

The signals required are these:
GND, VCC, JTCK, JTMS, JTDI, JTDO, JTRST, RST

Yes, "RST" is the STR7's reset signal.
And "JTRST" is the JTAG's reset.

They are different and both required, and they must not be connected to each other, and the RLink must be able to drive them both independently without interference from other components. (a pullup resistor or a small capacitor is OK, but even a strong capacitor could prevent communication)

A transistor (or a resistor) between RST and TRST will obviously prevent the JTAG from operating. Many ST boards contain such a connection, (to prevent accidental reprogramming) but it can usualy be disabled by unplugging a jumper. (which you must do)

Be careful that on different boards these signals have different names:
RST=NRST=RESET=CPU reset
TRST=JTRST=JTAG reset

Please do not use "JRST", as it could be confusing.

Please give us the reference of the demo board that you tried, or the schematic of your board. Then we'll be able to help you more precisely.

Best Regards,

Vincent

Still no progress

Schematic is at http://www.seagauge.com/files/JTAG_Connection_CDI.jpg

Week spent on this and no comunication - no indications of wahts wrong.

ONly JTAG signals and CPU RST connected to RLINK (power and ground too)

This should be very simple but has been impossible.

Embedded CPU starts and runs FLASH code just fine but no JTAG communication

Are there any other tools/utilities to check this out other than RLINK??? as it seems not to want to communicate regardless. We should have able to simply connect the JTAG signals but that is not the case.

Hi,

Thanks for the information.

Unfortunately, a partial schematic is quite useless. There is nothing wrong in the part that you posted, but it is very possible that there is something in the rest of the schematic that prevents the communication. For example, a component preventing the RLink from driving RST, or a connection (transistor) between TRST and RST. Also, if your CPU's clock is slow, you must slow the JTAG clock speed down in the options...

What is the frequency of your crystal?

Is there a connection (or transistor) between RST and TRST on your board?

I understand that your board's schematic is confidential. But you said you had tried many boards... Is one of them a commercial board (from ST or other)? Then I could have the complete schematic, and we could use it to make sure the RLink is not physically damaged.
Otherwise, you can send your board's schematic only to us at . We could even sign a NDA if needed.

I understand and I share your frustration, but it is not possible for the tools to give more details on the problem. The STR7 simply doesn't answer on TDO, and that could come from many things. The RLink and software have no way to tell more than this.

I re-read your first post... Could you please clarify what you meant by "...the suggested jTag Reset circuit minimal requirement ... Is it necessary to build extra reset circuit ...? "
There is no reset circuit required. You only need to connect each signal of the JTAG connector from RLink to STR7, with as few interferences as possible from other components or between them. Even the pullups are not required, because the RLink and the STR7 both contain some.

Best Regards,

Vincent

Sent Schematic via email. Clock is 4MHz oscillator.

Is there any way to test RLINK??? JTAG Inputs?

Sent Schematic via email. Clock is 4MHz oscillator.

Is there any way to test RLINK??? JTAG Inputs?

Hi,

The RLink firmware and USB connection test is the reading of the RLink Serial Number. On your system it works.

The RLink hardware and JTAG connection test is the reading of the JTAG IdCode. On your system it fails...

Please try to slow the JTAG clock down. 4MHz s the default and you might be on the limit. Try 400KHz and tell us if it makes a difference.

To try and determine the cause of the problem more precisely, you could take an oscilloscope and look at the JTAG signals (including RST and TRST) during the test. They should all move at some point during the test. If not tell us which ones move and which ones don't.

We will look at your schematic and tell you if we see something.

Could you please answer my question about what you meant about the "reset circuitry"?

Best Regards,

Vincent

Hi,

I have looked at the schematic. Thanks.

I see nothing wrong with it, but since it's still not complete, that proves nothing. Especially, it contradicts your previous extract a few posts above...???

Here is what you can do:

1. Send us a complete schematic.

2. Slow the JTAG clock down and tell us if it makes a difference.

3. Tell us an estimation of the length of the signals between the RLink and the STR7, including cables, connectors, and on-board lines.

4. Clarify what you meant in your first post about "reset circuitry" and tell us if you have any of this on your board. (and what)

5. On one board, remove all components (including pullup resistors and capacitors) except the STR7, that are connected to JTAG signals (including RST and TRST) and tell us if it makes a difference.

6. Using an oscilloscope, see which JTAG signals (including RST and TRST) move during the connection test, and which ones don't, and tell us the result.

Best Regards,

Vincent

We have removed all 10K Pull Up resistors which were on schematic that was confirmed OK. Cable length is 4 inches from RLIK to Target

Previous error persisted.

Scope on all JTAG lines showed activity during connect attempt. STR712 Reset tied directly to RLIN and no other components stayed High at all times during connect.

We then tried a forced reset by holding STR RST to ground during RLINK connect and we got the following new error.

Error 0x303 during connection to target.
Wrong IdCode detected: 07C3870F
Expected 0x3F0F0F0F

We then next tried a Blank Device with same circuit and observed the STR712 reset did go low during RLINK connect. Additionally we now get:

JTAG Connection to target OK
Target IdCode is : 0x3F0F0F0F
Target is not protected
Do you want to use this protection mask for programming?

We can now also erase and program blank Target STR712. We can also successfully run programs on blank target

However, we can not debug target with RLINK
We now get a OPI Driver Error (1004)
Unable to read IdCode

[Application]
ApplicationPath=O:\development\N2KAdapter_Code\RLink\Hello_Joe\HelloJoe.elf
CSX=0
HighBankAddr=400000
BootMode=0
Format=ELF
CodeOffset=0x0
LoaderTool=ARM
Target=ARM
DebugTool=RLINK_ARM
ApplicationComponents=
[Device]
Name=STR712FR2
[ARMSigDrv options]
CXS=0
[Debug]
Explore=No
Startup=1
StartupSymb=main
ToolName=RLINK_ARM
[ARM RLink options]
Debug=1
CkSpeed=1000
AloneInChain=1
IRB=0
IRA=0
DRB=0
DRA=0
SectorsMask=196863
SectorsProtectMask=0
ProgramMainFlash=1
ProgramSecondaryFlash=1
ProgramUserCode=0
UserCode=FFFFFFFF
ProgramConfiguration=1
ProtectMainFlash=0
ProtectSecondaryFlash=0
LVD_TH=0
LVD_RST_SEL=0
LVD_WNG_SEL=0
OTPLockBit=0
ProgramSecurityBit=0
ProgramOTP=0
OTP=FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
[SimFile]
path=C:\Raisonance\Ride\sim\ARM\STR711FR2.sim

So now we have two different problems.
1) Preprogrammed targets can not connect. Seems RLINK can not drive STR Reset which is just a direct connect.

2) Blank STR712 targets can connect to RLINK and be programmed but not debugged.

From page 11 of ST AN1775

5.2 JTAG / ICE connector
The ICE connector enables JTAG hardware debugging equipment, such as RealView-ICE, to
be connected to the ST7R71x board. It is possible to both drive and sense the system-reset
line, and to drive JTAG reset to the core from the ICE connector. The Figure 9 shows the ARM
ICE connector pin-out.
The STR71x has a user debug interface. This interface contains a five-pin serial interface
conforming to JTAG, IEEE standard 1149.1-1993, “Standard Test Access Port-Scan Boundary
Architecture”. JTAG allows the ICE device to be plugged to the board and used to debug the
software running on the STR71x.
JTAG emulation allows the core to be started and stopped under control of the connected
debugger software. The user can then display and modify registers and memory contents, and
set break and watch points.
In order for JTAG and Chip Reset to be synchronized the J4 jumper must be fitted.
2 STR71x has a Debug Request (DBGRQS) pin, on 144-pin packages only. This active high
signal can be used to force the core to enter Debug Mode, giving the Emulation system access
to internal resources (code, registers, memory, etc). This pin must be kept LOW when
emulation is not being used.
The following table describes the JTAG connector pins:
Std Name STR71x Description Function
nTRST JTRST
Test Reset
(from JTAG
equipment)
This active LOW open-collector is used to reset the JTAG port
and the associated debug circuitry. It is asserted at power-up
by each module, and can be driven by the JTAG equipment.
TDI JTDI
Test data in
(from JTAG
equipment)
TDI goes down the stack of modules to the motherboard and
then back up the stack, labelled TDO, connecting to each
component in the scan chain.
TMS JTMS
Test mode
select (from
JTAG
equipment)
TMS controls transitions in the tap controller state machine.
TMS connects to all JTAG components in the scan chain as
the signal flows down the module stack.
TCK JTCK
Test clock (from
JTAG
equipment)
TCK synchronizes all JTAG transactions. TCK connects to all
JTAG components in the scan chain. Series termination
resistors are used to reduce reflections and maintain good
signal integrity. TCK flows down the stack of modules and
connects to each JTAG component. However, if there is a
device in the scan chain that synchronizes TCK to some other
clock, then all down-stream devices are connected to the
RTCK signal on that component.
GND
(3) nTRST
10K*
3V3
GND
(5) TDI
(7) TMS
(9) TCK
(11) RTCK
(13) TDO
(15) nSRST
(17) DBGRQ
(19) DBGACK**
STR71x
nJTRST
JTDI
JTMS
JTCK
JTDO
nRSTIN
DBGRQS
10K*
(4)
(6)
(8)
(10)
(12)
(14)
(16)
(18)
(20)
GND
3V3
(1) VTref (2)
3V3
GND
10K*
JTAG Connector CN9
CONN_2*10 RA_IDC
J4
J4
* these values are given only as typical example
** The Debug acknowledge to JTAG equipment (DBGACK pin) is not used.
GND GND
10K
47K
3V3
GND
50v
10nF
22K
TR2
TR1
BC846
BC846
Note 1
See
GND
AN1775 5 Debug management
13/27
For more details on the JTAG port refer to the IEEE standard 1149.1-1993, “Standard Test
Access Port-Scan Boundary Architecture” specification.
RTCK
GND
(not used)
Return TCK (to
JTAG
equipment)
Some devices sample TCK (for example a synthesizable core
with only one clock), and this has the effect of delaying the
time that a component actually captures data. Using a
mechanism called adaptive clocking, the RTCK signal is
returned by the core to the JTAG equipment, and the clock is
not advanced until the core had captured the data. In adaptive
clocking mode, the debugging equipment waits for an edge on
RTCK before changing TCK.
TDO JTDO
Test data out (to
JTAG
equipment)
TDO is the return path of the data input signal TDI.
nSRST nRSTIN
System reset
(bidirectional)
nSRST is an active LOW open-collector signal that can be
driven by the JTAG equipment to reset the target board. Some
JTAG equipment senses this line to determine when a board
has been reset by the user.
When the signal is driven LOW by the reset controller on the
core module, the motherboard resets the whole system by
driving nSYSRST low.
DBGRQ
DBGRQS
(not used
w/ 64pin)
Debug request
(from JTAG
equipment)
DBGRQ is a request for the processor core to enter debug
state.
DBGACK
GND
(not used)
Debug
acknowledge
(to JTAG
equipment)
DBGACK indicates to the debugger that the processor core
has entered debug mode.

Is any of this required to DEBUG with RLINK or is just JTAG and direct STR RST and nothing else?

Hi,

Thank you for the detailed feedback. This tells us some very interesting things...:

* The RLink hardware is OK. And USB driver and PC software too.

* The connections on your board are OK. Well, there would be a few more things to check, but I think it's mostly OK.

* The problem is related to the previous content of the Flash. I'm not saying it's wrong. I'm saying it has an impact, and that's a critical hint for understanding the problem.

We're not there yet, but we are making progress. :)

Here are some hints that should help you understand and solve the situation:

* On STR7 devices, JTAG is disabled while the Reset signal is low. So it is not possible to communicate with JTAG, for example for starting debug, without letting (at least a part of) the application execute. Keep this in mind when reading the following points...

* Some low-power modes completely disable the JTAG, and therefore prevent debugging and can make reprogramming tricky.

* The protections (read and write) prevent debugging, and in some cases they can also prevent reprogramming. (by completely disabling JTAG)

* Because of the points above, you have to disable low-power and protections in your application for debugging it.

* Also because of the points above, if the application enters low power mode or activates some protections shortly after its start, then you have to use tricks for erasing it.

* One of these tricks is to tie the reset signal low by hand, just like you did. But it is not convenient and there are situations where it will not work.

* Another trick, which is the official one advised by ST, is to have your application designed in such a way that depending on some inputs it will enter a special mode with no low power and no protections. (or even erase itself automatically)

* Another trick, which is the official one advised by ST in case you missed the previous one, is to use the boot pins to start the CPU in RAM mode for the time of the Erase, then switch back to Flash mode.

To tell you more I would need to have your project here. Or at least tell me if your application uses low power? .. protetions?

Best Regards,

Vincent

Hi,

Our two previous posts crossed each other.

Concerning connections, you only need to connect the JTAG signals and RST directly from RLink to STR7.

DBGACK and DBGRQ can be ignored as they do not get out of your STR7.

As I said in my previous post, with your latest feedback I think your JTAG connections are OK. It's the application that we must inquire now.

Best Regards,

Vincent

As stated we have two separate problems so let’s take the simpler one first.

Starting with a blank device we can now erase and flash code but can not enter debug from Ride.
We started with the UART example. We can load and run and it prints out the UART.

#include

int main( void )
{
printf( "Hello, Joe!!\n" );
printf( "Hello, Joe!_> 1\n" );
printf( "Hello, Joe!_> 2\n" );
printf( "Hello, Joe!_> 3\n" );
printf( "Hello, Joe!_> 5\n" );
while( 1 );
}

If we set breakpoint and Start debug – Ride complains it can not connect and hangs up. We bring up RFlasher7 and need to reset before we can again gain access and try again.

We set debug options on but is there a special library required to link with? Are there special Startup routines? Any other Project settings? Any special register resets? Or is it like all other embedded systems and done only in H/W.

We then tried a forced reset by holding STR RST to ground during RLINK connect and we got the following new error.

Error 0x303 during connection to target.
Wrong IdCode detected: 07C3870F
Expected 0x3F0F0F0F

Is there any information on waht this error means? It read someting back. Is it some mask code?

Hi,

All this is very strange.

I could debug your code without issue by just copying it in the main.c of one of the Ride examples.

This makes me suspect the board again.

Also, the two problems might have the same source, which prevents the JTAG com. You only get different error messages because you are trying different operations, but they all mean the same thing: the JTAG com doesn't work!

Just to confirm things explicitly...

There are no special libraries to link for debugging.

There is no need to change the startup routines for debugging. Are you using the default or custom startup?

There are no project settings to set, except the "Debug" checkbox, which tells the IDE to debug, and which is correctly checked in your project otherwise you would get another error message. Some people use RAM mode, but it's in no way mandatory, and debugging can be performed in Flash mode... Unnless there are some protections set. Are there? (Remember the write protecion cannot be removed.)

There are no special register resets. Of course the application could prevent debugging by writing some values to some registers, but unless you really want to disable debugging, there is little chance that you do this by accident.

It is like "many" other embedded systems, done only by hardware.

Can you send us (support@raisonance.com) your precompiled "hello, joe" project? (zip the whole directory, including elf, sources, obj, lst, etc. ) We'll try to debug it as is on one of our boards. That should finally tell us if the problem is related to the application or to the board.

The "Wrong IdCode" problem I cannot explain. I don't observe exactly this when I connect while pressing reset on my board (I get the correct 0x3F0F0F0 IdCode but the protections are incorrectly reported as activated) and I cannot imagine how this could happen... At least there is very lttle chance that this second problem comes from the code. A hardware problem could do this, but under reset the software should not have any impact.

Are there other JTAG devices in the system? (on the board or chained with it)
Are you sure that the clock is stable and clean?
Could you please try erase the flash, power OFF and ON, then try to connect while tying Reset low? Then tell us if you get the same message or another one.

We really need the complete schematic to tell you more.

Best Regards,

Vincent

Due to the problems/issues we have had with the STR71 and JTAG we have abondoned that effort and moved to the STM32F103.

After purchasing a STEVALIDX001V from ST we still have not been able to get JTAG to work. We connected the RLInk directly the STEVAL-IDX001 JTAG and still get same connection errors as reported when in JTAG protocol. Oddly, we can get everything to work fine when using SWD protocol on the eval board and can now at least compile and debug.

New problem now is that the eval board uses a 16 MHz external oscilator and not 8 MHz. The “Hello World” sample app from the Ride/example/ARM/Reva director will compile and load and run fine with expected results in HyperTerminal over UART1. Our problem now is that most of the other example do not work with the same UART. In particular, using the STMF103 Quickstart, we can not get PRINTF to work at roper baud rates.

After some research it appears to be a problem with the external clock bing 16 MHz and not 8 MHz. After some effort we were able to modify the project to work correctly when using the internal 8 MHz clock HIS (enabled) compared to HSE (disabled).
/* Enable HSE */
// RCC_HSEConfig( RCC_HSE_ON );

/* Enable HSI */
RCC_HSICmd( ENABLE );
We can not seem to find were we can change the HSE clock to 16 MHz and get the project to work.

We did find the
#ifndef HSI_Value
/* Typical Value of the HSI in Hz */
#define HSI_Value ((uint32_t)8000000)
#endif /* HSI_Value */
In the st32mf103X_rcc.c file but no such equivalent for the HSE to tell the project the correct clock.

So, two things.

1) Why can we not use JTAG on the STEVAL-IDX001 but SWD seems to work fine.
2) How do we modify the project files to use a 16 MHz external clock (internal 8 MHz works fine)