FlashIAP: Fix problem of programming source buffer not aligned to 4 #6864
Conversation
| // 1. Size is not page aligned | ||
| // 2. Source buffer is not aligned to uint32_t. This is not supported by many targets (although | ||
| // the pointer they accept is of uint8_t). | ||
| if (unaligned_src || (chunk < page_size)) { |
There was a problem hiding this comment.
Thoughts on just copying to the internal buffer for all program calls?
There was a problem hiding this comment.
Not very efficient. I suspect that the vast majority of calls will have both buffer and size aligned.
|
/morph build |
| @@ -22,6 +22,7 @@ | |||
| #include "utest/utest.h" | |||
| #include "unity/unity.h" | |||
| #include "greentea-client/test_env.h" | |||
| #include <algorithm> | |||
There was a problem hiding this comment.
What exactly is this importing? This is the first time I've ever seen a system file simply called "algorithm".
There was a problem hiding this comment.
It is actually used quite a lot. It imports the std::min and std::max functions.
Build : SUCCESSBuild number : 1978 Triggering tests/morph test |
Exporter Build : FAILUREBuild number : 1629 |
Test : SUCCESSBuild number : 1791 |
|
Morph exporter needs to be restarted. Looks like failure is due related to tools. |
|
/morph export-build |
Exporter Build : SUCCESSBuild number : 1632 |
Description
This PR resolves a problem (found by @yossi2le) when programming the internal flash via FlashIAP: The
programAPI receives aconst void *bufferparameter as the source buffer to program. As such, the program buffer can point to data of any kind, without alignment restrictions. However, many of the target specific flash drivers assume this buffer is aligned touint32_tand thus cast it touint32_t*.Freescale's
flash_apimodule shows a typical example for that. Other targets do the same as well.Solution is by using an aligned buffer for this case in FlashIAP. This was already implemented for unaligned program sizes. Same code is now used for the unaligned source buffer case.
This PR also modifies the FlashIAP programming test code, as the previous one was quite trivial and didn't check this scenario as well.
This fix also resolves issue #6706.
Pull request type