SCI SMS Counter Info - error 50000 SMS received? - GSM-Forum

cyperghost · 08-25-2004, 20:23

The error is not new as we know but maybe we can solve that problem together. I don't know in which action the counter gets mad. I think it occurs if you see the counter and then get simultanly a SMS. Maybe I'm wrong but with that configuration of events I was able to get some of this errors and I saw that the counter is not set by any random number - it's round about 50300+

It's really hard work to reproduce an error you can't track everytime

but maybe it's the configuration I made above. I was able to track that to times today. Well I made a lot of calls and get calls as I used Dicataphone and Java midlets. Maybe it's one of that?

We can solve the problem if we can get sure that the number is a fix one (I mean it is independent from mobile patch configuration, date events or whatever). We can use a BIN file to fix that problem if occoured. Maybe like that.

~~
Read EEP area
if counter > 50000 then set counter-50000
Write new counter
~~

I think it must sound a bit childish but I don't understand how to produce a BIN file that can be executed by mobile phone.
I also test the SCI 3.x now maybe (as I mentioned it on myself) the problem occoured since the "Set Date of last Reset" action and this was version 4.x of the SCI Patch.

May the farce be with you

koper · 08-25-2004, 20:40

I have the same problem, and I'm using version 3.X...

greetings

yiourkas · 08-25-2004, 21:03

Actually the number i get is a little below 50000 (i.e. 49935 or 49960)
I think the problem is that some other procedure writes to that specific eeprom block.

Also keep in note that if your mobile hang for any reason or run out of battery, then the values in eeprom are restored to the values of the last successfull shutdown of your mobile...

cyperghost · 08-25-2004, 21:27

That's the question I also want to answer

Is the number of that error is a fix one or not. I only know it's round about 50000. Maybe I or someone other can made a exact counting of that. If the number is fix we can solve it. If not well than not.

Well first I want to write I can't agree your argument that annother process uses the same eep content.... [-=EDIT

=-]but if I'm thinking over I just agree with you! Why?

The problem was never reported in version 1.x of that Patch. Why was that possible, because the data was written during a normal shutdown of the phone, that means if there was annother data in this place, during shutdown, the old (the 50000+ counter) was overwritten by the actuelly used counter.....

I must say I'm not sure about this but it sounds good and resolveable

Maybe we can swap the counter to annother location?

lalo.lerry · 08-25-2004, 22:57

I also think it's a eeprom location conflict.
So I take this occasion and ask:
How can we understand if a eeprom block is really not used by phone (exept of course FFs)?
And a RAM location?
(post answer here or in technical thread)

rizapn · 08-25-2004, 23:50

*/ Agree with yiourkas. Maybe, relocating the RAM/EEPROM address will solve this strange problem. I'll try it ...
*/ About EEPROM. I think, the best way is create a new (a real free) EEPROM block to save our own data (just like what I did in the Password Access patch).
*/ About Free RAM? I dunno. I use AT+CGSN to check their values, if there are many 00 or FF, then I think that RAM is never used (but it is probably use by other function in the phone which never executed by me before dumping it).

rizapn

cyperghost · 08-26-2004, 07:29

@riza

The strange thing is, that nobody knows when this error occours (If somebody knows please write your opinion here - don't be afraid, we don't bite!)
Some content of the EEP I really don't understand, sometimes, I can read my announcments (birthdays, meetings...) two times - the same with the user DB of the t9.

trustkill · 08-26-2004, 09:19

I have received 50265 SMS

Sometimes after online flashing (I know I should not do this

) the phone
crashes. After that the received SMS are about 50xxxx. It´s not a fixed number.

Why don´t we write the numbers in a .log file, there is no conflict with ram

rizapn · 08-26-2004, 09:28

@trustkill: hehehe, writing something to the file is a last choice I think. Why? because the known "save" procedure to do write file is not really save (do you remember that you ever lose your Addressbook

caused by file access patch?) ...

rizapn · 08-26-2004, 12:39

@all:
I think I know what's the problem is. It is really my fault. I was creating a bad formula to determine the size of data need to be saved (1 byte shorter).

So, please reapply your SCI patch with this ones. If it is really the solution, I will copy it to the Sticky ...

;~~~~~~~~~~~~~~~~~

;*** SCI. SMS Counter Info ***

;Firmware : SL45v56
;Author : RizaPN
;Released : June 29, 2004
;Updated : August 12, 2004 (v4.1)

;Adapted from the same patch for 6688i by CoolLang

;Modify ---Help--- menu inside the "Message-SMS" menu with "SMS report" menu.
;Add a capability to give info about the number of received and sent SMS
;since the latest "Clear" action.

;Add confirmation dialog for "Clear" function.
;Does not count the Status report SMS for incoming.
;v3->save the count data directly to the EEPROM to prevent from loosing data
;due to abnormal shutdown.

0x18A8E2: DEFFEB00 B047E400
0x18A956: 2801AB02 53045304

0x39BE4C: DAE5CEDD DAE4DA48
0x39BE9C: DAE5CEDD DAE4DA48

0x44E700: DAE5DA25 DAE49848
0x4447B0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 8890888026F05000F08066F8FF3FE6FE
0x4447C0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 0409BB3AE6F92D00D7403600F2F47409
0x4447D0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 8840C08CBB3DA840C09C66FC0F00BB38
0x4447E0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 9840C09C7C4C06FCD407E0D9BB31E6FE
0x4447F0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 1409BB22E6F46809BB28E6FE2409BB1C
0x444800: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF E009E6F46A09BB21E6FC8B13F0D066FD
0x444810: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FF3FF2FE02FEE00FDAE69C59E6FC5C09
0x444820: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF E6FD9103E6FE5809F0FDDAE5D8EC06F0
0x444830: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 500098809890DB00F0C8F2FD02FEE6FF
0x444840: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 9103DAC71685F08CCB00D7403600A8C4
0x444850: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF F0D8F2FE02FEDAC71E89008CF049DC45
0x444860: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF B9880881CB0046FE23003DE5E6FEE025
0x444870: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF D7600D00982E983E984E26F4D4075C44
0x444880: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 7034F156E004D7603600F6F46A09F6F4
0x444890: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 6809F6F274090D0FDAE5DA25D7403200
0x4448A0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF F3F8F00267F840003D17E01CD7403600
0x4448B0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 04FC68090D00E00F88F088F088F0E6FC
0x4448C0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 5A0088C0E6FCC613E6FD6809E6FE3600
0x4448D0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF DAC2922F06F00800DB00E014D7403600
0x4448E0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 04F46A09DAE5CEDD0DE6F04E46FE1000
0x4448F0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 3DF3E6FC3409E6FD9103E6FE5409F0FD
0x444900: FFFFFFFF FAE5CEDD

;This is the last_reset text:
0x444904: FFFFFFFFFFFFFFFFFFFFFFFF 4C6173742072657365743A0D
0x444910: FFFFFFFF 00000000

;This is the Received text:
0x444914: FFFFFFFFFFFFFFFFFFFFFFFF 52656365697665643A200000
0x444920: FFFFFFFF 00000000

;This is the Sent text:
0x444924: FFFFFFFFFFFFFFFFFFFFFFFF 53656E743A20000000000000
0x444930: FFFFFFFF 00000000

0x444934: FFFFFFFFFFFFFFFFFFFFFFFF 03000000020030750000FF7F
0x444940: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 000000006648E400000000005A2CE202
0x444950: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 264E0200E000FF7F8B13FF7F00400000
0x444960: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 220000000000530400000000EA48E400
0x444970: FFFFFFFFFFFFFFFFFFFFFFFF 000000002A17E30200000000

;~~~~~~~~~~~~~~~~~

rizapn

cyperghost · 08-26-2004, 12:51

Okay, I'm your man

Thanks

rizapn · 08-26-2004, 15:21

I do some patches recheck, and found that BCI is also possible to create that problem. There is something "strange" in the BCI patch about saving the Charge info data into the EEPROM. I try to modify the BCI patch also, and here is the result:

(Please try to apply this if you still have problem after applying the modified SCI patch with the ones published by me in the previous posting) ...

;~~~~~~~~~~~~~~~~

;*** BCI. Battery Charge Info ***

;Firmware : sl45v56
;Author : rizapn
;Created : August 7, 2004
;Updated : Aug 26, 2004

;Record the last charging info (date w/o year, time, and voltage)
;into the EEPROM.

0x454A52: DAB9A49A DAE4804E

0x444E80: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF DAB9A49A4845FD418840D7403400F3F8
0x444E90: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 2C3EE6FCDC25D7700D00981C982C983C
0x444EA0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 985CF1924198ED0207F93C0021984995
0x444EB0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 8D2BD7403400F7F22C3ED7400E00F2F4
0x444EC0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF E23926F4480D7C447C215C617182C031
0x444ED0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 5C2270125C7570155CB37013E6FD7909
0x444EE0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF E6FE3600DC5E898D881DE6FD6809E00F
0x444EF0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 88F088F088F0E6FC5A0088C0E6FCC613
0x444F00: FFFFFFFFFFFFFFFFFFFFFFFF DAC2922F06F008009840DB00

;~~~~~~~~~~~~~~~~~~~~

rizapn

Maciek_K · 08-26-2004, 16:22

Hey Riza. I think, you forgot to paste these two lines in the SCI patch:

0x18A8E2: DEFFEB00 B047E400
0x18A956: 2801AB02 53045304

In my opinion the 50xxx error occurs because this place in memory is used by the phone. I remember, when I first time loaded this patch (version that saves data to eeprom) there was this number in incoming 50xxx, right after loading this patch, so this place in my eeprom wasn’t clean.

Greetings.

cyperghost · 08-26-2004, 17:03

No k-mac! It could be that the old data was filled with FFFFFFFFFFFFFFFFFFF blocks

trustkill · 08-26-2004, 20:00

ääähm, riza ?

I just did undo the sci v4.1 and applied the new version you post above.

There is no more any SMS-Report instead of help....

08-25-2004, 20:23	#1 (permalink)
cyperghost No Life Poster Join Date: Oct 2003 Posts: 705 Member: 42457 Status: Offline Thanks Meter: 1	SCI SMS Counter Info - error 50000 SMS received? The error is not new as we know but maybe we can solve that problem together. I don't know in which action the counter gets mad. I think it occurs if you see the counter and then get simultanly a SMS. Maybe I'm wrong but with that configuration of events I was able to get some of this errors and I saw that the counter is not set by any random number - it's round about 50300+ It's really hard work to reproduce an error you can't track everytime but maybe it's the configuration I made above. I was able to track that to times today. Well I made a lot of calls and get calls as I used Dicataphone and Java midlets. Maybe it's one of that? We can solve the problem if we can get sure that the number is a fix one (I mean it is independent from mobile patch configuration, date events or whatever). We can use a BIN file to fix that problem if occoured. Maybe like that. ~~ Read EEP area if counter > 50000 then set counter-50000 Write new counter ~~ I think it must sound a bit childish but I don't understand how to produce a BIN file that can be executed by mobile phone. I also test the SCI 3.x now maybe (as I mentioned it on myself) the problem occoured since the "Set Date of last Reset" action and this was version 4.x of the SCI Patch. May the farce be with you

08-26-2004, 12:39	#10 (permalink)
rizapn No Life Poster Join Date: Mar 2002 Location: -[r0]- Age: 53 Posts: 834 Member: 9891 Status: Offline Thanks Meter: 2	@all: I think I know what's the problem is. It is really my fault. I was creating a bad formula to determine the size of data need to be saved (1 byte shorter). So, please reapply your SCI patch with this ones. If it is really the solution, I will copy it to the Sticky ... ;~~~~~~~~~~~~~~~~~ ;* SCI. SMS Counter Info * ;Firmware : SL45v56 ;Author : RizaPN ;Released : June 29, 2004 ;Updated : August 12, 2004 (v4.1) ;Adapted from the same patch for 6688i by CoolLang ;Modify ---Help--- menu inside the "Message-SMS" menu with "SMS report" menu. ;Add a capability to give info about the number of received and sent SMS ;since the latest "Clear" action. ;Add confirmation dialog for "Clear" function. ;Does not count the Status report SMS for incoming. ;v3->save the count data directly to the EEPROM to prevent from loosing data ;due to abnormal shutdown. 0x18A8E2: DEFFEB00 B047E400 0x18A956: 2801AB02 53045304 0x39BE4C: DAE5CEDD DAE4DA48 0x39BE9C: DAE5CEDD DAE4DA48 0x44E700: DAE5DA25 DAE49848 0x4447B0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 8890888026F05000F08066F8FF3FE6FE 0x4447C0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 0409BB3AE6F92D00D7403600F2F47409 0x4447D0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 8840C08CBB3DA840C09C66FC0F00BB38 0x4447E0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 9840C09C7C4C06FCD407E0D9BB31E6FE 0x4447F0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 1409BB22E6F46809BB28E6FE2409BB1C 0x444800: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF E009E6F46A09BB21E6FC8B13F0D066FD 0x444810: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FF3FF2FE02FEE00FDAE69C59E6FC5C09 0x444820: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF E6FD9103E6FE5809F0FDDAE5D8EC06F0 0x444830: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 500098809890DB00F0C8F2FD02FEE6FF 0x444840: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 9103DAC71685F08CCB00D7403600A8C4 0x444850: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF F0D8F2FE02FEDAC71E89008CF049DC45 0x444860: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF B9880881CB0046FE23003DE5E6FEE025 0x444870: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF D7600D00982E983E984E26F4D4075C44 0x444880: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 7034F156E004D7603600F6F46A09F6F4 0x444890: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 6809F6F274090D0FDAE5DA25D7403200 0x4448A0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF F3F8F00267F840003D17E01CD7403600 0x4448B0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 04FC68090D00E00F88F088F088F0E6FC 0x4448C0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 5A0088C0E6FCC613E6FD6809E6FE3600 0x4448D0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF DAC2922F06F00800DB00E014D7403600 0x4448E0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 04F46A09DAE5CEDD0DE6F04E46FE1000 0x4448F0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 3DF3E6FC3409E6FD9103E6FE5409F0FD 0x444900: FFFFFFFF FAE5CEDD ;This is the last_reset text: 0x444904: FFFFFFFFFFFFFFFFFFFFFFFF 4C6173742072657365743A0D 0x444910: FFFFFFFF 00000000 ;This is the Received text: 0x444914: FFFFFFFFFFFFFFFFFFFFFFFF 52656365697665643A200000 0x444920: FFFFFFFF 00000000 ;This is the Sent text: 0x444924: FFFFFFFFFFFFFFFFFFFFFFFF 53656E743A20000000000000 0x444930: FFFFFFFF 00000000 0x444934: FFFFFFFFFFFFFFFFFFFFFFFF 03000000020030750000FF7F 0x444940: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 000000006648E400000000005A2CE202 0x444950: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 264E0200E000FF7F8B13FF7F00400000 0x444960: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 220000000000530400000000EA48E400 0x444970: FFFFFFFFFFFFFFFFFFFFFFFF 000000002A17E30200000000 ;~~~~~~~~~~~~~~~~~ rizapn Last edited by rizapn; 08-27-2004 at 00:30.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Nokia 6270 having date stamping error in sms when receive sms	hooi76	Nokia Base Band 5 ( BB-5 )	2	06-24-2007 15:13
SMS Counter for SL45i	rc-flitzer	Siemens-Benq Flash Patching	7	07-02-2004 22:37
SMS counter?	deemaa	Java, iOS, Android, Symbian development	0	05-03-2004 21:29
Sms counter & Smartmovie	spa803	Programs Keys & H/W finger prints	2	03-02-2004 06:09
sms counter?	sianzism	Java, iOS, Android, Symbian development	0	06-02-2003 06:13

08-25-2004, 20:40	#2 (permalink)
koper Crazy Poster Join Date: May 2004 Location: Wloclawek;Poland Age: 38 Posts: 54 Member: 66558 Status: Offline Thanks Meter: 0	I have the same problem, and I'm using version 3.X... greetings

08-25-2004, 21:03	#3 (permalink)
yiourkas Freak Poster Join Date: Oct 2003 Posts: 167 Member: 41707 Status: Offline Thanks Meter: 1	Actually the number i get is a little below 50000 (i.e. 49935 or 49960) I think the problem is that some other procedure writes to that specific eeprom block. Also keep in note that if your mobile hang for any reason or run out of battery, then the values in eeprom are restored to the values of the last successfull shutdown of your mobile...

08-25-2004, 21:27	#4 (permalink)
cyperghost No Life Poster Join Date: Oct 2003 Posts: 705 Member: 42457 Status: Offline Thanks Meter: 1	That's the question I also want to answer Is the number of that error is a fix one or not. I only know it's round about 50000. Maybe I or someone other can made a exact counting of that. If the number is fix we can solve it. If not well than not. Well first I want to write I can't agree your argument that annother process uses the same eep content.... [-=EDIT =-]but if I'm thinking over I just agree with you! Why? The problem was never reported in version 1.x of that Patch. Why was that possible, because the data was written during a normal shutdown of the phone, that means if there was annother data in this place, during shutdown, the old (the 50000+ counter) was overwritten by the actuelly used counter..... I must say I'm not sure about this but it sounds good and resolveable Maybe we can swap the counter to annother location?

08-25-2004, 22:57	#5 (permalink)
lalo.lerry No Life Poster Join Date: Jan 2004 Location: Italy Age: 49 Posts: 1,018 Member: 50673 Status: Offline Thanks Meter: 2	I also think it's a eeprom location conflict. So I take this occasion and ask: How can we understand if a eeprom block is really not used by phone (exept of course FFs)? And a RAM location? (post answer here or in technical thread)

08-25-2004, 23:50	#6 (permalink)
rizapn No Life Poster Join Date: Mar 2002 Location: -[r0]- Age: 53 Posts: 834 Member: 9891 Status: Offline Thanks Meter: 2	/ Agree with yiourkas. Maybe, relocating the RAM/EEPROM address will solve this strange problem. I'll try it ... / About EEPROM. I think, the best way is create a new (a real free) EEPROM block to save our own data (just like what I did in the Password Access patch). */ About Free RAM? I dunno. I use AT+CGSN to check their values, if there are many 00 or FF, then I think that RAM is never used (but it is probably use by other function in the phone which never executed by me before dumping it). rizapn

08-26-2004, 07:29	#7 (permalink)
cyperghost No Life Poster Join Date: Oct 2003 Posts: 705 Member: 42457 Status: Offline Thanks Meter: 1	@riza The strange thing is, that nobody knows when this error occours (If somebody knows please write your opinion here - don't be afraid, we don't bite!) Some content of the EEP I really don't understand, sometimes, I can read my announcments (birthdays, meetings...) two times - the same with the user DB of the t9.

08-26-2004, 09:19	#8 (permalink)
trustkill No Life Poster Join Date: May 2003 Location: GERMANY Age: 49 Posts: 980 Member: 27745 Status: Offline Thanks Meter: 0	I have received 50265 SMS Sometimes after online flashing (I know I should not do this ) the phone crashes. After that the received SMS are about 50xxxx. It´s not a fixed number. Why don´t we write the numbers in a .log file, there is no conflict with ram

08-26-2004, 09:28	#9 (permalink)
rizapn No Life Poster Join Date: Mar 2002 Location: -[r0]- Age: 53 Posts: 834 Member: 9891 Status: Offline Thanks Meter: 2	@trustkill: hehehe, writing something to the file is a last choice I think. Why? because the known "save" procedure to do write file is not really save (do you remember that you ever lose your Addressbook caused by file access patch?) ...

08-26-2004, 12:51	#11 (permalink)
cyperghost No Life Poster Join Date: Oct 2003 Posts: 705 Member: 42457 Status: Offline Thanks Meter: 1	Okay, I'm your man Thanks

08-26-2004, 15:21	#12 (permalink)
rizapn No Life Poster Join Date: Mar 2002 Location: -[r0]- Age: 53 Posts: 834 Member: 9891 Status: Offline Thanks Meter: 2	I do some patches recheck, and found that BCI is also possible to create that problem. There is something "strange" in the BCI patch about saving the Charge info data into the EEPROM. I try to modify the BCI patch also, and here is the result: (Please try to apply this if you still have problem after applying the modified SCI patch with the ones published by me in the previous posting) ... ;~~~~~~~~~~~~~~~~ ;* BCI. Battery Charge Info * ;Firmware : sl45v56 ;Author : rizapn ;Created : August 7, 2004 ;Updated : Aug 26, 2004 ;Record the last charging info (date w/o year, time, and voltage) ;into the EEPROM. 0x454A52: DAB9A49A DAE4804E 0x444E80: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF DAB9A49A4845FD418840D7403400F3F8 0x444E90: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 2C3EE6FCDC25D7700D00981C982C983C 0x444EA0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 985CF1924198ED0207F93C0021984995 0x444EB0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 8D2BD7403400F7F22C3ED7400E00F2F4 0x444EC0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF E23926F4480D7C447C215C617182C031 0x444ED0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 5C2270125C7570155CB37013E6FD7909 0x444EE0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF E6FE3600DC5E898D881DE6FD6809E00F 0x444EF0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 88F088F088F0E6FC5A0088C0E6FCC613 0x444F00: FFFFFFFFFFFFFFFFFFFFFFFF DAC2922F06F008009840DB00 ;~~~~~~~~~~~~~~~~~~~~ rizapn

08-26-2004, 16:22	#13 (permalink)
Maciek_K Junior Member Join Date: May 2004 Location: Poland Age: 45 Posts: 18 Member: 66044 Status: Offline Thanks Meter: 0	Hey Riza. I think, you forgot to paste these two lines in the SCI patch: 0x18A8E2: DEFFEB00 B047E400 0x18A956: 2801AB02 53045304 In my opinion the 50xxx error occurs because this place in memory is used by the phone. I remember, when I first time loaded this patch (version that saves data to eeprom) there was this number in incoming 50xxx, right after loading this patch, so this place in my eeprom wasn’t clean. Greetings.

08-26-2004, 17:03	#14 (permalink)
cyperghost No Life Poster Join Date: Oct 2003 Posts: 705 Member: 42457 Status: Offline Thanks Meter: 1	No k-mac! It could be that the old data was filled with FFFFFFFFFFFFFFFFFFF blocks

08-26-2004, 20:00	#15 (permalink)
trustkill No Life Poster Join Date: May 2003 Location: GERMANY Age: 49 Posts: 980 Member: 27745 Status: Offline Thanks Meter: 0	ääähm, riza ? I just did undo the sci v4.1 and applied the new version you post above. There is no more any SMS-Report instead of help....