bladox.com

[belve]

I have allocated a 3840 bytes buffer in EEPROM by emalloc(). Start address is 0xffb5 and last address is 0x0eb5 as displays pointer value dbih(ptr) function. I store the pointer in persistent memory.
So I have the persistent pointer on a buffer (3840 bytes) in EEPROM. When I write data wb() to the buffer and increment the pointer (ptr++) and the pointer address reach 0xffff eeprom last address an error of wb() to eeprom occurred.
Any idea to resolve the problem to write data until the last address and then repeat cyclic process? If decrements the pointer so the 0x0eb5 last address is not correct. What is the last address in fact? 0x0eb5 or other?

#define RECORD_LEN 32//fixed length record
#define MAX_EEPROM_BUF 3840 //(4096-256=3840) 3840/32 = 120 fixed length records
typedef struct _Pers_data
{
u8 *cp_buf_start_eeprom; //the start of free buffer in EEPROM
u8 *cp_buf_end_eeprom; //the last available address in EEPROM
u8 *cp_buf_eeprom; // the current available address in EEPROM

} Pers_data;
-------------------------------------
case ACTION_APP_REGISTER:
u8 *ptr;
Pers_data *p = emalloc (sizeof (Pers_data));
ptr = emalloc (sizeof(MAX_EEPROM_BUF));//MAX_EEPROM_BUF 3840
ww(&p->cp_buf_start_eeprom, ptr);
ww(&p->cp_buf_eeprom, ptr);//on the initial stage the current address of the buffer is equal to the start address
ptr = ptr + MAX_EEPROM_BUF;//+3840 bytes is the last address
ww(&p->cp_buf_end_eeprom, ptr);
reg_app_data (p);//
--------------------------------------
case ACTION_APP_INIT:
u8 *ptr1;
u8 *ptr2;
u32 k;
Pers_data *p = app_data();
ptr1 = rw(&p->cp_buf_start_eeprom);//start address
ptr2 = rw(&p->cp_buf_end_eeprom);//last address
k = ptr2-ptr1;//the result of subtract calculation displays 120 record - is correct
k = k >>5;//calculation how many records at total we can store in eeprom, 32 bytes per record, >>5 - divide on 32
dbih(ptr1);//0xffb5 (65461) - dispaly fisical address of EEPROM
dbih(ptr2);//0x0eb5 (3765) 0R if assume 0x10eb5 (69301)
----------------------------------------
1/65461-3765=61696 bytes (not correct)
2/ 69301-65461=3840 bytes (CORRECT)
-----------------------------------------
void f (u8 *data)
{
u8 j;
u8 *buf_ptr;
Pers_data *p = app_data ();//
buf_ptr = rw(&p->cp_buf_eeprom);//0xffb5 (65461) - physical address of EEPROM
while (k)
{
wb(&(*buf_ptr), data[j]);//write to EEPROM memory ERROR occured when buf_ptr = 0xffff (more than 0xffff)
buf_ptr++;
j++;
}
ww(&p->cp_buf_eeprom, buf_ptr);
......
}

[pz]

Mmm, where did you get the number 3840? Have you checked the return value of emalloc()? It's too big, can't work.

[belve]

emalloc returns 0xffb5 address as the start of eeprom buffer. +3840 (f00) = 0x0eb5 address as the end of eeprom buffer. I have chosen 3840 bytes as maximum available buffer to store data (32 bytes fixed length*120 records) which I am going to send to a server from time to time. Of course I could emalloc less.
A little problem is the increment ffb5, ffb6, ffb7 ?.fffd, fffe, ffff, 0000 (error occured). I suppose that eeprom hardware physical addresses are from 0000 to 1000. So the 0xffb5 is a kind of error. But 0x0eb5 is correct address. I will try to decrement 0eb5, 0eb4, 0eb3 ?.0001, to 0000.. I will let you know regarding results. I suppose that some Bladox software probably uses a piece of eeprom space 4096 bytes, approximately 330-335 bytes for debugging, run the core, stacks etc or for something else including persistent data.

[pz]

For app the EEPROM is mapped to 0xf000, it's 4k so valid pointer is 0xf000-0xffff. There must be something wrong if emalloc() returned 0xffb5 for 3840 chunk - there simply isn't that memory space. The 0x0eb5 is because dbih() assumes u16 and you are u32. So it's 0x10eb5. Anyway pointer can't be >0xffff.

[belve]

The results of emalloc() for different large buffers size in eeprom.
The first address is ffb5 and the last is 0fb5 (after ACTION_APP_REGISTER) and then is ffaf ( 6 bytes for persistent data and depends on the size of the persistent data structure). I use wb() 0xAA and 0x55 to check that the start and the last address of the buffer works. The last address offsets on - 256 bytes when the buffer size is decremented on 256 bytes.
So it is need to decrement pointer to write bytes correctly for large buffers in eeprom.

76.359 Startbuff size: 0f00 (3840 bytes buffer)
76.406 start addr: ffaf***data: aa
76.437 end addr: f0af***data: 55
76.546 buff size: 0e00 (3840-256 bytes buffer)
76.562 start addr: ffaf***data: aa
76.593 end addr: f1af***data: 55
76.703 buff size: 0d00 (3840-512)
76.734 start addr: ffaf***data: aa
76.765 end addr: f2af***data: 55
76.875 buff size: 0c00
76.906 start addr: ffaf***data: aa
76.937 end addr: f3af***data: 55
77.046 buff size: 0b00
77.062 start addr: ffaf***data: aa
77.093 end addr: f4af***data: 55
77.203 buff size: 0a00
77.234 start addr: ffaf***data: aa
77.250 end addr: f5af***data: 55
77.359 buff size: 0900
77.390 start addr: ffaf***data: aa
77.437 end addr: f6af***data: 55
77.546 buff size: 0800
77.562 start addr: ffaf***data: aa
77.593 end addr: f7af***data: 55
77.703 buff size: 0700
77.734 start addr: ffaf***data: aa
77.750 end addr: f8af***data: 55
77.859 buff size: 0600
77.890 start addr: ffaf***data: aa
77.921 end addr: f9af***data: 55
78.031 buff size: 0500
78.046 start addr: ffaf***data: aa
78.078 end addr: faaf***data: 55
78.203 buff size: 0400
78.234 start addr: ffaf***data: aa
78.250 end addr: fbaf***data: 55
78.359 buff size: 0300
78.390 start addr: ffaf***data: aa
78.421 end addr: fcaf***data: 55
78.531 buff size: 0200
78.546 start addr: ffaf***data: aa
78.578 end addr: fdaf***data: 55
78.687 buff size: 0100
78.718 start addr: ffaf***data: aa
78.734 end addr: feaf***data: 55
78.859 buff size: 0000 (3840-3840 bytes)
78.890 start addr: ffaf***data: aa
78.921 end addr: ffaf***data: 55

[belve]

By the way... Is a possibility to get income call MSISDN? Voice or sms

[belve]

Sory... I mean visa versa How to get MO MSISDN desination call So Whom I am calling to