Hi,

I just saw that you get the same error if the file does not contain valid hex records, or if it does not contain data for the Flash address range. Maybe you compiled using RAM mode?

I'll make the error messages clearer in the next version...

Best Regards,

Vincent

Hi,

I have corrected a few errors in "STR7_pgm.exe". Two of them might be related to your problem. I will include the corrections in the next version of RIDE, but in the meantime, you can download the fix there:
ftp://www.raisonance.com/temp/ST/STR7_pgm_fix_070123.zip

Just download, unzip, and read "ReadMe.txt".

Best Regards,

Vincent

Thanks Vincent!

The fixed version seems to work as expected, and the new error messages helps a lot. Super work! I had the wrong address range in my hex file, so offsetting it with 0x40000000 should do the trick (when i open the hex file I can also see that all data records start at 0x0000 and no other extended address records exist other than offsetting with 0x0000, not helping at all).

I'll report back how it went (I can't test it now since I'm temporarily out of time :-).

Btw, the serial number of my RLink is dngStd003002851, RIDE build is BN746-ST7-ARM-80C51 and Windows is XP Pro.

Cheers,
Steen

Hi Vincent.

This version does not seem to program the very last byte from my hex-file. The last four lines in my hex files are as follows:

:020000044000BA
:2088F100FEFFFFEAFEFFFFEAFEFFFFEAFEFFFFEAFEFFFFEAFEFFFFEA00F09FE5FEFFFFEAA9
:04891100C40200009C
:00000001FF

Thus an offset to 0x40000000 and the second to last line programs the last data byte at 0x40008914 and the value at that address is 0x00. 'Verify' with str7_pgm.exe tells me that:

...
File and Flash are different:
At address 0x40008914: file is 0x0, Flash is 0xFF
...

Does verify start from the start of the file or the end of the file? The programming is ok though - my program runs at least, the last couple of zeros in the hex-file are hopefully just padding...

Also, 'verify' reads the entire internal flash no matter how i set the S switch. Even if I use S0x001 I still get

...
pre-Reading Flash Bank0... OK
pre-Reading Flash Bank1... OK
Reading Flash Bank0...
................ OK
Reading Flash Bank1... OK
...

which tells me the entire flash is being read. What do I do if I only want to check a single sector (for better performance for instance)?

The F switch also do not seem to have much impact on performance. Either I do F400 or F12000 I get the same execution times. Is this switch ignored in str7_pgm.exe?

Cheers,
Steen

Hi,

Easiest answer first:
the "F" switch is taken into account, but the JTAG clock has not much to do with the overall speed when programming flashes. Everything (PC, USB, RLink, JTAG, etc) is much faster than the Flash modification algorythms.

I'll check for the two other questions and let you know.

Best Regards,

Vincent

Hi,

The "S" switch is not used for the verification. I'll do that in a future version, but it implies modifications in some low layers of the software, so I'll not be able to do it very quickly.

About the last byte not being programmed, it's a bug in the programmation. The ARM tools are handling everything 4-byte aligned. Your hex file is not 4-byte-aligned and we had not foreseen this. I'll correct it by adding some padding and send you a fix next week, maybe Monday. In the meantime, try to have a hex file that uses only 4-byte aligned data. What kind of linker generated this file anyways???

Vincent

Hi,

Here is the fix that corrects the not-4-byte-aligned bug above:
ftp://www.raisonance.com/temp/ST/STR7_pgm_fix_070126.zip

Note that this bug was introduced by the previous fix. (point 5 in the readme) It was not there in the official release. (which was programming the whole flash no matter what)

Best Regards,

Vincent

Hi Vincent.

I'm deeply impressed at how swiftly you are able to support me in this matter. Definetely a big thumbs up for You compared to many other similar cases I have been involved in.

It seems blank-check doesn't use the sector switch either? I can erase bank 0, sector 0 for instance, but can't verify only if this area is erased.

Also, if I lose connection with target during plugin upload, a message box stating "write error" pops up, making it necessary for a test operator to dismiss it before str7_pgm.exe returns. Does a command line switch exist to make these kinds of message boxes not appear? Some kind of 'non-verbose' mode?

Best regards
Steen

Hi,

Well, you were lucky because last week I was working on STR7s already, so I had the software and boards installed, connected and ready and I could look at your problems quickly. But I have to admit that it's not always that fast.

For the Blank-Check and sectors, I'm afraid it's the same answer as for the Verify: I'll do that later.

For the "quiet" mode, I'll try to see if it can be done quickly. But when there is an error, your operator will have to do something anyways... even if just putting the board in the "boards with a problem" box. :)

Warm Regards,

Vincent