Greetings,
My port of AWE (6.17) core to the L4 has run into a flash interface behavior I have not figured out how to resolve.
After successfully initializing the flash (similarly, format works as well), when I attempt "Add File" (in my case a .awb file), my awe_pltWriteFlashMemory() gets called to write to the same address more than once which, of course, fails. Details follow.
During init, awe_pltWriteFlashMemory() gets called 3 times (5 d-words, 1 d-word, 1 d-word respectively).
During Add File, awe_pltWriteFlashMemory() succeeds 3 times (1 d-word, 1 d-word, 5 d-words). On the fourth call (to write 1 d-word) it is called to write the same location (0x80e0048 in awe's view of flash) as it successfully wrote the first time it was called for the Add File operation. This, of course, fails.
Presumably I have an initialization screwup of some sort but I'm not seeing it. As is apparent from below, each awe d-word is stored as a 64 bit value due to the L4 flash limitations. However, the remapping does not appear to me to be related to this issue.
/* (AWE view) The following three are the (not in order) parameters for awe_pltInitFlashFileSystem */
#define FILE_SYSTEM_START 0x080E0000 /* first address of awe 64k chunk of
flash (of which awe will only perceive 32k) */
#define FLASH_AWE_MEMORY_END_PLUS_1 (FILE_SYSTEM_START + 32 * 1024) /* end of AWE's view of flash */
#define AWE_ERASEABLE_BLOCKSIZE 0x0400 /* AWE will percieve erasure of 1k pages */
#define FLASH_DEVICE_DWORDS (FLASH_AWE_MEMORY_END_PLUS_1 >> 2)
/* L4 view of flash */
#define FLASH_START 0x08000000 /* first address of flash */
#define FLASH_END_PLUS_1 0x08100000 /* end of (main) flash in the L4 */
#define L4_ERASEABLE_BLOCKSIZE 0x0800 /* L4 erases in 2k byte chunks */
...
(maybe more g_filesystem_info initialization is required?)
g_filesystem_info.m_FlashDeviceDWords = FLASH_DEVICE_DWORDS;
if (FAILURE == InitFlashFileSystem(FLASH_AWE_MEMORY_END_PLUS_1,
AWE_ERASEABLE_BLOCKSIZE,
FILE_SYSTEM_START)) {
...
All insight and suggestions are appreciated.
Steve.
2:43pm
Hi Steve,
Are you using the STM32L496 reference BSP available on our downloads page as the guide for your port?
Also note that we only support reading and writing 32-bit values to the flash in the flash file system library.
-Axel
2:56pm
Greetings Axel,
I am using the STM32L496 reference BSP (AWE BSP stm32l496 s1.4) as the guide for my port. And, short of the flash functionality, everything appears to be working.
I have noted that awe only supports reading and writing 32-bit values. My interface addresses this by providing what looks to awe as a contiguous 32k block, erasable via 1k pages to be accessed by reading and writing 32 bit values. Under the hood, the implementation uses a 64k block, erasable via 2k pages with each 32 bit awe value stored in a 64bit word. As mentioned in the original post, this mapping appears to work as expected and awe is successfully reading, writing and erasing. Nonetheless, awe is also requesting a flash write to an address it has already written to.
Any clues are appreciated.
Thanks for your help,
Steve.
3:26pm
Steve,
Internally we do calculations based on flash memory addresses that expect to be addressing contiguous bytes as contiguous 32-bit words. There are calculations like this:
// Calculate number of DWords not taken up by the application and boot loader
nAvailableDWords = ( g_nFlashMemorySizeBytes - (INT32)g_nStartOfFileDataFlashAddr ) >> 2;
Is it your expectation that your scheme of using 64-bit entities will work with this code?
3:53pm
Hi Chris,
Interesting question... and the answer is, it depends...
Based in the information my code is telling AWE (which is limited to:
g_filesystem_info.m_FlashDeviceDWords = FLASH_DEVICE_DWORDS;
if (FAILURE == InitFlashFileSystem(FLASH_AWE_MEMORY_END_PLUS_1,
AWE_ERASEABLE_BLOCKSIZE,
FILE_SYSTEM_START)) {
(see an earlier post for the symbol definitions)
then yes, my expectation is that it will as this presents an address space visible to awe as a contiguous space of 32bit words. However, I will not be surprised if something is causing my expectation to be wrong (i.e. we know something is breaking it...).
But I don't know how g_nFlashMemorySizeBytes and g_nStartOfFileDataFlashAddr have been determined.
if g_nStartOfFileDataFlashAddr == FILE_SYSTEM_START
and g_nFlashMemorySizeBytes == FLASH_AWE_MEMORY_END_PLUS_1
then I don't see a problem (but, obviously, there is one somewhere...).
Steve.