Forum : ARM
| Post Information | Post |
|---|---|
|
July 5, 2007 - 4:51pm
|
Hi Vincent (and others), We are using the R-Link and the STR7_pgm.exe to program our STR712's. Our program calls the STR7_pgm.exe with a command line via a batch file. This works pretty flawlessly on the whole. However, we have come across a problem that we need your expert help with: Using the STR7_pgm.exe that comes with the BN746 there is no (visible) option to cause a "Reset and Run" operation - that is necessary if you have just used the R-Link to program in a bootloader and you now need to run it. Running the STR7_pgm.exe in a CMD window, it lists all the available options and there doen't appear to be any way to generate a CPU reset. Using the new STR7_pgm.exe that I downloaded from this forum (from the 'Problem flashing Bank 1' thread) has a new option to "Launch" the CPU - which works great and is exactly what we need. However (you knew there was a but coming), this new STR7_pgm.exe version also seems to have another new feature for "Sectors Protection" (when viewed in RFlasher), but this new option is not visable when using a CMD window to see the options list. The problem with this "Sectors Protection" feature is that I have no information on how to use it in a command line, and it appears that if you do not put anything for it in the command line, the default is to enable protection on all sectors! This has the unfortunate problem of stopping my bootloader from being able to do it's job - so production is at a standstill. So, there are two solutions to this: 1. Using the standard STR7_pgm.exe that came with BN746, all I need is the ability to cause a CPU reset - which I know RFlasfer can do. Is it possible to tell me how RFlasher does this operation so I can request it from the R-Link in my own program? 2. Please give me information on how to control the "Sectors Protection" option in the new STR7_pgm.exe so I can make sure there are no sectors protected and allow my bootloader to work. RFlasher suggests that you can enable / disable each sector just like the Sector Mask option, but what is the letter I need to put before the mask value? I would be really, immeasurably releaved if you can help me with a solution today or tomorrow. Best Regards, |
Hi,
We are in the process of issuing a new patch. Hopefully, it will be available tomorrow or Monday. I'll try to include the protection in STR7_pgm with this release.
Best Regards,
Vincent
Hi Vincent,
Thank you (again) for your very quick reply.
Sorry to be a pain, but does your reply mean that there is currently no way to modify the "Sectors Protection" option using the new STR7_pgm (and that it is indeed defaulting to "All protected")? I only say this because the options available in RFlasher do suggest that it is possible to do so?
I don't really need the protection option at all - I just need it to leave the Flash unprotected! :D.
Or alternatively, I need to know how to cause a "Reset and Run" operation with the older STR7_pgm (just like RFlasher does).
I would be very happy either way.
Best Regards,
Andy Campbell
Hi,
No, there is no way to do what you want to do with what you have now. Sorry.
Please give a try at these files:
ftp://www.raisonance.com/temp/ST/STR7_pgm_test_070705_noprotect.zip
This version of STR7_pgm should not protect anything unless you use option 'W'. (see on-line help for more info, as usual)
Best Regards,
Vincent
Hi Vincent,
You're a legend! Thank you for the very quick response.
The new STR7_pgm is working very well (although after about 8 reprograms of an ARM IC it did enable the protection - at least the symtoms are the same as before when the protection was on).
I'll give you more feedback when I've gotten to the bottom of all this.
Best Regards
Andy Campbell
Hi Vincent,
I am afraid to say that I was premature in saying you were a legend ( :D ) - as the new STR7_pgm suffers from almost the same problem as the previous version:
Using the new STR7_pgm - it can become impossible to erase or program sector B0S5 (and probably B0S4 as well - but my bootloader stops after failing to program B0S5 so I cannot say for sure) after a random number of cycles (erase and program). For example, the best one went for 6-8 cycles before becoming unuseable, where as the last two chips went bad on only their second cycle...
Using the previous (Launch capable) STR7_pgm - it would 'enable protection' almost always immediately on the first cycle. So you certainly changed it for the better, just not totally right.
Using the 'old' STR7_pgm that came with BN746 - there are no problems with flash sectors becoming 'protected'. I have just finished proving this fact - so I did not send you on a wild goose chase - I have managed to reprogram an ARM 712 chip 24 times without any problems. That's at least 4 times longer than any chip last under the new STR7_pgm. Unfortunately I have to manually reset the chips as there is no launch command with this one...
So I am afraid to say that the problem has not gone away.
Do I guess right that you would rather avoid adding the launch command to the version of STR7_pgm that came with BN746? As this would solve the issue...
I guess you would rather fix the current one instead - please ask what you require of me to help fix this problem.
Furthermore, I now have 6 ARM chips that I cannot use - as the bootloader cannot reprogram the Main Application... will a new version of STR7_pgm allow these chips to be 'repaired'? Or should I change my bootloader to try and disable the sector protections?
Best Regards,
Andy Campbell
Hi Vincent,
I can appreciate you are busy, but do you have an idea of when you can get back to me concerning my STR7_pgm problems?
Thanks for all your help to date.
Andy Campbell
Hi,
Sorry, I was out of office yesterday, and I have a lot of (other) urgent things to do today. And from your description of the problem, I think it won't be easy to solve.
Can you send me an application or project that will allow me to reproduce your problem. All the tests I've done here seem fine.
Also, what do you mean by "becoming unusable"? Does it mean that the part does not respond to JTAG anymore? Can you still read the IdCode? Or is it just the erase/program operations that fail? Have you tried to erase using RFlasher? That should remove all the protections. That should at least allow to "repair" your 6 chips. Does it manage to do it? If it does not manage to do it, then the problem is deeper than I thought...
I don"t expect to solve this issue quickly. Not as quickly as the others anyways. :) Here is a procedure I can suggest for you in the meantime: you should be able to have the two versions of the exe (and associated DLLs) in two different folders. Then, you can try to use the old one for programming and the new one for starting the exec. As you said, I will not make a branch on the old one for adding the launch to it.
Best Regards,
Vincent
Hi,
I cannot make a branch on the old version, but I have an old internal exe that will only reset the ARM:
ftp://www.raisonance.com/temp/ST/RLink_ARM_reset_070711.zip
Restore your old STR7_pgm.exe and its DLLs so that you can program without protection problems but not reset.
Then, take the two files from the zip and place them with the rest in c:\ride\bin. (overwrite monitortools.dll, the other file is new)
Then, you can call "RLink_ARM_reset.exe" to make RLink reset the device.
That should allow you to go on with your work.
I still need the answers to the questions in my previous post for understanding and solving the problem in STR7_pgm.
Best Regards,
Vincent
Hi Vincent,
I can appreciate you're a very busy man. Thank you - that sounds like a great workaround - I'll try it tomorrow and say how it goes.
As for me saying "becoming unusable" - I mean that the bootloader flashed in to the ARM using R-link and the STR7_pgm cannot erase and/or program the Main Application sectors (B0S4 and B0S5).
The erase operations (performed by our bootloader) are returning without an error being detected - but its obvious they have failed because they normally take a few seconds to perform, but when the protections are enable, they are almost instanteous.
The program, followed by verify operations (performed by our bootloader) fail immediately - either because of the previous failure of the erase operation or directly because the flashed/written data is not the same as that read back (verified).
This makes the bootloader useless because it can no longer do its intended job of updating the Main Application. The erase and write operations use the standard library functions, so I don't believe that is the issue.
Using the R-Link and RFlasher it is completely possible to erase and program Flash sectors - including the problem sectors B0S4 and B0S5. The J-Tag connection is still fine - the IdCode is still readable. How does doing an erase with RFlasher remove the protections? The Flash registers are not viewable using RFlasher - are they? That would be a very useful feature.
The Erase operation is only possible if you do it one sector at a time - or, as I found out a few days ago - if you first erase the first bootloader sector (so the bootloader Watchdog enable code is removed and so cannot be run), then you can erase all sectors in one go successfully. Which really puts weight behind my watchdog idea... :D).
However, once you ask the bootloader (transferred to RAM at startup) to do the erase/reprogram operation, there is no change - it still fails - even when I used RFlasher to put both the bootloader and Main Application in the Flash...
I've tried setting the 'Sector Protection' bits on and then off (via RFlasher), but there is no change in the bootloader. Out of interest, when are these bits programmed into the ARM - is it only during a program operation?
We have now successfully programmed over 250 ARM chips using the 'old' STR7_pgm without any problems so it must be down to the changes between the two (sorry I cannot help any more :) ). I have not used the new versions since.
Best Regards,
Andy Campbell
Hi Vincent,
A little more information to hopefully help get to the bottom of this:
If I use the original STR7_pgm (from BN746) with the ARM chips that have been wrongly protected using the new STR7_pgm, I cannot erase or program the flash sectors! This can be proven using RFlasher - it is also unable to perform erase and program operations on a protected ARM chip (using the original STR7_pgm installed).
As I mentioned before, using the new STR7_pgm on these ARM chips I can perform erase and program operations as normal - so this has to be down to the protections - doesn't it? The new STR7_pgm is obviously temporarily turning off the protection to perform its requested operations, but the original STR7_pgm does not know anything of these protection settings and so cannot peform the requested action.
I hope this information is of help.
Best Regards,
Andy Campbell
Hi,
Thank you for all this feedback. I called ST about this, and with all the information from you, I now have a good understanding of the situation...
The protection, once enabled for a sector, can only be removed temporarily, until the next reset. We had not understood the doc this way until now. This means that unless your bootloader application disables the protection, you will not be able to use your 6 protected chips anymore. In fact, this is what ST says: an application that needs to modify the flash should disable the protection first.
As you understood, the old STR7_pgm does not handle protection at all. So it will not be able to modify a protected sector. The new STR7_pgm does disable the protection when it needs to modify a sector, so it will manage to erase and program these chips. Now I must understand why it does sometimes enable protection when it is not asked to. But this might take some time...
I suggest you either modify your bootloader for handling protected chips, or use the workaround with RLink_ARM_reset in my previous post. I cannot commit on a date for the correction of the problem above.
Best Regards,
Vincent
Hi Andy,
We do not manage to reproduce your problem. We tried to program about 20 times with the new STR7_pgm but the part is still not protected. Please give me the exact command-line you are using when calling STR7_pgm. Please also give me the last address containing some data in your hex file. (or send the hex file to "support@raisonance.com", saying it's for Vincent)
Thanks in advance.
Best Regards,
Vincent
Hi Vincent,
Finally got some time to reply:
I only used your RLink_ARM_reset program briefly, but it seemed ok. I quickly moved on to changing our bootloader to disable the sector protections (regardless of whether they are enabled or not), and that has worked perfectly - I've only tried it on 2 of the 6 ARM chips, but they are now useable again. I cannot find anywhere that ST specifies this requirement (to always disable protection) - can you point me to it? or is this a new requirement of theirs?
However, this does prove that it was the sector protection being put on by the R-Link / STMR7_pgm that was the root of the issue. Sad to hear that you cannot duplicate the issue at your end... we have the same problem with our products sometimes - it's finding that one difference between your setup and the customers that can be elusive!
To this end I have answered your questions:
The command lines we use (inside a .bat file) are:
1. To perform a Blank check to begin with
c:
cd "C:\Program Files\RIDE\BIN\"
STR7_pgm.exe TSTR712FR1 S1023 W0x00 F4000 B >CommandLine.txt
2. To perform Erase of sector B0S0 (because we are still forced to erase each sector seperately)
c:
cd "C:\Program Files\RIDE\BIN\"
STR7_pgm.exe TSTR712FR1 S1 W0x00 F4000 E >CommandLine.txt
3. To perform Erase of sector B0S1 (this completes the erase of the Bootloader. Bootloader used to erase Main Application sectors - as this is much quicker (3 seconds vs. 50 seconds)).
c:
cd "C:\Program Files\RIDE\BIN\"
STR7_pgm.exe TSTR712FR1 S2 W0x00 F4000 L >CommandLine.txt
4. Program of Bootloader program hex file
c:
cd "C:\Program Files\RIDE\BIN\"
STR7_pgm.exe TSTR712FR1 S7 W0x00 F4000 P"w:\Projects\ARL\Programmer\Uni-Prog\Software\v1_11\Temp.hex" >CommandLine.txt
5. Perform a reset of ARM after programming Bootloader to start Bootloader running.
c:
cd "C:\Program Files\RIDE\BIN\"
STR7_pgm.exe TSTR712FR1 S7 W0x00 F4000 L >CommandLine.txt
I hope the extra parts ("S7 W0x00") in the Launch command line above will not be a problem - the line is generated from a standard function that adds the required operation (and file name if appropriate) part to it. Obviously it can be changed if required.
I originally did not include the "W0x00" part, but after an ARM chip became protected, I added it to be on the safe side - and I thought that had fixed it for a while, until about 5-6 reprograms later when the protection became active in the new one too. :|
RIDE is installed into the "Program Files" directory - would this have a bearing on things?
The hex file (of the bootloader) uses the addresses 0x40000000 to 0x40003FFF (Sectors B0S0 and B0S1). The Hex file does appear to be programmed fine with STR7_pgm. It's only when the bootloader tries to access the top of B0S5 (0x4001FFF0) that a problem is detected by the bootloader - as the verify operation fails.
I hope this helps... :)
Best Regards,
Andy Campbell