Øyvind Harboe wrote:
>> Maybe the following example (output is pasted below) can illustrate the issue
>> a bit better. First I try to flash a 20KB block, then a 21KB block and
>> finally a 24KB block. Only the blocks of 20 and 24 succeed, because they
>> happen
>> to be nicely 4K alligned. All blocks that are not 4K alligned will fail.
>> OpenOCD
>> tries to erase, (un)protect and flash only those sectors that are modified,
>> but doesn't take into account that some platforms require certain alligments.
>
> This error message is specific to stm32.
>
> Did you look at the stm32 source code?
Yes, I know that code. I've got a committed patch of mine in there.
> Are you *sure* the error message isn't in fact telling you that this is a
> quaint
> requirement of stm32?
It most certainly an STM32 specific quirk. This is sort of what I was trying to
say in the first place. Let met explain further:
* The "flash write_image" function is trying to be smart by only deleting,
(un)protecting and flashing those sectors that have to be modified. This is a
good thing.
* The STM32 specific flash code has certain alignment requirements, which
currently only generate an error in case of a non-compliant situation. This is
not very bad, but it can be done better.
* My suggestion is to add a global parameter which tells OpenOCD to handle
alignment issues in a smart way (globally); by adjusting the sector counts
automatically in such that these errors do not appear. I suggest that we do not
make this the default setting, because the "flash write_image" and "flash
write_sectors" use the same code to write to the flash. If the default settings
are such that OpenOCD automatically adjusts sector counts, then the user might
get unexpected results when using "flash write_sectors". So to be safe, OpenOCD
must not adjust sector counts, but only when told to do so.
* For now, the smart_sector_aligment setting will only be regarded by the
STM32-specific code. Any other platforms that are eligible for alligment
smartness? A quick grep through the code gives:
./src/flash/lpc288x.c:320: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/lpc2000.c:568: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/stellaris.c:946: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/stm32x.c:572: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/str9xpec.c:589: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/pic32mx.c:482: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/at91sam7.c:975: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/avrf.c:229: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/str9x.c:481: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/str7x.c:449: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
So, I'll try and figure out where smart_aligment might be useful. As these are
quite a diverse bunch of controllers, I'm not sure I dare touch all of the
code. I'll have to see if it's worth the trouble, if at all do-able.
> There is a bug in stm32 code in that it gives you a warning and not
> an error, but that's minor.
>
>
> if ((first && (first % stm32x_info->ppage_size)) || ((last + 1) &&
> (last + 1) % stm32x_info->ppage_size))
> {
> LOG_WARNING("Error: start and end sectors must be on a %d sector
> boundary", stm32x_info->ppage_size);
> return ERROR_FLASH_SECTOR_INVALID;
> }
Correct. And I will remove this little "beauty mark" along with adding the
alignment parameter then :-)
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
