RLink
Dear customers,
Here is a list of questions that we will ask whenever you request any support from Raisonance about RLink.
If you plan to contact us by email, telephone or on the forum, please include all this information in your message (or have it ready to hand if calling on the phone).
You might even find the problem by yourself while answering. 
For an easier, faster and more efficient support, the best is to copy the text below in an email, answer each question, and then send it to "support@raisonance.com".
0. Questions on the Raisonance tools (we will need this info even for the simplest question).
0.0. 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).
0.1. What is the version of your software? (RIDE).
If in Ride6, what is the Build Number of your Ride6? (open Ride6, click "help"->"About" and look for "BN", or send us a screenshot).
If in Ride7, what are the versions of your Ride7 kits? (open Ride7, click "help"->"About" and look for "installed products", or send us a screenshot).
If you are using other software (STVD, CAPS, ...), we also need the name(s) and version number(s).
0.2. What kind(s) of RLink(s) do you have? (REva? RLink-Std? RLink-STX?).
1. Questions on the RLink.
1.1. Does the PWR LED turn ON when you connect the RLink to the PC?
1.2. Is the USB driver correctly installed? 1.2.1. Does the BUSY LED turn ON and then OFF when you connect RLink to the PC?
1.2.2. Does the RLink appear under the Jungo section in Windows device manager when it is plugged in?
1.2.3. What is your host system? (CPU, version of Windows, service pack(s), etc.).
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").
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 above. the Serial Number is NOT written on the RLink itself).
2. Questions on the target...
2.1. What is your target CPU? (we need the complete name of the derivative).
2.2. What is(are) your target board(s)?
2.2.1. Please send us the schematic of the board.
2.2.2. If it is a commercial board, who is its manufacturer and what is its exact reference? (and have you modified it?)
2.2.3. What is the configuration of the jumpers and switches on the board, if any?
2.2.4. How do you power the board?
2.2.5. If we need to get the real board for testing, under what conditions would it be possible? (sign an NDA, return it after the tests, ...)
3. Questions on the problem itself...
3.1 Please describe the problem you are experiencing as precisely as you can...
3.1.1. What software are you using? (RIDE, RFlasher, CAPS, STVP7, ...)
3.1.2 What is the simplest sequence of operation that we can perform in order to trigger the problem?
3.1.3. How does the problem manifest itself? (please write down all error messages, if any, or make screenshots).
3.1.4. Did the problem appear in a configuration that was working before?
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).
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).
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).
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).
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 at Raisonance.
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 to show 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.
Best regards,
The Raisonance support team
^top
RLink
Q. I have an RLink Driver installation problem on Win XP SP3. What can I do?
A. There has recently (around January 2009) been an 'update' from Microsoft in the Windows XP SP3 driver installation procedure, that changes the way drivers are selected when there are several candidates.
It uses the .inf file date tag to select between the drivers that it finds and chooses the latest (in previous versions it asked which one to take, when it found several). It also always searches on CDs, even when you tell it not to (before the update it searched the CDs only if you asked it to, and only if it did not find a preinstalled driver in DriverStore). As a result, it now tries to use the RLinkWinUSB driver, which is for Vista, when it should use the Jungo driver, which is for XP.
The workaround is:
Remove the Ride CD from the drive after installing Ride and before plugging in the RLink.
Then Windows just takes the Jungo driver that the Ride installer has preinstalled in the DriverStore directory, like it did before the Windows update regardless of the CD in the drive.
This has also been worked around in the latest CDs, available on our website since last week, by removing the 'unpacked' version of the drivers from the CD. (You can still find all the drivers after installing Ride in <RideInstallDir>\Drivers\...). Unfortunately all CDs that were shipped before that to distributors along with RLinks, Primers or REva boards might show this problem (only on XP with automatic update activated, or very recent Windows with brand new PCs or CDs).
If you have already attempted (and failed) to install the RLinkWinUSB driver, then you must uninstall it before you can install the Jungo driver. For this you must plug in the RLink and tell the Windows Device Manager to uninstall the driver. In case of problems, here is an advanced procedure for that, more complex but with more chance of success:
You must also take care not to let Windows search in "<Ride>\Driver", as it would find both drivers and MAY select the wrong one (or maybe not, but don't take that risk...). So, if you select the manual driver search, you must point to "<Ride>\Driver\RLinkDrv\Jungo_WinDriver_2000_NT_XP\..." if in XP, and to "<Ride>\Driver\RLinkDrv\MS_WinUSB_XP_Vista\..." if in Vista.
Here is the RLink documentation, which contains mostly a summary of the USB driver problems and solutions:
ftp://www.raisonance.com/pub/RLink_USB_ … dRLink.pdf
Thanks to klausr and hairykiwi for their detailed feedback. More information here:
http://www.stm32circle.com/forum/viewtopic.php?id=113
^top
RLink
Q. RLink USB driver on Windows Vista and/or 64-bit PC
A: (25/08/2008) The latest version of RIDE includes a new driver (WinUSB/RLinkWinUSB) for Windows Vista and Vista64. You must reinstall all your RIDE kits to use the new driver. You might also need to uninstall the old driver (Vista32). You can download it here: http://www.raisonance.com/download/index.php (end EDIT 25/08/2008).
The USB driver for RLink that is installed by the RIDE installer (v7.0.0) does not work on some systems with Windows Vista or 64-bit CPUs. Here is a version (V7V) of the installation that should work in these systems (as well as the older systems like Windows XP and older that use the old driver (Jungo/RLinkWDP)): ftp://www.raisonance.com/pub/RLink_USB_ … 080606.zip
To install it you must have administrator rights. Note that this version does NOT work under Windows Vista64.
Troubleshooting:
If you installed the old driver (the one for XP), or if you plugged RLink before installing the Vista driver, or if your user account management is not as admin as you think (often happens in Vista), then you might be unable to install it. Here some things to try to make it work.
Make sure you are logged on as Administrator AND run the "RLinkUSBInstall.exe" using the "run as administrator" option, then follow this uninstallation procedure in case you have a wrong driver loaded:
- Plug the RLink, and if any driver is loaded for it, go to the device manager and ask Windows to uninstall it. I don't expect that to have much effect, but it's cleaner to try it. If you see a "Jungo" section in the device manager, please also try to uninstall it. Then, unplug the RLink.
-
Windows makes backup copies of rht inf files it installs.
You must remove these backup copies for the uninstall procedure to be complete:
Search C:\Windows\inf directory for "oem*.inf" files containing either "Jungo" or "RLink". (use grep or something similar)
Remove all those files and the associated oem*.pnf files.
To check that the uninstall procedure is complete, you must be able to plug the RLink, tell Windows to search the driver automatically, and get an answer like 'no compatible driver found'.
- Remove all the files, directories and reg keys (using regedit.exe started as admin) in the list below. In DriverStore, try to remove the directories. If you cannot, remove as many of the files in them as you can. Also remove the registry entries if you manage to do it. You'll need to change the ownership to yourself, recursively, then give "everyone" the complete access to the keys/directories/files, then you should be able to remove them. Being an administrator is not enough with Vista. You have to trick it all the time. ;( Here is the list of things to remove if they exist:
Files and folders:
- C:\Windows\inf\Windrvr6.*
- C:\Windows\inf\RLink*.*
- C:\Windows\System32\Drivers\Windrvr6.*
- C:\Windows\System32\Drivers\RLink*.*
- C:\Windows\System32\DriverStore\FileRepository\Windrvr6*.*
- C:\Windows\System32\DriverStore\FileRepository\RLink*.*
Reg keys:
- "HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Enum/USB/VID_138E&PID_9000/..."
- In Windows XP, the driver store is called "DRVSTORE" and not "DriverStore". So you must also search
- C:\Windows\System32\DRVSTORE\FileRepository\Windrvr6*.*
- C:\Windows\System32\DRVSTORE\FileRepository\RLink*.*
- When you have removed everything you can, run RLinkUSBInstall again (in admin mode, not just while being logged as admin) leave it at least 2 minutes to complete and then plug the RLink. Check that you see the BUSY LED turning ON (means the RLink is started) and then OFF. (means the USB enumeration has been done, and therefore that the driver is correctly loaded)
If you followed this complete procedure and still don't manage to use RLink, please contact us: "support@raisonance.com".
Before that, please run the uninstallation/reinstallation procedure above a second time and write down all the details about what you did, tried, succeeded, failed, which files and registry keys you removed, which files and registry keys you tried to remove but didn't manage, which error messages you got (if any), and the log of the execution of RLinkUSBInstall (use an admin DOS prompt an redirect the output to a file).
Here is the RLink documentation, which contains mostly a summary of the USB driver problems and solutions:
ftp://www.raisonance.com/pub/RLink_USB_ … dRLink.pdf
^top
RLink
Q. I get strange debugger behaviour when using GCC with optimization. Why?
A: In recent versions of GCC, which are provided with Ride7, when optimization is activated, a line of C code is often split in two (or more) parts. The first part is for initialization and the second part for execution. For a block of C code, the initialization of all lines of C code in the block is done first, followed by all the executions. This allows factorization of the initialization parts between several lines of C code or other really efficient optimizations.
The drawback is that debugging is much less convenient. This also often makes people think that there is a bug in the compiler or debugger when in fact it's just optimization.
For example...
- Open this example: <RideInstallDir>\Examples\ARM\REva\STM32F103_Toggle\STM32F103_toggle.rprj
- Configure it for Flash mode and activate optimization level 1.
- Compile, start debug, place a breakpoint on the first line of the main while loop of the 'main' function.
- Execute until it reaches the break, remove the break.
You should now see something like this:
Here you can see that some (but not all) C lines of the loop are associated with two blocks of assembler each. The first block is for initialization and the second block is for execution.
Here is the same screenshot with red lines showing the association between the C lines and assembler blocks:
When you set a breakpoint from the C window, Ride has to set it on the first block associated with the C line, which is the initialization.
This means that the breakpoint that you have set is on the initialization of the line, so if you step in the C code (press F7 in the C window), it will execute the initialization of the function. If you only look at the C code, you might think that it has executed the line but in fact the LEDs have not changed. But if you go on stepping a few times, then it will go back to this line and perform the execution a little later.
To understand this better, try stepping in the C in this example while observing the execution sequence in both the C and assembly windows.
Now that the problem is identified and explained, here is what you can do to work around it:
- As much as possible, perform the debugging of your code in optimization level zero. Activate optimization only after the C code is validated.
- Trust GCC. Code very similar to yours has been tested with every optimization level and all compiler options during the validation process of the compiler (unless you are doing something very, very, very unusual). Although compiler bugs do happen, they remain very rare. ('developer bugs' are much more frequent
)
- When you see strange things happening (PC going back when stepping, variables not updated when you think they should be, etc.), look at the disassembly view and try to understand what it does. Watch out for 'split code' (two or more blocks of assembler for a single line of C). Also, give it a few more C steps as second chance.
- Expect useless code to be stripped out without notice: If myvar is not volatile, the first statement of this code: { myvar=2; myvar=3; } will be optimized out and the variable myvar will never be equal to 2. This is normal optimization. Always use volatile variables for delay loops and such. (See the code of the Delay function in the example above.) Make sure you know what 'volatile' means and does, as GCC has much less remorse about optimizing out accesses to non-volatile variables than most other compilers (always staying inside the boundaries set by the C standard, of course). So if your code works in opti level 0, but not in opti level 1, it is not necessarily a compiler bug. It is more likely to be a non-volatile variable that should have been volatile, or something like that.
- You can try to isolate the line of code that you really want to observe in a separate function. Then, when it is validated, you can either put it back in the calling function, or declare the sub-function as static, so that it is inlined in the calling function and produces no more code than really needed.
Here is a quote on this topic from the official GCC website:
The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.
Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.
Complete document here:
http://gcc.gnu.org/onlinedocs/gcc/Debug … tions.html
And other related information here:
http://gcc.gnu.org/onlinedocs/gcc-4.1.2 … -Code.html
^top
RLink
Q. How does the 32K limitation for ARM work?
A: First, note that the Raisonance software for ARM is completely free of charge.
There is no limitation on the compiler, assembler, linker, library manager, etc. and you can always download the update from our website.
The only limitation is on hardware debugging with RLink.
For ARM devices there are two kinds of Raisonance RLink: the standard (STD) and the professional (PRO).
Raisonance Primers normally contain an RLink-STD.
Raisonance STM32 Primer-Pro contains an RLink-PRO.
The RLink-PRO allows unlimited programming and debugging.
The RLink-STD allows unlimited programming, and of course the CPU will have access to all memories and peripheral registers.
The RLink-STD allows debugging up to 32K. This limitation starts at the beginning of a debug session:
- If the application you want to debug uses more than 32K of Flash or more than 32K of RAM, then Ride will not start the debug session at all (it can use 31.9K of Flash and 31.9K of RAM).
- If the application fits within the limit, but during execution the PC exceeds this range, then the debug session will stop.
(NB You may think that you have reached the debug limit, when in fact it's your stack or PC that is corrupted by wrong code).
Note that altough the Program Counter cannot exceed the 32K limit, the ARM is still able to access all peripheral registers.
All RLink-STD (including those in Primers) can be upgraded by software to the RLink-PRO functionality.
^top
RLink
Q. How to get free 16K version for RKit-STM8.
A: Here are the steps to follow to get this 16k license after you installed the software Ride7 and RKit-STM8:
- Open Ride7 and go to the menu "Help", enter your name, the name of your company and click on next.
- Select "Manual activation".
- You should arrive at the "Activation code registration" where you have the fields "Serial Number"(empty), "Serial Key"(given) and "Activation
Code" (empty). Please note that you do not have a serial number so leave this field empty and do not worry about it (it is only for people who bought a software license).
- Leave this window open and go to: http://www.mcu-raisonance.com/stm8_st7_registration.html
- Enter the required fields and submit. You will be redirected to a webpage named "RKit-STM8 Lite Toolset".
- Enter the Serial Key numbers given in the Ride7 window you kept open into the field "form1" and click "get your activation code"
- You will receive this code by an email (the one you entered) and you must enter this code in the same page window of Ride7 (the activation code field).
To be sure that you are correctly registered you can see "Help Ride7" and you should have the message "Lite suite".
^top
RLink
Q. How can I use the RLink for ARM: JTAG-SWD-ADP?
A: The RLink uses the standard 20-pin JTAG connector.
Here is the pinout summary:
- GND: 4,6,8,10,12,14,16,18,20
- VCC: 1,2
- TRST/*: 3
- TDI/*: 5
- TMS/SWDIO: 7
- TCK/SWDCLK: 9
- RTCK/*: 11
- TDO/*: 13
- RST: 15
- DBGRQ/*: (17) do not connect
- DBGACK/*: 19
*: Do not connect for SWD. Connect for JTAG (except DBGRQ).
NOTE: RST (CPU reset) and TRST (JTAG reset) are two different signals. They must not be connected to each other, and they must both be connected between the RLink and the target CPU.
The two jumpers of the adapter must always be left in the 'JTAG' configuration.
The 'SWD' markings are a mistake on our part.
Note that the protocol SWD is not supported by the PC software Ride7 version 7.14.0001 and RKit-ARM version 1.13.0810
When you have the adapter in front of you and can read "JTAG-SWD" the two jumpers must be on the left for both JTAG and SWD protocols.
Adapter schematics can be found here: ftp://www.raisonance.com/pub/forum/RLin … _ARM20.pdf
^top
RLink
Q. Debug problem using JTAG protocol with RLink
A: If you meet a problem with RLink using JTAG protocol, check the RST and TRST signals.
There are two signals that must be checked for debug purposes: RST and TRST. The correct configuration is described below:
RLink CPU
RST ---------------------- xxxxxRST
TRST ---------------------- xxxxxTRST
On your board make sure that:
- these two signals are indeed connected to the corresponding signals of the CPU,
- these two signals are never connected together (),
- these two signals are not changed by external control during Programing and Debugging processes.
^top
RLink
Q. How do you get the serial number of your RLink?
A: Here is how to get the serial number of an RLink:
If you use Ride7:
- Choose RLink as Debug Environment in the ARM Advanced Options.
- Select Options Properties Configuration Options.
- Click on the box "Connect to RLink and read Serial Number".
If you use Ride6:
- Select "Real Machine" and check RLink is the tool in Options.
- Select Options->Environment(tab)->Advanced Options.
- Click on the box "Connect to RLink and read Serial Number".
If you use RFlasher you have a button on the panel named "Connect to RLink [and read serial number]"
You can also get the serial number by entering "RLinkCapab.exe" in any windows cmd prompt if you installed RIDE, or download the application from this link.
Note: this serial number is different from those used for registration. The latter correspond to a license, not to an RLink product.
^top
RLink
Q. Where can I find information about the RLink connectors?
A: RLink uses adapters to connect to the different targets. All these connectors follow the standards designed by their respective designers (ARM for ARM-JTAG, ST for ST7-ICC and STM8-SWIM, etc.).
Here are links to the PDF schematics:
The list of older adapter schematics is available below:
And here is the description of all these connectors and their equivalence on the 24-points generic RLink connector. You will need this if you need to use a protocol that did not exist when you purchased the RLink, or if you loose or break an adapter.
JTAG connectors
********************************
JTAG | SWD | 20 pts(ARM) | 24 pts(RLink3) | 14 pts (uPSD)
| | | |
GND | GND | 4,6,8,10,12,14,16,18,20 | 3,4,10,17,19,21,22 | 3,10
VCC | VCC | 1,2 | 1 | 7
TRST | - | 3 * | 6 | 2
TDI | - | 5 | 8 | 5
TMS | SWDIO | 7 | 12 | 9
TCK | SWDCLK | 9 | 13 | 11
RTCK | - | 11 | 5 | 1
TDO | - | 13 | 15 | 13
RST | RST | 15 * | 11 | 8
DBGRQ | - | (17) do not connect | 9 | 6
DBGACK | - | 19 | 16 | 14
- | - | - | 7, 14 | 4, 12
* Attention:
RST and TRST are two different signals. They MUST NOT be connected to each other!
TRST (also sometimes called nTRST, JTRST, nJTRST or JNTRST) and RST are required for ARM and uPSD devices.
You MUST connect these two signals from RLink to the target CPU.
ICC connectors
********************************
signal | 10pts(ICC) | 24 pts(RLink3)
| |
GND | 1,3,5,10 | 3,4,10,17,19,21,22
ICCDATA | 2 | 6
ICCCLK | 4 | 7
RST | 6 | 9
VCC | 7 | 1
ICCSEL/VPP | 8 | 18
12MHz | 9 * | 20
* Use the 12MHz signal from RLink for clocking your ST7 device only if there is no external clock
(crystal or oscillator) on the target board and you don't want (or cannot) use the internal RC.
Sending several clocks to the ST7 is a bad idea!
If you are not sure, you should place a jumper on your board for allowing to cut the 12MHz signal from RLink.
SWIM connectors
********************************
signal | 4pts(SWIM) | 10pts(ICC-like)| 24 pts(RLink3) | 20 pts(REva2)
| | | |
VCC | 1 | 7 | 1 | 1,2
SWIMDATA | 2 | 2 | 6, 12, 15 * | 3,7,13
GND | 3 | 1,3,5,10 | 3,4,10,17,19,21,22 | 4,6,8,10,12,14,16,18,20
RST | 4 | 6 | 9 | 17
* All three pins must be connected.
An additionnal 2K2 pullup resistor on SWIMDATA is required if there is no pullup on the target board.
The resulting pullup, taking the RLink internal pullups in consideration,
should be around 1K and never less than 500 Ohms.
^top
RLink
Q. RLink for ST7 - ICC-SWIM ADP usage
A. What is the 10-pin connector pinout ?
The RLink uses the standard 10-pin ICC connector defined by ST. Other programmers from ST or that have been in any way validated by ST, very probably use the same connector. To make sure, look at the ICC documentation from ST. Here is the pinout summary:
GND: 1, 3, 5, 10
ICCDATA: 2
ICCCLK: 4
RESET: 6
VCC: 7
ICCSEL/VPP: 8 (not used for ST7Litexx)
12MHz: 9
Which position should I use for internal movable connectors of the adapter ?
Do not plug "Adapt" and "SWIM". They are not for the ST7. ("Adapt" should not give any trouble though).
Plug "12MHz" if you want the RLink to send a 12MHz clock on pin 9 of the ICC connector.
Plug "PW_5V" if you want the RLink to send a 5V power on pin 7 of the ICC connector for powering the target board (see below).
What is the adapter's lateral connector function ?
Like the "Adapt" and "SWIM" jumpers, this is for SWIM, not ICC(ST7). Just ignore it.
Do I have to insert a +5 volt power into adapter, or does the power for the application board come directly from my PC ?
You do NOT need to power the RLink or the adapter.
The RLink is powered from the USB.
The RLink I/Os are powered either from the target board or from the RLink.
Your board should output its power on pin 7 of the connector.
If you want the board to use its own power then do not plug the "PW_5V" jumper and the board will power the RLink I/Os.
If not, then you can use RLink to power the board and the RLink IOs by plugging the "PW_5V" jumper.
I didn't find a hardware schematic of adapter outputs on your CD-ROM. Where is it ?
Documentation about the connector is in the ST7/ICC specification from ST.
^top
RLink
Q. STR912F daughter board for REva : Workaround to make I2C work.
A: We have found a design conflict on the REva STR912F daughter board that prevents I2C from working properly.
Here is a workaround for people wanting to use I2C with the STR912F daughter board:
Hardware modification:
- Remove jumper SCL/J2.60 on the REva motherboard.
- Solder a stem on the J2.58 pin of the REva motherboard, connect it to the SCL pin of the same SCL/J2.60 jumper support.
Software modification:
- Use the following code snippet to configure the GPIO ports according to this modification:
void GPIO_Configuration(void)
{
GPIO_InitTypeDef GPIO_InitStructure;
// Port 0 configuration: I2C0 SDA
//-------------------------
GPIO_DeInit(GPIO0);
GPIO_InitStructure.GPIO_Direction = GPIO_PinOutput;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_1 ;
GPIO_InitStructure.GPIO_Type = GPIO_Type_OpenCollector;
GPIO_InitStructure.GPIO_IPConnected = GPIO_IPConnected_Enable;
GPIO_InitStructure.GPIO_Alternate = GPIO_OutputAlt2;
GPIO_Init(GPIO0, &GPIO_InitStructure);
// Port 2 configuration: I2C0 SCL
//-------------------------
GPIO_DeInit(GPIO2);
GPIO_InitStructure.GPIO_Direction = GPIO_PinOutput;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0;
GPIO_InitStructure.GPIO_Type = GPIO_Type_OpenCollector;
GPIO_InitStructure.GPIO_IPConnected = GPIO_IPConnected_Enable;
GPIO_InitStructure.GPIO_Alternate = GPIO_OutputAlt2;
GPIO_Init(GPIO2, &GPIO_InitStructure);
}
^top
RLink
Q. How to use and register Ride7 under Windows Vista
A: Administrator privileges under Windows Vista are harder to handle than under Windows XP or previous versions. Here is what we recommend in order to avoid problems with registration under Windows Vista :
It is mandatory to launch Ride7 with administrator privileges if you want to use the Register from the web option, because Ride7 needs to be allowed to connect to the Internet.
To make this work correctly, instead of launching Ride7 the standard way (for example double-clicking on its icon), right-click on the RIDE icon and select "Run as administrator", like on the picture below :
Then you will be able to use the Register from the web option from Ride7 .
It is mandatory to use this procedure when launching the Ride7 installation program (install.exe), to ensure it has full access to the filesystem.
UPDATE:
Unfortunately, the registration information is only be available when Ride7 is launched as administrator.
So it is recommended for now to always launch the program as Administrator, until we find a better solution.
This FAQ entry will be updated with this information.
In order to ensure that Ride7 is executed as Administrator, please follow this procedure :
1. Right-click on RIDE.EXE and select Properties
2. Open the Compatibility pane
3. Check the Run this program as administrator option
4. Click OK.
Each time Ride7 launches, Windows Vista will ask for a confirmation that you allow this program to execute.
We hope that a better solution to handle registration will soon be in place (2007).
^top
RLink
Q. RCST7: Always prefer the UNSIGNEDCHAR directive
A: The code generated for SIGNEDCHAR is less optimal than the code produced for UNSIGNEDCHARs. This is due to the ST7 architecture.
Moreover, when using enumerations, RCST7 has the capability of using the enum values as if they were of CHAR type (the C standard mandates that enum values should be of int type).
In the following snippet of code, the DISABLED enum value is defined as 0x80.
- If the UNSIGNEDCHAR directive is activated, then the enum can be treated as a CHAR.
- But if the SIGNEDCHAR directive is applied instead, the compiler converts the Init_Value valiable to an int, which produces much bigger code.
Conclusion:
Use the UNSIGNEDCHAR directive whenever possible (it is the default option for RCST7). Enforce this requirement when using enums with ENUMTYPE(char) activated.
#pragma SIGNEDCHAR ET(CHAR)
typedef enum {
DEFAULT = 0x00,
ENABLED = 0x01,
DISABLED = 0x80
} ENUMTYPE;
void check(ENUMTYPE Init_Value)
{
if (Init_Value & 0x80)
{
/* ... some code */ ;
}
}
^top
RLink
Q. Why can't my RLink connect to STR710?
A: There are two known issues you can check:
- The STR710 evaluation board MB393B cannot be programmed by RLink and Ride7.
This issue is fixed in versions more recent than Ride7 7.14.0001 and RKit-ARM 1.13.0810. If you have this version or older, the workaround is:
- Close Ride7 and RFlasher7.
- Open c:\program files\raisonance\ride\sim\arm\str710FZ2.sim(or STR710FZ1.sim).
- Replace fNeedTRSTforReset=0 by fNeedTRSTforReset=1.
- Run the software again.
- RLink-STD last version. There is a problem on RLink-STD (the version in the dark gray box) on the STR710 (but not on the STR711, 712 or 715).
To workaround it, cut pin 17 of the 20-point connector of the RLink ADP, as shown in this picture:
[img]ftp://www.raisonance.com/pub/forum/STR7 … nk_cut.jpg[/img
RLink
Q. STR9 is broken - JTAG does not respond anymore. What can I do?
A: Sometimes, a working STR9 stops working after a program is downloaded to it.
Then, RFlasher and Ride7 answer something like "STR9 Boundary Scan TAP IdCode mismatch: ...".
And you are not able to erase or reprogram the part. This is very probably the manifestation of a hardware bug that is documented in section 2.14 of this errata sheet: ftp://www.raisonance.com/pub/forum/STR9 … -02_07.pdf
(see extract below). Most of the time, it happens when you are trying to write the clock configuration part of your project. Unlike what the errata sheet says, RLink does NOT allow you to tie reset low by a software manipulation.
Here are the steps to take to erase the part with RLink when you have this problem:
- Power the board and start RFlasher.
- Press the Reset button and keep it down for the following steps.
- Unpower the STR9, but not the RLink (using the jumpers in the POWER section of the motherboard if you are working with REva).
- Wait a second or two. Power the STR9 again.
- Launch the Erase command in RFlasher.
- Wait for a few seconds and then release Reset.
- Wait for the Erase to complete. It should succeed.
- Now you can use your board like when it was new.
- Check your code against the errata sheet to make sure that the problem does not occur again: you should just insert some NOPs or a short loop after changing the clock source from PLL to another.
Here is the extract from the errata sheet:
ST (in ErrataSheet-02_07) wrote:
2.14 Clock control unit clock switching
Description of limitation in Rev B and Rev D
When switching the main clock (fMSTR) from PLL clock source to OSC clock source, NOP
instructions must be inserted after the OSC is selected and before the disabling of the PLL.
Without the NOPs, the CPU will lose its clock and a warm, external reset will not re-boot the
processor. The number of NOPs needed depends on the PLL frequency. The total NOP
execution time must be greater than 10 OSC clock periods (one PLL clock is needed to
execute one NOP).
Workaround using Rev B and Rev D
1. To prevent the CPU from losing its clock, do not disable the PLL while it is the selected
main clock source.
2. When configuring the PLL for a different frequency, it is recommended to:
a) Select the OSC as clock source
b) After inserting the required number of NOPs, disable the PLL
c) Enter new P, M and N values in the SCU-PLL Configuration register
d) Enable PLL
e) Select PLL as clock source
3. If you have programmed the device with the incorrect clock switching codes and the
processor has no clock source to run on, you can still reprogram the Flash with a JTAG tool.
The JTAG tool will directly control the board reset line to program the device. The
programming steps are:
a) Run JTAG programming application software
b) Go to "Program Device"
c) Power-off the board
d) Click "Assert Reset" button in JTAG software tool
e) Power-on the board
f) Perform any programming operation
g) When done, click "De-Assert Reset" button
This will be fixed in the next revision of silicon.
^top
