Wrong contents written for particular binary file

[carrotIndustries]

When writing this https://www.dropbox.com/s/ykshejjyu77pwmy/rand.bin file at 0x8004000 using

st-flash  write /tmp/rand.bin 0x8004000

and reading it back using

st-flash read /tmp/flash.bin 0x8004000 0x7d0

the read data https://www.dropbox.com/s/9w2vjmo1ap0i97e/flash.bin differs from the written data around offset 0x650. Writing the binary file using the built-in dfu bootloader works just fine.

STM320F407 on STM32F4DISCOVERY

[yigitb]

I ran into the same issue with a different binary file. I'm using an STM32F417.

• The same binary file gets corrupted in the same way, even on different processors.
• Chopping up the binary file into chunks and writing each chunk separately causes different corruptions, but still consistent.
• Windows programmer works fine.

[texane]

Hi,

I reviewed the code in file src/stlink_common.c, function
stlink_fwrite_flash. There
is a logic to compute already erased bytes. I wonder how this
implementation can
possibly work. It should compute offsets from the beginning and end of
file, not in
between. It likely explains why you see corrupted bytes.

Could you comment the num_empty computation logic (from line 1749 to 1760)
and
tell if it solves your issue ?

Thanks

2014-03-20 20:42 GMT+01:00 yigitb [email protected]:

I ran into the same issue with a different binary file. I'm using an
STM32F417.

• The same binary file gets corrupted in the same way, even on
  different processors.
• Chopping up the binary file into chunks and writing each chunk
  separately causes different corruptions, but still consistent.
• Windows programmer works fine.

Reply to this email directly or view it on GitHubhttps://github.com//issues/193#issuecomment-38212063
.

[yigitb]

Hi,

I commented out the num_empty lines, and the corrupted bytes are still there, at the same location as before.

Here is the diff of the what's programmed vs. what's on the processor:
http://pastebin.com/JsvfMKnt

The version with a lot of 0's are from the processor.

The differences after the first line are actually starting from offset 0xc000, if that makes a difference.

Thanks.

[texane]

Thanks for the info, I will investigate asap. Any help welcome !

2014-03-24 14:19 GMT-05:00 yigitb [email protected]:

Hi,

I commented out the num_empty lines, and the corrupted bytes are still
there, at the same location as before.

Here is the diff of the what's programmed vs. what's on the processor:
http://pastebin.com/JsvfMKnt

The version with a lot of 0's are from the processor.

The differences after the first line are actually starting from offset
0xc000, if that makes a difference.

Thanks.

Reply to this email directly or view it on GitHubhttps://github.com//issues/193#issuecomment-38488540
.

[yigitb]

Hi again,

I think I found a workaround. I commented out the lines that set the stack pointer and the program counter, then run the processor after programming in stlink_fwrite_flash() (lines 1763, 1765, 1766 in stlink-common.c).

The specific binary file I was working with programmed just fine. I tested it multiple times and on two different processors, and they are correct byte by byte. I didn't try any other binary files yet.

I honestly have no clue why this workaround works, though.

[texane]

It is strange. Could you remove your comments and put a long delay (
sleep(5); )
at line 1762 ? Maybe setting the PC disturbs an in progress flash operation
(ie.
the loader code ran by run_loader).

Let me know,

Thanks

2014-03-24 16:41 GMT-05:00 yigitb [email protected]:

Hi again,

I think I found a workaround. I commented out the lines that set the stack
pointer and the program counter, then run the processor after programming
in stlink_fwrite_flash() (lines 1763, 1765, 1766 in stlink-common.c).

The specific binary file I was working with programmed just fine. I tested
it multiple times and on two different processors, and they are correct
byte by byte. I didn't try any other binary files yet.

I honestly have no clue why this workaround works, though.

Reply to this email directly or view it on GitHubhttps://github.com//issues/193#issuecomment-38504828
.

[yigitb]

Hi,

The sleep() call didn't seem to change anything. The binary still gets corrupted if the register sets are there.

[texane]

Thanks for the info. Then, I have no clue ...

2014-03-27 14:11 GMT-05:00 yigitb [email protected]:

Hi,

The sleep() call didn't seem to change anything. The binary still gets
corrupted if the register sets are there.

Reply to this email directly or view it on GitHubhttps://github.com//issues/193#issuecomment-38847622
.

[xor-gate]

As this is a old issue, please test against latest tools in master, and latest stlink firmware. Reopen a new issue when the problem still exists with more details.

[Nightwalker-87]

This problem appeared about one month before Release v1.0.0. This has likely been fixed somewhen around that point in time, but not clear where exactly - which would be helpful though. Maybe addressed by 5dcd45d ? Any helpful ideas when looking at it?

[Nightwalker-87]

@chenguokai: You contributed to "st-flash write is ignoring 0xff at end of file" (Issue 609).
Could this be related to optimisation too?

[chenguokai]

It could be, I will check the binary file if possible.

Edit: The diff results seem to be irrelevant with the 0xff ones. That issue only affects the tail empty bytes. For this one, however, corrupted bytes appear in the middle.

[Nightwalker-87]

Obviously fixed by #377 where the mentioned code section was rewritten.
According to #377 (comment) the previous implementation was not functional.