OK Vincent,

Here we go with the very long list of questions (:D):

0.1. What is your Customer Serial Number, if you have one? No Serial Number

0.2. What is the Build Number of your RIDE? The version using at the moment (from first STX-RLINK) is "BN743-ST7-ARM-80C51". The second version (from the second STX-RLINK purchased last week) is "BN746-ST7-ARM-80C51-P1-P2" - I have not used this version yet - will do after I send this reply.

0.3. What kind(s) of RLink(s) do you have? 2x RLink-STX

1.1. Does the PWR LED turn ON when you connect RLink to the PC? YES

1.2. Is the USB driver correctly installed? YES

1.2.1. Does the BUSY LED turn ON and then OFF when you connect RLink to the PC? YES

1.2.2. Does RLink appear under the Jungo section in Windows device manager when it is plugged? YES

1.2.3. What is your host system? Pentium III 1.7Ghz CPU, Windows XP SP2

1.2.4. Can you read the RLink Serial Number? First (and in use) RLink SN: dngStd004000352. Second (new) RLink SN: dng003002586
1.3. What is your RLink(s) Serial Number? Sorry, don't understand the difference you are making here.

2.1. What is your target CPUs? STR712FR1

2.2. What is your target board(s)? Our own PCB

2.2.1. Please send us the schematic of the board. Cannot do that

2.2.2. If it is a commercial board, what is its manufacturer and exact reference? Our own

2.2.3. What is the configuration of the jumpers and switches on the board, if any? N/A

2.2.4. How do you power the board? From 12v PSU

2.2.5. If we need to get the real board for testing, under what conditions would it be possible? Sign an NDA - yes, but should not be necessary as this has to be a general issue.

3.1. Please describe the problem you are experiencing as precisely as you can... Hopefully already done that in first post.

3.1.1. What software are you using? RFlasher and the STR7_pgm exe directly

3.1.2. What is the simplest sequence of operation that we can perform in order to trigger the problem? Have a program that remaps the FLASH to the RAM during its standard ST ARM initialisation code "71x_init.s".

3.1.3. How does the problem manifest itself? Hopefully alrady covered this

3.2. Do you have any comment or personnal interpretation of the problem? No that I didn't put in my first post

3.3. Please make a few tests... Already done with RFlasher and STR7_pgm - both cannot erase. However, the IAR J-Link can erase the FLASH (when enterying debug) - and is the only way I can currently erase our programmed ARMs...

I hope this help Vincent!

Best Regards
Andy Campbell

Hi Vincent,

OK, I have now used the new RIDE/RFlasher from the R-Link we purchased last week (BN746-ST7-ARM-80C51-P1-P2). The "Wrong boot mode detected" error has stopped! I was excited for a few seconds.

However, before you shout horray, I now have the same problem as at least two other users of this forum - "cvs_rv" (posted 11th May 2007) and "jkim74" (posted 25th April 2007) and there may be more users out there with this issue:

[Unfortunately, neither thread was replied to - I really hope there is an answer to this problem...]

The erase and program operations seem to complete successfully (RFlasher reports that the operation completed OK), but when you check to see if that's true you find nothing has changed in the Flash.

The Erase operation does not erase, and the Program operation does not program. After a successful full chip erase operation, the Blank check fails... Trying to program a section of the Flash (even one that is read as all FF's) does not succeed at all - not even one byte is changed - although RFlasher reports that it completes successfully.

However, in complete contrast, the Flash Read operation does exactly what it says! Crazy hey!?

Please help us Vincent - we really need the R-link to work!

Best Regards,
Andy Campbell

Hi,

First, thank you for taking the time to answer the questions. Now we have a good understanding of your situation.
Your second RLink's SN is not correct. Either you didn't copy it correctly, or it is defective. Please read it again and confirm.
I'm not surprised that you had problems with BN743. It's a quite old version.

I have installed BN746-ST7-ARM-80C51-P1-P2, and then modified the test example for it to remap the RAM at address 0.

Then, I get an error when I try to debug, (I'll correct it ASAP) but the programmation functions (erase, blank-check, program, run) work fine in RFlasher, unlike what you experience...

Did you uninstall your BN743 before you installed your BN746?
If not, please uninstall RIDE, remove (or rename) the RIDE directory, and then install it again.

If yes, then probably we need more than just "remapping the RAM at 0" to trigger the problem. We'll need you to send us a project that shows the problem, and hope that there is no link with the board, only the program. Either you can make a non-confidential project that shows the problem, or we'll have to arrange for us to sign a NDA so that you can send us your project. Please contact us at "support@raisonance.com".

Note that you can send us a IAR project (or ARM or Keil) if it's easier for you. This makes no difference for us. However, we'd prefer a small project running on a commercial demo board (from Raisonance or ST is even better) if it's possible. The less differences there are between our tests and yours, the more likely we'll manage to reproduce (and solve) your problem. And using different boards is a big difference... :)

I'll make a few other tests, but there are so many possible causes for the problem that I don't have much hope of falling on it without an example from you.

Best Regards,

Vincent

Hi Vincent,

I have been working out how to 'workaround' this problem and I will get back to you with the details once the products are completed and the pressure is off. Just thought I'd better say I hadn't disappeared on you!

Best Regards,
Andy Campbell

Hi Vincent,

First thing: we need to simplify the situation to help us find a solution.

As moving from BN743 to BN746 removed the "Wrong boot mode detected: RAM mode. Expected FLASH mode" problem perhaps we need to move on to a different thread?

For the moment, we are now left with an annoying issue that the R-Link will not erase the ARM712's sectors correctly. To keep this simple, I am sure this has nothing to do with any firmware inside the ARM712, and I am as sure as I can be that it probably has nothing to do with the hardware the ARM712 is mounted to.

Can you please confirm or deny that when the R-Link and RFlasher (or STR7_pgm.exe) are used to erase the ARM712, the contents of the Flash are not relevant to this operation?

As far as the hardware surrounding the ARM712 is concerned, it is identical to the hardware found on the IAR kickstart PCB - there isn't really that much different you can do - is there?

If we look at this as a purely erasing operation problem, can the firmware project really affect this operation?

When using the R-Link with RFlasher (or STR7_pgm.exe) to perform an erase operation, only the first sector is erased correctly, the second sector can be filled with 0's instead of F's sometimes! Therefore, the workaround I have used (along with a few other users it seems from looking at other threads) is to perform a seperate erase operation for each sector. This does on the whole work - although it obviously takes far longer to perform!

I must also add that sometimes B0S4 and B0S5 are not erased completely (even when erasing just that one sector). When the sector is read back after the erase operation, you can see that most of the Flash bits are 1's but anywhere between 5-10% of the bits are still 0's - giving a very odd looking memory. I think other user have mentioned this.

To hopefully help discount some of the hardware factors, I can also say that once the R-Link has been used to put our Bootloader into B0S0 and B0S1, it can erase the two Main Application sectors B0S4 and B0S5 within 2 seconds and always performs a total flash erase - so this should prove that the hardware can be erase correctly.

I hope this helps

Best Regards
Andy Campbell

--------------------------------------------------------------------------------------------------------------------------------------------------
To answer your questions in your last positing:
Our new RLink is definately reported by RFlasher as "SN: dng003002586" - I have tried it many times now and it is always the same number. It is performing exactly the same as the other RLink, so I don't think it is faulty (apart from it's erasing issues ;)... sorry)

I did uninstall BN743 and then install BN746 to a different directory - but I have a query about the install - it defaulted to using the directory "C:\Program Files\RIDE\" but when you clicked 'next' it complained that the directory did not follow the 8.3 file/directory format. I then navigated to the "C:\Program Files\RIDE\" directory manually (which was empty) and the installer was then happy.

Is the R-Link / RFlasher / RIDE code happy to be in "C:\Program Files\RIDE"? or will this cause problems? To answer this question, I have installed it to "C:\Programs\RIDE" on another PC, but I have not had the time to test this install out yet.

Thank you again for your time!

Hi Vincent,

I have just been reading threads further afield than the ARM71x, and found the thread by "AlexMueller" that had a problem erasing the Flash when using the ARM75x. He found that it was the watchdog being turned on by his Bootloader that was at fault in causing the erase operation to fail.

This makes perfect sense to me also - if the J-Tag interface cannot stop the ARM from executing a few instructions before it is halted (as Alex summises), then the watchdog can get enabled before the ARM halts and subsequently cause the erase operation to end prematurely due to a watchdog reset. This could also explain why the small 8 Kbyte sectors are always erased, but the large 64 kbyte sectors are sometimes left 'partially' erased (as they take longer than the watchdog timeout).

If this is indeed the answer to all this madness then there are two real solutions as far as I see:

1. If the number of instructions or time before the J-Tag can halt the ARM is predictable (or at least a maximum time is), then we could all place a small wait loop at the beginning of our Bootloaders before the watchdog timer becomes enabled.

2. The J-Tag interface is used to clock in instructions to the ARM core - so why not send it a disable watchdog timer instruction before you begin the erase operation?

"AlexMueller" had another idea about using a special value in the RAM - which whilst great is more work than either of these ideas.

Please say whether either of these ideas would work.

Thank you Vincent!

Best Regards,
Andy Campbell