Main Site Documentation

Max size of EWR for each platform


#1

Where can we found this information?


#2

Thanks Andre. My Mfdeploy tool (or the EMX) was not indicating EWR in the log. This is why I have never associated Storage A and B with EWR (cf the following code):
Flash Sector Map Command
Sector Start Size Usage

0    0x80000000  0x00030000   Bootstrap
1    0x80030000  0x00090000   Code
2    0x800c0000  0x00020000   Storage (A)
3    0x800e0000  0x00020000   Storage (B)
4    0x80100000  0x00010000   Bootstrap
5    0x80110000  0x00030000   Application
6    0x80140000  0x002b0000   Deployment
7    0x803f0000  0x0000a000   Deployment
8    0x803fa000  0x00002000   Bootstrap
9    0x803fc000  0x00002000   Bootstrap

10 0x803fe000 0x00002000 Configuration
11 0x00000000 0x00004000 Bootstrap
12 0x00004000 0x00004000 Code
13 0x00008000 0x00070000 Code
14 0x00078000 0x00006000 Code
15 0x00000000 0xece00000 File System
Loop performs in334175 micro seconds
16 0x00000000 0x0f100000 File System
Flash Sector Map Complete

Now is there’s a way to know what is the actual size of the data that I put into it?


#3

Sorry but I do not understand the link between the 256kB announced by GHI on page 34 for the EMX and the 2x 20k(Byte?) shows by mfdeploy


#4

Ok, I should have search more. Thanks for your fast replies!!!

Still have to determine what is the size of the data I am storing to have the theoritical limit…


#5

It seems that EWR size have changed with the new SDK release. On my EMX board: the GHI Configuration tool reports:
Sector Start Size Usage

 0            0x80000000          0x00030000   Bootstrap
 1            0x80030000          0x00110000   Code
 2            0x80140000          0x00010000   Storage (A)
 3            0x80150000          0x00010000   Storage (B)
 4            0x80160000          0x00010000   Bootstrap
 5            0x80170000          0x00280000   Deployment
 6            0x803f0000          0x0000a000   Deployment
 7            0x803fa000          0x00002000   Bootstrap
 8            0x803fc000          0x00002000   Bootstrap
 9            0x803fe000          0x00002000   Configuration
10            0x00000000          0x00004000   Bootstrap
11            0x00004000          0x00004000   Code
12            0x00008000          0x00070000   Code
13            0x00078000          0x00006000   Code

Is it a bug? I didn’t read any info about that.


#6

This means that on 4.1 256kB was available whereas only 128kB are available on 4.2. I think this is really important and did not see any info about that…

Reducing the size by two is a lot… even if we are not abble to know what size we need (because there’s no way to know what our actual data takes…)


#7

Where did you see that in EMX doc?. Yes the problem is that knowing the limit is useless if there’s no way to check the size of our stored data… or to compute it…


#8

The doc says “256KB is reserved for two EWR (Extended Week References) regions, each region being 128KB and one of them is reserved for CLR use.”

But What I see is two block of 65kB (size = 10000)

What is wrong? Is there problem in byte bit conversion?


#9

And so at the end… there’s only 64K available. Am I right? May be GHI should details more this on his doc. I think the community need to have a way to know if data can be stored or not due to space limitation as it is a design constraint… First people read the doc and say: " ok 4MB of flash COOL!!! this board is enough… and finally they discover that there’s only 64K available and still this may be less since nobody know how data are store and what is the impact of serialization…


#10

EWR was always problematic. We improved it by adding flush feature so it works better for small object. Maybe under 1KByte. So the memory as reduced but it is still a lot larger than what a user should need, in most cases at least.

The manual was not updated. We will take care of it when possible.