Great thanks for prompt reply.

I have installed:
Ride7 IDE ver 7.14.0001
RKit-ARM for Ride7 ver 1.13.0810
RLink Driver version 6.2.0.0
RLink Driver Date 01.04.2004 (probably it matters)

When I press 'Resotre default Option Bytes now' in RFlasher it says 'Option Bytes programming failed!'
The FULL caption on the chip body is:
ARM Y
STM32F103
R8T6
220PN 93
MLT 22 824

Thanks,
Andrew

Hi,

Thanks for the information.
Unfortunatelly, for now I don't understand what could be happening.
Your versions of software and hardware are fine.

The RLink driver version and date do not matter, as it is only the low-level USB driver.

Can you please give me the Silicon Revision Id of your chip?
You can see it when clicking "connect to target" in RFlasher.

Do you have other STM32s to try?
Other boards?

I will probably need some information on your board too. (and other things) Please fill this form:
http://www.raisonance.com/Forum/punbb/viewtopic.php?id=2231

Best Regards,

Vincent

Hello,
I have exactly the same problem.
When I am programing, reading blank checking etc. microcontroller on evaluation PCB everythings works OK. But when I am trying to do the same things on my own PCB I have the same messages as Andrew (nordic). I have also installed newest version of Ride and ARM-kt but it has not helped.
I guess that there is a problem with JTAG connections (but I have checked them carefully and everything looks ok) or with processor itself. When I am checking connection to the target it shows Silicon Revision Id=20036410 and in case of evaluation board it shows Silicon Revision Id=20016410.
Maybe that is the reason why this microcontroller bahaves incorrect.

Somebody can help us to solve the problem?

Maciek.

Here are my answes to the long form (hope it will help):

0. Questions on the Raisonance tools... (we will need that even for the simplest question)

0.1. What is your Customer Serial Number, if you have one? (open RIDE, click "help"->"About" and look for "Serial Number", or send us a screenshot)
Fully functional, no serialization needed

0.2. What is the version of your Software? (RIDE)
If in RIDE7, what are the versions of your RIDE kits? (open RIDE7, click "help"->"About" and look for "installed products", or send us a screenshot)
Ride7 IDE 7.14.0001
If you are using some other software (STVD, CAPS, ...), then we will also need the name(s) and version number(s).
None. But if you send me a link I will definetely try.

0.3. What kind(s) of RLink(s) do you have? (REva? RLink-Std? RLink-STX?)
the caption on the package is: STX-RLINK

1. Questions on the RLink...

1.1. Does the PWR LED turn ON when you connect RLink to the PC?
Yes

1.2. Is the USB driver correctly installed?
Yes

1.2.1. Does the BUSY LED turn ON and then OFF when you connect RLink to the PC?
Yes

1.2.2. Does RLink appear under the Jungo section in Windows device manager when it is plugged?
Yes

1.2.3. What is your host system? (CPU, version of Windows, service pack(s), etc.)
Windows XP, SP3

1.2.4. Can you read the RLink Serial Number? (open RFlasher, select any ST7 or ARM device as target and RLink as programmer, click "connect to RLink")
dngSTD000010423
Note: if you think that the USB driver is not installed, reinstall RIDE or run "RLinkUSBInstall.exe",
which is available on the RIDE CDs and in the RIDE installs.

1.3. What is your RLink(s) Serial Number? (see 1.2.4. above. the SN is NOT written on the RLink itself)
Yes

2. Questions on the target...

2.1. What is your target CPUs? (we need the complete name of the derivative.)
STM32F103R8T6

2.2. What is your target board(s)?
custom board

2.2.1. Please send us the schematic of the board.
I will ask my bosses

2.2.2. If it is a commercial board, what is its manufacturer and exact reference? (and have you modified it?)
I can't open up this info now

2.2.3. What is the configuration of the jumpers and switches on the board, if any?
I can't open up this info now

2.2.4. How do you power the board?
over USB

2.2.5. If we need to get the real board for testing, under what conditions would it be possible? (sign a NDA, return it after the tests, ...)
Probably, I will ask my bosses

3. Questions on the problem itself...

3.1. Please describe the problem you are experiencing as precisely as you can...
When I press 'Resotre default Option Bytes now' in RFlasher it says 'Option Bytes programming failed!'

3.1.1. What software are you using? (RIDE, RFlasher, CAPS, STVP7, ...)
Ride7 IDE ver 7.14.0001
RKit-ARM for Ride7 ver 1.13.0810

3.1.2. What is the simplest sequence of operation that we can perform in order to trigger the problem?
When I press 'Resotre default Option Bytes now' in RFlasher it says 'Option Bytes programming failed!'

3.1.3. How does the problem manifest itself? (please write down all error messages, if any, or make screenshots)
When I press 'Resotre default Option Bytes now' in RFlasher it says 'Option Bytes programming failed!'

3.1.4. Did the problem appear in a configuration that was working before?
No

3.1.5. If the answer to the previous question was "yes", can you think of anything that changed between the last time it succeeded and the first time it failed?

3.2. Do you have any comment or personal interpretation of the problem? (Please give it to us)
see sections 3.1.2, 3.1.2

3.3. Please make a few tests...

3.3.1. If you have other software, (from ST, Signum, ...) do they all show the same problem? (please tell us what you could test and how it went)
I don't have any other software

3.3.2. If you have other programmers/debuggers, even other RLinks, do they all show the same problem? (please tell us what you could test and how it went)
I don't have any other debuggers

3.3.3. If you have other boards/CPUs, (demo boards, ...) even other boards identical to the one showing the problem, do they all show the same problem? (please tell us what you could test and how it went)
I have also checked the Reva bard (STM3210B with daughter board and STM32F103RBT6) and Option Bytes can be successfully programmed there (with the same debugger).

3.3.4. If the problem appears with a particular application, can you send us your project?
Note: If we need it, we will need the complete project folder, including source, include, object, hex and listing files.
In some specific cases, the hex file might be enough, but we cannot guarantee that.
We can sign NDAs if this information is confidential.
We can work with a reduced version of the application, if it shows the same problem, but we need a complete project that we can recompile here.

3.3.5. If you only have one application, please try to reproduce the problem with one of the examples provided with RIDE, or try to reduce your application until there is only the minimum remaining for showing the problem.

4. Do you allow us to share the information in the answers to this form with our partners?
Note: This is NOT for advertising purposes. Depending on the problem you have, our partners (mostly, but not only, the chip manufacturers like ST) might have more technical information than us on the cause of your problem and be able to answer faster and more accurately, or just to help us a little.

Thank you for taking the time to answer.
You will see that it has not been wasted, because it allows us to provide you with fast and efficient support.

on our board
RTCK, DBGRQ, DGBACK signals of 20-pin JTAG interface are connected to the ground.
Could that be a reason for malfunction ?

Hi,

Thanks for all this information.

In your answers to the form, I see that you manage to connect to the REva.
That means that the software (and USB driver registration) is fine.

Here are the descriptions of the RLink connectors:
http://www.raisonance.com/Forum/punbb/viewtopic.php?id=2449

Pin 3 should be connected to the TRST signal, (which is called JNTRST in the STM32 datasheet) which is NOT the same as RST (called NRST in the datasheet).
Your problem could very possibly be that you have either connected TRST to RST, or that you have not connected one of these signals between the STM32 and the RLink.
If the problem is that you have not connected TRST from STM32 to RLink, then switching to SWD should work around it, as SWD does not use this signal.
If the problem is linked to RST, (either not connected from RLink to STM32 or connected to TRST) then I'm afraid you will have to modify the board's design.

Pin 11 is not used for STM32.

The RTCK, DBGRQ and DBGACK to ground should not be a problem, even though I don't see why you did this. (increases power consumption on the RLink USB, but we don't really care)

One last question: you say that you power the board through USB. I guess that you mean the board's USB, not the RLink's USB like in the REva board. Can you please confirm?

If you send schematics or other files to us, please send them to this address:

And include a link to the associated forum post in the body of the email.

Best Regards,

Vincent

Thanks for you help,
Andrew

I have sent NDA papers to . I hope that after we get them signed I will be able to send board schematics for review.
Thanks.

I am the designer of Nordic's board.

I basically copied the JTAG interface from a combination of the ones used on the Keil MCBSTM32 development board and the ST Micro STM32E-EVAL board. However there are some variances. At the time, I could not find schematics of any Raisonance development boards on the web. Since the Keil and STM boards had JTAG conectors with the same pin out I assumed it was standard for all vendors of STM32 tools.

The 10K resistors to ground on pins 11, 17, and 19 are in the STM32E-EVAL design. If they are a problem, they could be removed of course. The Keil design leaves these pins unconnected to anything.

The Keil MCBSTM32 has a 22K pull up resistor on the TMS line while I specified a 2.2K. Could be I need better glasses. Is 2.2K too strong a pull up? The Keil board has no other pull ups or pull downs on the TRST, TDO, TDI, or TCK lines while the STM32E-EVAL has 10K pull ups on TMS, TRST, TDO, and TDI and a 10K pull down on TCK. The STM32 data sheets say that all five of these lines have the correct internal pull ups and pull downs so that external resistors are not needed. Are they or are they not needed?

The IC's system reset pin, nRST is connected to a 0.1uF (100nF) capacitor to ground in parallel with a normally open pushbutton to allow manual reset. There is no pull up resistor. The STM32 data sheets say that there is an internal pull up resistor so that an external one is not needed. Is 0.1uF appropriate? Is an external pull up resistor recommended?

System power is provided by a separate USB connector (not the one connected to the RLINK/ULINK) which then is connected to a LDO regulator.

BOOT0 and BOOT1 are each connected to 10K resistors which is then connected to the center pin of a 3 pin header. Each header also has a ground and VCC connection so that BOOT0 and BOOT1 to be set to a 0 or a 1. This is how these lines are shown in the STM AN2606 document.

Some STM32 boards have a 1M resistor in parallel with the crystal and some don't. Should one be there?

Hi,

Nordic,
For switching from JTAG to SWD, you just need to select it in the advanced debug options in Ride7, or in the programming options in RFlasher. You don't need to change any jumper nor any other hardware manipulation, as the SWD connector is a subset of the JTAG connector.

We will sign the NDA and send it back to you.

RandMan,
The 20-pins connector is an ARM standard, so it is indeed the same for all STM32s, Cortexes, and even ARM7, ARM9, etc.

The RLink includes 4.7K pullup resistors on all its signals.
The 10K pullups are fine.
I think it's worth trying to replace the 2.2K on TMS with a 22K, and to remove the 10K pulldowns. (or replace them with 100K)
The capa on reset should not be a problem, but it's also worth trying to reduce it.

We have tested the RLink on the STM3210E-EVAL board from ST, so if you took it as reference, then it should be fine. I don't know about the Keil board.
You will find the schematics of the REva board and STM32 daughterboard in the Ride documentation (in the folder where you installed Ride). You should also be able to find the schematics of the STM32 primers (which include a RLink and a STM32) on our website. (along with the CircleOS sources, probably)

I don't know about the 1M resistor on the crystal. I suggest you do as ST does on the STM3210-EVAL. (for power too)

I should be able to tell you more when I see the schematic.
It might be a good idea to send it to ST for reviewing too. I will not transfer it to them myself because of the NDA, but I can put you in touch with someone that can help, if you are willing to send him a NDA too. Or maybe you already have a contact there?

Best Regards,

Vincent

Hello Vincent,
I have sent our board scematics to the technical support.
Can't wait to hear your verdict.

Huge thanks,
Andrew

Hi,

I don't see anything wrong in your schematic.
Have you tried to remove the 2.2K resistor on TMS? (or replace it with a 22K)
Is it any better?

Yesterday I realized that your version of the chip is more recent than the ones I have.
So I got a few like yours from ST and checked them.
They work fine on the REva board with the same version of the software that you have.
So it's not a problem of chip revision.

How do you configure the BOOT0 and BOOT1 pins?

Have you looked at the REva board schematics?
for the daughterboard:
C:\Program Files\Raisonance\Ride\Doc\ARM\REva_User_Guide_STM32.pdf
for the motherboard:
C:\Program Files\Raisonance\Ride\Doc\ARM\REVA_v3.3_EvalPart.pdf

Best Regards,

Vincent

Hi,

I am working with Andrew (nordic).

I just had Chase (who works with Randy) replace the 2.2k resistor (R58 on the schematic) for a 24k (the closest to 22k we had available) and remove the three 10k pulldowns (R64, R65 & R66) on board 6. My unmodified board used for comparison is board 5.

The short answer is that the mods do not appear to have made any difference.

Connecting with an RLink unit over the JTAG connector using the JTAG protocol doesn't work for either board. Pressing "Connect to target and display information" returns an "Unable to read IdCode" error.

Connecting with the SWD protocol works for the "Connect to target and display information" press, with both boards confirming that the connection is OK, returning the Silicon Revision Id and warning that "FLASH is READOUT protected!".

Attempting to write the target option bytes (with read-out protection unchecked) thinks for about 11 seconds and then returns the same error in both cases, "Option Bytes programming failed."

Attempting to erase or write target flash results in the same "Plugin timeout expired." error for both the modified and unmodified boards.

I also have the REva kit board with the STM32F103B daughter board. With this setup I am able to connect and display target information, program the option bytes, erase and write the flash successfully with the same software tools and procedure.

I have tried to use the bootloader for all three cases, and have not gotten so much as an ACK back yet. I assume this is my inexperience with the bootloader as I can't get it working for the REva board either.

Randy, I am going to leave both the modified (06) and unmodified (05) boards with Chase. If you could try and get the bootloader up and running with either or both boards, that would be great as you have much more experience with this procedure than I do.

Vincent, hopefully you have the schematic by now. Any suggestions you might have would be greatly appreciated.

cheers,

Chris

I have found that ground in JTAG connector on our actual board is not connected to ground on the board. However connecting it didn't help to solve the problem. The result stayed the same.

Hi,

Please note that once you have connected to the STM32 in SWD, you have to disconnect and reconnect power if you want to switch back to JTAG. This is probably the explanation why you cannot read the IdCode in JTAG now but you could before and you can in SWD. Please check and confirm that.

Now that you mention that the bootloader doesn't work too, I suggest we inquire towards the STM32 CPU execution. What you observe (able to read JTAG IdCode but not the option bytes, no response from bootloader, etc...) makes me think that the JTAG/SWD connections are fine, but the problem is rather in something like power, clock, reset, etc. that prevents the CPU from running.

Have you checked with a scope that the clock is oscillating at the correct frequency and that the signal is clean? (maybe you can try to remove the crystal and send a clean and powerful clock from an external device, just to check.)
Have you checked that the RST signal goes up fast enough after power on? (maybe you should try to remove the RST capa, or to add a pullup resistor)
Have you checked that the several STM32 powers are at the correct value and stable enough? (are the decoupling capas close enough to the powers?)
How do you set the jumpers for the BOOT0 and BOOT1 pins? On our boards we stick BOOT1 to VCC through a pullup, and BOOT0 can be either 1 or 0, but you should connect it to zero for normal operation.

I think ST support would be able to help you better than me on these issues. Have you tried to contact them?
I'm afraid I will reach the limits of my knowledge on this problem. I would need to have the board here to tell you more, but I think it is simpler that you send your schematic to ST for reviewing.

Best Regards,

Vincent

Hello Vincent, thank you very much for you help.
I checked the idea with BOOT0, BOOT1 and it didn't help.
I also tried to start debugging in RAM (the documentation says it is possible even with Read-out protection) but Ride said "Wrong boot mode detected".
Probably Randy will be able to check the other things.
Thanks