Hi Oppie & cvs_rv,

If you read the threads I started:
"New STR7_pgm.exe and RFlasher options" (concerning updated STR7_pgm & R-Link programming problems), and
"STR7 and RFlasher error "Wrong boot mode detected" (concerning Erase and Programming problems),

you'll soon see that you're not alone with these problems - I am also following in the footsteps of older threads to my own. I am using the STR712, but I feel these points are still valid for the STR710.

My current understanding of the "I can only erase one sector at a time" issue is that the program you are programming into the ARM (the Bootloader or Main Application) is enabling the watchdog timer as one of it's first job - right? This is important as the R-Link tool takes a little while from reseting the ARM before it takes control of it and stops the programmed code from being run. Naturally if the watchdog timer is enabled, it will reset the ARM sometime in the future - which I believe is in the middle of the failing erase operation.

My reasoning is that if you try to erase a single 8K sector, it is always successful - as the watchdog timer does not have enough time to reset (we set the watchdog timer to the maximum interval - which I think is about 2 seconds if I remember correctly). However, if you try to erase a 64K sector, and then read it back with RFlasher, you can sometimes see that most of the bits have been reset (to 1) but there are still some bits that are 0 - as if the operation was interrupted. I believe this indicates that this issue is definately time related.

To prove this I asked Raisonance (via Vincent) to add an extra bit to the erase and programming operation to firstly clock in (to the ARM core) a "Disable watchdog timer" operation and so stop any possible future resets. However, he is unhappy to perform this change without me proving my theories 100% - which I have not had the time to do yet...

It could be proven by simply removing the enable watchdog timer from the code (as a temporary measure) - or, creating a long enough delay at the beginning of your program (in which the R-Link will take control of the ARM core) before the watchdog timer is enabled. Unfortunately Vincent was unable to tell me (or give a ball-park figure) of how long this delay would have to be - however, as our bootloader has to be transferred from Flash to RAM before it is run, the required time is definately in the milliseconds.

If it can be proven, and Raisonance add this 'Disable watchdog timer' operation, there will be one hell of a cheer!

Hope this helps,
Andy Campbell

Hi Andy,

Thank you for your work on this. Will check with our programming people on the watchdog issue to see how this figures into the problem (I'm the hardware guy). Without getting into the low level details, it seems pretty strange to take control of a device by way of the JTAG... and not really take control by allowing the watchdog (and who knows what else) funtions to keep running.

Will report back when I get some answers but at present, the Segger J-Link/ J-flash bundle ($650 usd) is looking like a more reasonable route. IAR provides the J-Link as part of their Embedded Workbench tools. HiTex on the other hand, is outrageous at $3395 for their MemTool-UAD2.

Regards,
Bob Oppenheimer
aka 'Oppie'

Confirmed with our programming folks, we do NOT use the watchdog timer at present. It is by default disabled and for us should not be a problem. Still will not erase anything but the first sector.

For that matter, I filled the memory buffer for flash (B0F0 - B0F7) with 0x55, set only sector B0S0 check box and programmed it. Sector had previously been erased. Got lots of errors at addresses way above the sector I thought I was programming. There is something major that appears to be wrong. Did I miss someting here?

When reading memory, the confirmation pops up as an independant window and not as part of the window in use. Makes it confusing trying to figure why it is not accepting a new command - because the confirmation dialog is under the rflasher window. happens when doing something useful while the memory is off reading.

Hi Oppie,

Thank you for the feedback... however puzzling it makes this matter! :D My theory now has a large hole in it... thanks alot! ;) I guess this issue is more fundamental than first thought - hopefully Vincent is reading this thread and can give his opinion on this new information... Vincent?

Please say how it goes with the Segger bundle - I'm sure I'm not the only one reading these threads that's interested in your findings on that (if you go for it) - if it gets shown...

Best Regards,
Andy Campbell

Hi @all,

if you have problems with erase, blank check, programming and verify you should check the Jumper placed on the Rlink2.
For further information look at the RFLASHER program. Select your Device. In the group "Programmer-specific options" you should find a subgroup "Test Connect". Click on the button "View REva jumpers". The descrition for this button is a little bit confusing. A window "RLink jumpers for JTAG" opens and show you how to set the jumpers of the RLink2 to program the JTAG.

Best Regards,
maheni