Forum : ST7/STM8
| Post Information | Post |
|---|---|
|
March 18, 2011 - 9:18pm
|
I have occaisional trouble erasing flash with the RLink. On troublesome boards it may take 20 or more attempts before it reports success. The other steps (program, verify, blank check, read die ID) all seem to work without this issue. Is this a known issue or what should I be checking? Is there an example circuit of what should be attached (if anything) to the pins used by the RLink? I suspect there may be something on the target board causing the issue. I also had a program error on one board - "Unable to write option bytes". Multiple erase and retries were unsuccessful. I programmed the same file into other boards without problem. The flash verified ok even though the program step failed but I did not use the board because I suspected there may still be an issue. Again, what should I be checking. |
Hi,
There was no such problem reported for now.
Please first check that you are using the latest version of the software.
You need to update both the Ride7 and the RKit-STM8 from our website:
http://www.mcu-raisonance.com/stm8-download.html
Then you should check the connections...
Make sure your board makes the connections for all four required signals: GND, VCC, RST, SWIM_DATA.
Make sure no other component (reset circuitry, etc.) prevents the RLink from driving the lines when it needs to.
Make sure you have only one power supply: if your target board has a power supply, you must unplug the PW5V jumper from the RLink ADP.
If your board has no power supply and you power it from the RLink (with jumper PW5V set), make sure all components of the board are 5V-tolerant.
If your VCC is lower than 3V3, plug the ADAPT jumper on the RLink SWIM ADP. The resulting pullup (including the internal RLink and STM8 pullups) should be between 500 and 1K.
Finally, if all these fail, I would check the power of the board itself. The Erase procedure (and erasing Option Bytes for removing protection) is one of the operations during which the CPU draws the more power. If your power supply is around its limit, then it might explain your problem.
I hopt it helps.
Best Regards,
Vincent
Hi,
Here are more hints following the additional information that you sent by email:
For SWIM/STM8 you MUST plug the SWIM jumper on the ADP. Plugging only the PW5V jumper cannot work reliably.
Moreover, cables longer than 20cm are not validated. Using longer cables could very possibly explain your problems.
Best Regards,
Vincent
Thank you for the suggestions - everything but a slightly long cable seems ok.
The target is 5V and I am only powering it from the RLink during erase/programming. I can check the voltage during programming.
The reset line is as shown on the device data sheet. A 0.1 uF capacitor to ground. It also has a 100k pullup but that is high enough I don't think it should matter. The SWIM line is only connected to the programming connector.
I have the 5V and SWIM jumpers installed and no others.
The cable length is about 25 cm. I will try shortening this.
Hi,
Yes please try shortening the cable to see if it makes a difference.
Is this problem related to the board, or does it disappear on a given board after you have managed to Erase once?
If it is related to the board, I might a few other ideas...
Can you provide an estimation of the number of boards that show the problem?
You could first try to remove the capacitor on RST on one of the boards that show the highest probability of failure.
Just to see if that makes a difference.
You can also check that the internal RC of the STM8 has been correctly calibrated: The SWIM protocol and Flash programming algorithms require that this clock is calibrated in factory by ST to a specified tolerance. It happened one time in the past that a customer received uncalibrated devices, and that resulted in about 5% of his boards showing connection errors. (not during Erase, but it wasn't the same STM8 as you, so the same source problem might result in different symptoms)
Did you get the STM8 devices using the standard distribution process, or are they special?
prototypes? discounts? restocked? stolen? (just joking ;) )
The other customer's devices were prototypes...
To check the calibration, you must use a simple toggle application that DOES NOT reconfigure the CPU clock and keeps on using the internal RC. Use the Ride example for that, remove the clock config if needed, change the output pin if needed, recompile, make it run on a few boards that work, measure the frequency with a scope. You should observe a variation of the frequency of the toggling not greater than 10%. Then make it run on a few boards that fail and see if the frequency of the toggling varies more than 10% compared with the boards that Erase without issue.
This is how we found the problem with the other customer's devices.
Best Regards,
Vincent
The issue does not seem to be consistent. I don't have much information on recurrance of the problem on the same board but I will be getting more of that info. For a unit that had option bytes error while programming multiple times (until I gave up) I then went back to it several days later with the same equipment (no change in cable length or anything else that I know of). The unit programmed without error on the first try! I tried several erase/program cycles with no problem.