Mleaf / stm32flash

Automatically exported from code.google.com/p/stm32flash
0 stars 0 forks source link

No support for specifying read address ranges #23

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
See attached patch which adds ability to (optionally) specify start address and 
length of a read.

Original issue reported on code.google.com by reubendowle0@gmail.com on 5 Jan 2012 at 8:50

Attachments:

GoogleCodeExporter commented 9 years ago
Here is a patch that is applied against the cvs version of the code. Needs 
patch from issue 22 to be applied also.

Original comment by reubendowle0@gmail.com on 5 Jan 2012 at 10:02

Attachments:

GoogleCodeExporter commented 9 years ago
Looks good also, but issue 22 needs to be updated before it will be applied.

Original comment by ge...@spacevs.com on 14 Jan 2012 at 8:33

GoogleCodeExporter commented 9 years ago
See attached for patch against git merging branch, which adds a new -S 
address[:length] parameter

Original comment by reubendowle0@gmail.com on 26 Nov 2012 at 8:58

Attachments:

GoogleCodeExporter commented 9 years ago
Thanks for the patch! A very welcome functionality.

Note that I have done some coding style fixups that I will squash into the same 
commit. Most of the existing code follows what seems to me like K&R or Linux 
kernel coding style http://www.kernel.org/doc/Documentation/CodingStyle so I 
try to apply that when changing any code. Maybe later when there is no more 
pending patches I will do a full style clean-up of the whole code. In your 
patches it is mostly about having spaces after "if" and opening brace on the 
same line, and braces on the same line as "else".

Original comment by lists.to...@gmail.com on 27 Nov 2012 at 7:41

GoogleCodeExporter commented 9 years ago
While testing I have bumped into a couple of problems with your patch. When 
writing to flash, if I specify address but no length and a small file, it will 
error out with "Specified start & length are invalid" because it calculates 
"end" from the flash end instead of start + size (of file). "end" should 
probably be the smaller of those two. Or the corresponding bound checking must 
be rewritten.

Also, per comment "Assume data from stdin is whole device" it neglects any 
given start address and this is not good. It should calculate "size" from flash 
end - start address in this case.

Original comment by lists.to...@gmail.com on 16 Dec 2012 at 11:06

GoogleCodeExporter commented 9 years ago
Your patch is now in the official code. I'll keep this bug report open just to 
remember the issues in my last comment.

Original comment by lists.to...@gmail.com on 10 Dec 2013 at 7:17

GoogleCodeExporter commented 9 years ago
Hi,

How about optionally disabling the address range checks? That would enable 
users to read the unique ID bits or other ROM-programmed data.

Original comment by Andrew.Shadoura on 11 Jan 2015 at 4:10

GoogleCodeExporter commented 9 years ago
Actually, it would be extra cool to have an additional option to read the 
unique id choosing the correct address for the chip automatically.

Original comment by Andrew.Shadoura on 11 Jan 2015 at 4:11