Forum : ST7/STM8
| Post Information | Post |
|---|---|
|
October 9, 2017 - 2:28pm
|
We are experiencing a failure of Rlink programing of STM8L targets which the Ride7/RFlasher software does not report. Development was via a standalone laptop using Ride7 enterprise for STM8 and Rlink programming hardware. Once complete and tested 3 additional Rlinks were purchased and a dedicated programming laptop was loaded with Ride7/RFlasher. A programming project using the Ride7 programming computer was made using the Hex file from the development computer. The production systems were programmed with the programming laptop; targets were erased, blank checked, programmed, and verified without ANY errors. However the units failed operation. When taken back to the development computer and reprogrammed the units worked correctly. The procedure to successfully program units on the development computer is a follows: Debug-Start, {which erases, programs and verifies}, the debugger must be started and then paused to program the unit correctly. === Starting the debugger is the key===. If the target is just programmed and then placed into service without starting the debugger it will fail. There is something that the Ride7 development software does to the STM8 hardware that allows it to operate correctly, which a standalone production programmer does not do. Remember this is all taking place in an environment where the production programmer does not report a single programming error. We have swopped Rlinks and the problems stay with the Ride7/RFlasher software. |
Hello,
Did you try to program and run the flash using the development PC using the same procedure (software version, power supply, RLink connection, connections order, POR, command-line or RFlasher project, etc.) that you use on the production PC ?
After successfully debugging on the development PC, does the application run properly if you turn its power OFF and ON?
There are indeed a few things that the debugger does and which could make an application "fall in work" (= "fail to fail" ;/ ) when debugging.
The most likely issue that I think of is related to the unlocking of nvm write: the debugger unlocks the nvm (flash or eeprom) writing because it needs it for placing and removing breakpoints. One side-effect of this is that if an application relies on writing in the nvm for operating (usually storing data, for calibration or for other purposes), but "forgets" to unlock it, then it might work when debugging but not when simply programming and executing. Does your application modify the nvm? (flash or eeprom) Does it do it periodically during its normal operation or just one time at the first execution? (typically, calibration)
There are a few other possible explanations, but please clarify this usual suspect first.
If this does not allow you to solve the problem, we will need more details on your situation. please send us the answers to this form:
http://support.raisonance.com/node/430017
Best Regards,
Vincent
Once we determined the problem, we tried using identical procedures and hardware at both development and production with no change in result.
Once the target is programmed with the development PC, power can be cycled and the unit continues to work properly.
We have a number of products based on the same STM8L microcontroller and all have been developed using Raid7 and STM8 from Raisonance. All except this one program perfectly using the production PC. There are number of things that make this one different. We program the option bytes for a different brownout-reset value and enable the watch dog timer. We also preload 8 EEPROM locations with default values. We initially thought that these two areas might be the issues, but using the read command (after programming and verifing), and we can see that everything seems to be set correctly. We also use a dedicated programming fixture with pogo pins to make the swim contacts, but using that fixture with the development PC works correctly. I will send the answers to the rlink questions via email later today.