Topic : STR912FAW46. Write errors.

Forum : ARM

Original Post
Post Information Post
May 11, 2009 - 8:08pm
Guest

We have STR912FAW46 processors we are trying to use RFlasher7 on. We were unsuccessful using the latest tools (7.16) and the version which was shipped with us (7.02).

I am able to configure the device for Bank 1 booting, set the high bank to address 0x0020 0000, and erase both banks. However, I am unable to write my Ihex files to the device without getting write errors. I tried re-writing and re-erasing the config registers, before and after programming and still have the same pop-up: "OPI Driver Error: Error reported by the device"

What am I doing wrong?

Replies
Post Information Post
+1
0
-1
May 12, 2009 - 10:07am
Raisonance Support Team

Hi,

There are two kinds of errors that could lead to this problem...

The first kind is a mixup in addresses: Ride interprets hex files as an image of the memory as the CPU will see it. That means, in your case, that the hex file must contain the data for bank1 at address 0 and the data for bank0 at address 0x2000000. So you have to configure you linker for generating hex files like this. Also, for programming the flash from multiple hex files, you must use the project mode in RFlasher. If you are using obj files generated by CAPS it's much simpler, as this format gives directly the data for each bank. Maybe you should consider using CAPS to merge your hex files into an obj file with all the data and check the correct addresses. Another option, if you have debugged your program already, is to run a debug session, which will program the Flash, then use STR9_pgm to read the whole Flash out to a single obj file. Then you can use this obj file for mass programming.

The second kind of errors that can lead to "error reported by device" is hardware. It could be that the power is not strong or stable enough. Flash erasing/programming is one of the operations during which the STR9 uses more power than usual, so they can fail on a board on which other operations (connect, dump, ...) work fine. It could also be related to unstable clock, or even to wrong connections. (are RST and TRST both connected from the RLink to the STR9? have you checked that they are NOT connected to each other?)

That's all I can say with the information I have. To help you more, I would need the answers to this form:
http://raisonance-forum.xsalto.com/viewtopic.php?id=2231

I need at least the version of the Ride and ARM kits, the serial number of the RLink, the hex or obj file(s), and the schematic of the board. Please also note that version 7.16 is not the latest. there is a version 7.18 of the Ride kit, and in fact the version of the ARM kit is more important for your questions.

Best Regards,

Vincent

+1
0
-1
May 12, 2009 - 8:35pm
Guest

Latebreaking:

I was able to program my boards successfully when I held them in reset while writing to flash. I think we may have issues with our JTAG part of our target boards but the reset hold is an acceptable solution at this time.

Thanks for your sugestions, though, and I will double-check the hardware. We might not have the JTAG resets connected correctly, or may have too much pull-up/pull-down current or something.

From,

sgroves_tyco

+1
0
-1
May 13, 2009 - 9:38am
Raisonance Support Team

Hi,

I'm glad to hear that you can use the RLink now.

I think your interpretation is correct, that the RST signal is not connected from RLink to the STR9, or that some third component (could be a strong pull-up, a reset manager, ...) prevents the RLink from pulling the RST signal low.

Best Regards,

Vincent