Sector size for 2.72 (8M)

[CoryCasanave]

The sector size for 2.72 is 4096. This code will find it, perhaps you could add it and make SectorSize variable?

u16 SectorSize = 0;
u8 flash_mode = 0;
u8 SecBuff[LARGEST_SECTOR_SIZE];
uc8 DiskDevInfo_8M[]={"8MB Internal"};

define FLASH_8M 1

define FLASH_2M 0

define FLASH_2M_SECTOR_SIZE 512

define FLASH_8M_SECTOR_SIZE 4096

define LARGEST_SECTOR_SIZE 4096

define BUFFER_SIZE 16384

extern u8 flash_mode;
extern u16 SectorSize;

define DEVICEINFO 18 //DISK=7 (FLASH 2M,OR 8M)

/*******************************************************************************
Initialize the file system return value: 0x00 = successful
Primarily sets variables for flash_mode and SectorSize
*******************************************************************************/
u8 InitFileSystem() {
u32 ptr;
u8 Ver[8];

if (SectorSize!=0) return 0;

ptr=_Get(DFUVER);
memcpy(Ver,(u8)ptr,5);
ptr=(Ver[1]-'0')_100 +(Ver[3]-'0')_10 +(Ver[4]-'0');
if(ptr<=311){
flash_mode=FLASH_2M;
SectorSize = FLASH_2M_SECTOR_SIZE;
// __Display_Str(1_8, 10, YEL, PRN, "FLASH_2M");
}
else{
ptr=__Get(DEVICEINFO);
if(memcmp((u8*)ptr,DiskDevInfo_8M,3)==0){
flash_mode=FLASH_8M;
SectorSize = FLASH_8M_SECTOR_SIZE;
}
else {
flash_mode=FLASH_2M;
SectorSize = FLASH_2M_SECTOR_SIZE;
}
}
if (SectorSize>LARGEST_SECTOR_SIZE) { //This should never happen
SectorSize = 0;
return 255;
}
return 0;
}

[gabonator]

This looks like a serious problem... the firmware can hardly fit the RAM and with extra 4kB it would need some redesign... Maybe if I remove some useless parts of the FW I could save some space...

[CoryCasanave]

See the thread: http://www.seeedstudio.com/forum/viewtopic.php?f=26&t=5128&start=10
There have been some linking options to make more RAM available that have seemed to work. Of course, removing useless stuff is always good! Also, can you say what the "user app" slots do?

[roberttidey]

I made the changes that are on the referenced forum. I am trying to make it work for a relative who has the 8M model whereas I have the 2M.
I'm not totally sure about the RAM allocation but the memory map seems to indicate that 2 sector bufffers are allocated and so going from 512 to 4096 actaully uses 7kB more memory and the build definitely complained with the existing lds files. The current top of memory seemed to be a bit beyond the nominal 48K but well below the actual 64K. So I added 8K to the RAM length in the LDS files and it was then happy building and still seems well below the 64K limit. It seems to run fine still in 2M mode and one user reports that it seems OK in 8M but I can't verify it myself at the moment.
One bit I wasn't sure about was the stack pointer initialisation. I didn't make any explicit changes for that so I assumed it gets adjusted following the LDS change. Having looked a bit further it looks like end stack is always set to 64K by main.lds so doesn't need adjusting.
I have also now forked this and put the changes in there.

[groobybugs]

Hi! well about the 8M device I have it. At the beginning of the year I could fix that problem I don't know if that was the best way but everything works fine i make a little changes if you want i tell you what have done and you will said if that's right.