Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

Hello,

I am building a list of issues that may “brick” BREW handsets, and would like everyone’s input. “Bricking” is a rough term used for destroying the internals a phone, to where the phone will not restart.

Apparently, this can occur when the protected memory space is inadvertently overwritten. In the VX-4400, for example, this “can” happen when: 1) the EFS is filled to 100%, 2) the address book field size is exceeded, 3) entering a record into the address book, without a phone number, or 4) too many non-BREW SMS messages sent to the phone, with the power off.

Please contribute where you can. I am specifically looking for additional info on the: VX4400, VX6000, SCHA530, SCHA610, and CDM8600 phones.

Thanks,
Martin

Well, it would appear that filling the EFS to 100% on a Motorola T720 will do it also. Sigh.

Well, it would appear that filling the EFS to 100% on a Motorola T720 will do it also. Sigh.

saving a tone on T-720 with space in start of the file name cause the phones ringer interface to not show any other tones ... I am not sure of this, haven't got the nerve to try it again.
On certain phones the ringer manager will allow to save zero byte tones which then can't be deleted from the phone's ring tone configuration menus ... this happens on Vx10, VX4400 and t720.

saving a tone on T-720 with space in start of the file name cause the phones ringer interface to not show any other tones ... I am not sure of this, haven't got the nerve to try it again.
On certain phones the ringer manager will allow to save zero byte tones which then can't be deleted from the phone's ring tone configuration menus ... this happens on Vx10, VX4400 and t720.

I have been able to brick a Kyocera 3225, but I don't know how I did it. Couldn't exactly try it again, as the phone was out of commision afterward, and even qualcomm couldn't fix it when i sent it to them.
I think it might have had something to do with database manipulation, but I'm not at all sure.
The phone went into a reboot loop: when I turned it on, it would display a message, "dog.c 000625" and then reboot, and it never stopped rebooting. Does this message mean anything to anyone?

I have been able to brick a Kyocera 3225, but I don't know how I did it. Couldn't exactly try it again, as the phone was out of commision afterward, and even qualcomm couldn't fix it when i sent it to them.
I think it might have had something to do with database manipulation, but I'm not at all sure.
The phone went into a reboot loop: when I turned it on, it would display a message, "dog.c 000625" and then reboot, and it never stopped rebooting. Does this message mean anything to anyone?

dog.c is the watchdog thread for BREW - essentially it makes sure apps are responding and not hogging the phone (tight loops, etc) - sorta ironic that it took your phone out...
But I haven't heard it mentioned, I have bricked 3 A530 phones, I just have a knack for killing them.
Curt

dog.c is the watchdog thread for BREW - essentially it makes sure apps are responding and not hogging the phone (tight loops, etc) - sorta ironic that it took your phone out...
But I haven't heard it mentioned, I have bricked 3 A530 phones, I just have a knack for killing them.
Curt

I've found a new way to brick almost any phone. Hopefully by posting this I'll help keep some perfectly good handsets from ending up in a landfill site.
We set the Mif file to notify us if the following events occurred:
01001000 Mask:1
which I think is power on notification. We then had a small bug in our program which crashed the phone. As you can guess, every time the phone started, it called our app, and killed the phone. Curiously, the bug only appeared on some sets and not others which made it hard to find and the code ran perfectly on the emulator.
This technique claimed a Motorola C343, Samsung A530, Audiovox 8410 and a Kyocera KX414. Needless to say we got rid of the MIF setting for now.
Hope this helps.

I've found a new way to brick almost any phone. Hopefully by posting this I'll help keep some perfectly good handsets from ending up in a landfill site.
We set the Mif file to notify us if the following events occurred:
01001000 Mask:1
which I think is power on notification. We then had a small bug in our program which crashed the phone. As you can guess, every time the phone started, it called our app, and killed the phone. Curiously, the bug only appeared on some sets and not others which made it hard to find and the code ran perfectly on the emulator.
This technique claimed a Motorola C343, Samsung A530, Audiovox 8410 and a Kyocera KX414. Needless to say we got rid of the MIF setting for now.
Hope this helps.

I just bricked a t720 by loading a bad mod and then taking the battery out when it wouldn't reset by itself. Dunno if the bad mod did it, or if the battery removal did it.

I just bricked a t720 by loading a bad mod and then taking the battery out when it wouldn't reset by itself. Dunno if the bad mod did it, or if the battery removal did it.

I just "bricked" a Samsung A530. Apparently this happened by writing a file to disk and filling the file system. At least that's my guess based on what I've read above. At any rate, my phone is wrecked beyond recovery. It keeps trying to restart but will never boot. When I power it on, it presents the Welcome Screen and then after about 10-15 seconds, the screen goes black and the phone cycles back to the Welcome screen again, and on and on.
So, now that I'm in the club, does anyone know how to recover the phone? Is there a way to reset it somehow or is little more than a paper weight now? Any help in this matter is GREATLY appreciated.
Thanks.

I just "bricked" a Samsung A530. Apparently this happened by writing a file to disk and filling the file system. At least that's my guess based on what I've read above. At any rate, my phone is wrecked beyond recovery. It keeps trying to restart but will never boot. When I power it on, it presents the Welcome Screen and then after about 10-15 seconds, the screen goes black and the phone cycles back to the Welcome screen again, and on and on.
So, now that I'm in the club, does anyone know how to recover the phone? Is there a way to reset it somehow or is little more than a paper weight now? Any help in this matter is GREATLY appreciated.
Thanks.

Great. I've claimed the life of another device, an 8900. For this one, I really have no idea why it bricked. Using the AppLoader (v2.1.1.3) I tried to create a directory on the device, but the directory did not appear. Then I tried to load a module to the device, and the device resetted during the transfer, an error about being unable to write to the EFS appeared on the AppLoader and now the device is broken. My 8900 will no longer boot, instead it shows a verizon logo and then a white screen with the following black text "Please wait, User data is being restore....[7]." Then it reboots and performs the same behavior endlessly. Argh!
Is there anybody out there that can recommend a course of action to recover devices in this state? It seems that the local stores can't re-flash devices, and I sent a previously bricked unit to Qualcomm and they sent it back saying that the device was beyond their help. Thanks.

Great. I've claimed the life of another device, an 8900. For this one, I really have no idea why it bricked. Using the AppLoader (v2.1.1.3) I tried to create a directory on the device, but the directory did not appear. Then I tried to load a module to the device, and the device resetted during the transfer, an error about being unable to write to the EFS appeared on the AppLoader and now the device is broken. My 8900 will no longer boot, instead it shows a verizon logo and then a white screen with the following black text "Please wait, User data is being restore....[7]." Then it reboots and performs the same behavior endlessly. Argh!
Is there anybody out there that can recommend a course of action to recover devices in this state? It seems that the local stores can't re-flash devices, and I sent a previously bricked unit to Qualcomm and they sent it back saying that the device was beyond their help. Thanks.

I killed our VX6000 trying to perform a True BREW test
(Filling the EFS)
We returned the phone to the store where we purchased it and they gave us a new one no questions asked.

I killed our VX6000 trying to perform a True BREW test
(Filling the EFS)
We returned the phone to the store where we purchased it and they gave us a new one no questions asked.

Ok guys ! now, let me add myself to the club.... :) we just Briked a 4400 by the same EFS full test ! But the problem is I can't get back to US to replace my device.. is there a way to get the device back to normal ?? atleast to get it started and delete those files which was created at the test.
How come there is no reset or other way to retrive the phone back if Qualcomm knows that FILL EFS test could brick a phone ???
Please give us some pointers or solutions....

Ok guys ! now, let me add myself to the club.... :) we just Briked a 4400 by the same EFS full test ! But the problem is I can't get back to US to replace my device.. is there a way to get the device back to normal ?? atleast to get it started and delete those files which was created at the test.
How come there is no reset or other way to retrive the phone back if Qualcomm knows that FILL EFS test could brick a phone ???
Please give us some pointers or solutions....

maxfiles is a tool of satan, unless you have a lot of phones available theres better ways to do what it does.
loading too many applications can also kill a phone, around 20 or so with the LG6000

maxfiles is a tool of satan, unless you have a lot of phones available theres better ways to do what it does.
loading too many applications can also kill a phone, around 20 or so with the LG6000

Yesterday I was using the emulator to find a bug that occured on the handset while my app was trying to access the shared directory after filling it up and then removing one file with maxfilecnt.
I tried using the device file configurator to set the maxfile and maxsize properties for the device emulator files, but when this didn't work I set the MIF file maxfile and maxsize properties. This required me to set the MIF file type to 2.0.b ! When I debugged my app I loaded it back on the handset, BUT I forgot to change the MIF file type from 2.0.b to 2.0 !!! I believe this is what bricked the A610, because I had been loading my app onto the handset with the EFS full and nothing happen until I changed the MIF file type to 2.0.b.
Ivan

Yesterday I was using the emulator to find a bug that occured on the handset while my app was trying to access the shared directory after filling it up and then removing one file with maxfilecnt.
I tried using the device file configurator to set the maxfile and maxsize properties for the device emulator files, but when this didn't work I set the MIF file maxfile and maxsize properties. This required me to set the MIF file type to 2.0.b ! When I debugged my app I loaded it back on the handset, BUT I forgot to change the MIF file type from 2.0.b to 2.0 !!! I believe this is what bricked the A610, because I had been loading my app onto the handset with the EFS full and nothing happen until I changed the MIF file type to 2.0.b.
Ivan

kuehnt wrote:I've found a new way to brick almost any phone. Hopefully by posting this I'll help keep some perfectly good handsets from ending up in a landfill site.
We set the Mif file to notify us if the following events occurred:
01001000 Mask:1
which I think is power on notification. We then had a small bug in our program which crashed the phone. As you can guess, every time the phone started, it called our app, and killed the phone. Curiously, the bug only appeared on some sets and not others which made it hard to find and the code ran perfectly on the emulator.
This technique claimed a Motorola C343, Samsung A530, Audiovox 8410 and a Kyocera KX414. Needless to say we got rid of the MIF setting for now.
Hope this helps.
This works on the Nokia 3586i

kuehnt wrote:I've found a new way to brick almost any phone. Hopefully by posting this I'll help keep some perfectly good handsets from ending up in a landfill site.
We set the Mif file to notify us if the following events occurred:
01001000 Mask:1
which I think is power on notification. We then had a small bug in our program which crashed the phone. As you can guess, every time the phone started, it called our app, and killed the phone. Curiously, the bug only appeared on some sets and not others which made it hard to find and the code ran perfectly on the emulator.
This technique claimed a Motorola C343, Samsung A530, Audiovox 8410 and a Kyocera KX414. Needless to say we got rid of the MIF setting for now.
Hope this helps.
This works on the Nokia 3586i

and from simply doing a TrueSync Plus with Outlook. I've done it a dozen times without a problem. Anyone have any guess as to why? I can't be sure, but I don't think I was near the phone's memory limit.

and from simply doing a TrueSync Plus with Outlook. I've done it a dozen times without a problem. Anyone have any guess as to why? I can't be sure, but I don't think I was near the phone's memory limit.

Apparently I'm very good at bricking phones. In the last three months, I've bricked two phones and screwed up a third. Unfortunately, I don't have the circumstances to an exact science and I'm not going to brick more phones just to prove it.
Here are some of the ways I've managed to do it:
1) I connected our SCH-A670 to my computer via a data cable through a Belkin USB hub. The phone was powered off and wouldn't power up. When I tried to charge it (thinking it was out of juice), the battery got very hot.
2) This one didn't become a brick but was very odd. I was testing on a VX6100 and had filled up the file system using Maxfilecnt. I attempted to run a demo app and accidentally selected the "Buy Now" option from the GIN menu. I pressed CLR to cancel that action, returned to the GIN menu and selected another app. The phone suddenly reset itself and wiped all apps from the EFS. I checked the debug menus and noticed that test enabling was off. Other than that the phone was fine.
3) I was testing a BREW app on our LG VX7000 and I noticed that when pressing "#" several times (theoretically '###' activates BREW debug mode), closing the clamshell, reopening the clamshell and re-entering Get-It-Now caused the handset to reset. I was trying to determine if this was a Get-It-Now/BREW specific problem or if it was specific to our application so I entered the Get-It-Now menu, opened Fun and Games, pressed # a few times. After that I'm not sure but I may have selected the Get-It-Now option accidentally and pressed pound a few more times while it was trying to connect to the internet. Anyway the screen went blank and displayed a message "Resetting EFS please wait" and the LCD screen started flashing slowly. I waited about 30 mins and the flashing never ceased, the handset was unresponsive to input. So I popped out the battery and put it back in after a minute and restarted the handset. It reported a message as it was starting "Factory Test Mode Enabled". After it had started up it displayed a message on the screen "FTM Mode" and nothing worked (e.g,. can't make phone calls, starting Get-It-Now causes the handset to reset, all contacts and messages are gone...). I checked in the debug menus and noticed that the software ESN number was all zeroes.

Apparently I'm very good at bricking phones. In the last three months, I've bricked two phones and screwed up a third. Unfortunately, I don't have the circumstances to an exact science and I'm not going to brick more phones just to prove it.
Here are some of the ways I've managed to do it:
1) I connected our SCH-A670 to my computer via a data cable through a Belkin USB hub. The phone was powered off and wouldn't power up. When I tried to charge it (thinking it was out of juice), the battery got very hot.
2) This one didn't become a brick but was very odd. I was testing on a VX6100 and had filled up the file system using Maxfilecnt. I attempted to run a demo app and accidentally selected the "Buy Now" option from the GIN menu. I pressed CLR to cancel that action, returned to the GIN menu and selected another app. The phone suddenly reset itself and wiped all apps from the EFS. I checked the debug menus and noticed that test enabling was off. Other than that the phone was fine.
3) I was testing a BREW app on our LG VX7000 and I noticed that when pressing "#" several times (theoretically '###' activates BREW debug mode), closing the clamshell, reopening the clamshell and re-entering Get-It-Now caused the handset to reset. I was trying to determine if this was a Get-It-Now/BREW specific problem or if it was specific to our application so I entered the Get-It-Now menu, opened Fun and Games, pressed # a few times. After that I'm not sure but I may have selected the Get-It-Now option accidentally and pressed pound a few more times while it was trying to connect to the internet. Anyway the screen went blank and displayed a message "Resetting EFS please wait" and the LCD screen started flashing slowly. I waited about 30 mins and the flashing never ceased, the handset was unresponsive to input. So I popped out the battery and put it back in after a minute and restarted the handset. It reported a message as it was starting "Factory Test Mode Enabled". After it had started up it displayed a message on the screen "FTM Mode" and nothing worked (e.g,. can't make phone calls, starting Get-It-Now causes the handset to reset, all contacts and messages are gone...). I checked in the debug menus and noticed that the software ESN number was all zeroes.

yeah its pretty easy FYI LG's don;t use ### for debug menu, they use 9 *'s

yeah its pretty easy FYI LG's don;t use ### for debug menu, they use 9 *'s

just bricked a Nokia 3589i.
I was loading apps onto it via Nokia PC suite (because I couldn't get Apploader to work). I turned it off then turned it back on again to get it to recognize the newly loaded apps, it booted up then as soon as it got to the main menu it rebooted itself. This repeated endlessly and happens so fast you can't do anything.
Possible contributing factors are that I may have had the USB cable connected to the handset and I may have had the handset connected to my computer via USB when power cycling it.

just bricked a Nokia 3589i.
I was loading apps onto it via Nokia PC suite (because I couldn't get Apploader to work). I turned it off then turned it back on again to get it to recognize the newly loaded apps, it booted up then as soon as it got to the main menu it rebooted itself. This repeated endlessly and happens so fast you can't do anything.
Possible contributing factors are that I may have had the USB cable connected to the handset and I may have had the handset connected to my computer via USB when power cycling it.

Many of phones have layed slain to this util. We have failed NSTL for maxfilecnt2 issue, however we only used the util on a few phones because of the destructive nature. Can someone explain to us how to get a full mem situation without 'bricking' a phone?
Thanks

Many of phones have layed slain to this util. We have failed NSTL for maxfilecnt2 issue, however we only used the util on a few phones because of the destructive nature. Can someone explain to us how to get a full mem situation without 'bricking' a phone?
Thanks

override the file handling code to force errors instead of actually filling the filesystem

override the file handling code to force errors instead of actually filling the filesystem

Is there maybe some sample code that would help out with this? I'm attempting NOT to brick any more phones as we're late on submitting the KX2 to NSTL as is.
Thanks in advance,
Jon

Is there maybe some sample code that would help out with this? I'm attempting NOT to brick any more phones as we're late on submitting the KX2 to NSTL as is.
Thanks in advance,
Jon

not that i'm aware of, but its trivial to do, all you do is wrap the file
handling calls with your own wrapper that either randomly or always makes the call fail to do what its supposed to, so say using a c lib function fopen
FILE*fopen(const char *name,const char*mode)
{
if( rand() ) return NULL;
return call_real_fopen(name,mode);

something like that

not that i'm aware of, but its trivial to do, all you do is wrap the file
handling calls with your own wrapper that either randomly or always makes the call fail to do what its supposed to, so say using a c lib function fopen
FILE*fopen(const char *name,const char*mode)
{
if( rand() ) return NULL;
return call_real_fopen(name,mode);

something like that

We've been through quite a few phones here and wondering if there's any way to de-brick a phone? My assumption is, no, but its worth a try.

We've been through quite a few phones here and wondering if there's any way to de-brick a phone? My assumption is, no, but its worth a try.

usually you either need a bmd, jtag or the test harness if it won't talk at all, then you reset the flash.
if it will stil talk theres software available to reflash the phones, but its usually only properly available from verizon or qualcomm etc

usually you either need a bmd, jtag or the test harness if it won't talk at all, then you reset the flash.
if it will stil talk theres software available to reflash the phones, but its usually only properly available from verizon or qualcomm etc

Hey...
I just bought the new LG VX-8100 yesterday. I was messing with the phone... I went to menu, pressed 0, and then 000000. I don't remember what I did, but I set the phone on "FTM Mode." I had to reset my entire phone to get it off. Does anyone know what that is or what I did? Maybe you could email me...
eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%67%6f%76%62%72%69%74%6e%69%40%79%61%68%6f%6f%2e%63%6f%6d%22%20%63%6c%61%73%73%3d%22%62%62%2d%65%6d%61%69%6c%22%3e%67%6f%76%62%72%69%74%6e%69%40%79%61%68%6f%6f%2e%63%6f%6d%3c%2f%61%3e%27%29%3b'))
Thanks so much!
-Britni

Hey...
I just bought the new LG VX-8100 yesterday. I was messing with the phone... I went to menu, pressed 0, and then 000000. I don't remember what I did, but I set the phone on "FTM Mode." I had to reset my entire phone to get it off. Does anyone know what that is or what I did? Maybe you could email me...
eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%67%6f%76%62%72%69%74%6e%69%40%79%61%68%6f%6f%2e%63%6f%6d%22%20%63%6c%61%73%73%3d%22%62%62%2d%65%6d%61%69%6c%22%3e%67%6f%76%62%72%69%74%6e%69%40%79%61%68%6f%6f%2e%63%6f%6d%3c%2f%61%3e%27%29%3b'))
Thanks so much!
-Britni

FTM = factory test mode
you can easily brick/"render worthless" your phone playing around in that mode.
you put your phone in test mode, thats it, try a few other combinations, a couple of them will cause you to break FCC rules , and i believe its a felony offense, then there is the 'reset phone back to factory state, which will render it into a paperweight.
who knows you might get lucky ;) if it still works , then just leave it be.

FTM = factory test mode
you can easily brick/"render worthless" your phone playing around in that mode.
you put your phone in test mode, thats it, try a few other combinations, a couple of them will cause you to break FCC rules , and i believe its a felony offense, then there is the 'reset phone back to factory state, which will render it into a paperweight.
who knows you might get lucky ;) if it still works , then just leave it be.

This utility has claimed many handsets and continues its deadly reign on unsuspecting tester victims. Who will stand and save all these handsets?
But seriously, are there any places to get these phones resurrected? and secondly, how about test strategies that do not use the MaxFileCnt2 utility?

This utility has claimed many handsets and continues its deadly reign on unsuspecting tester victims. Who will stand and save all these handsets?
But seriously, are there any places to get these phones resurrected? and secondly, how about test strategies that do not use the MaxFileCnt2 utility?

bricked phone = send to qualcomm for a reflash
avoid maxfiles = override file handling code and induce errors programmatically

bricked phone = send to qualcomm for a reflash
avoid maxfiles = override file handling code and induce errors programmatically

If your phone is totally bricked, then sending it into Qualcomm won't accomplish anything. I've sent bricked phones to them only to have them returned with a note saying that there was nothing they could do.

If your phone is totally bricked, then sending it into Qualcomm won't accomplish anything. I've sent bricked phones to them only to have them returned with a note saying that there was nothing they could do.

sometimes they can,, i just got one back that they fixed. depends if they have access to the right hardware for the phone, as well as willingness to fix.
not sending it, means they definetely can't fix it

sometimes they can,, i just got one back that they fixed. depends if they have access to the right hardware for the phone, as well as willingness to fix.
not sending it, means they definetely can't fix it

That's interesting...I was told (by QIS) that a bricked phone is unrecoverable. The fact that they can get some of them back is good. What handset did they fix and was it the typical "continuous reboot" behavior.
If qualcomm can fix some of them then I have a few that I will send to them.
Cheers...TK

That's interesting...I was told (by QIS) that a bricked phone is unrecoverable. The fact that they can get some of them back is good. What handset did they fix and was it the typical "continuous reboot" behavior.
If qualcomm can fix some of them then I have a few that I will send to them.
Cheers...TK

lg 8000 with a corrupted flash

lg 8000 with a corrupted flash

At the risk of bricking a phone, does one still have to perform the MaxFileCnt test on phones that have proven to be constantly bricked (such as the Kyocera KX1 or KX2)? Is there another test that can be implemented that NSTL will accept?

At the risk of bricking a phone, does one still have to perform the MaxFileCnt test on phones that have proven to be constantly bricked (such as the Kyocera KX1 or KX2)? Is there another test that can be implemented that NSTL will accept?

Speaking of recoverable phones, I need to attempt a maxfile on a Kyocera KX160 and brick it. I was wondering if anyone is familiar with being able to recover this phone while in "sleep mode"/ aka powered on while charger is plugged.
I can't seem to remember if this was possible, and since I don't have the handset available right now, I can't try.
I do, however, remember being able to recover a bricked handset by accessing the files while the handset was plugged into the charger and deleting the maxfiles. I just can't recall if it was the KX160 or another handset.
We have been passing NSTL stating that the KX160 will brick when maxfiled until just recently - they insist that we can do maxfile testing on the KX160.

Speaking of recoverable phones, I need to attempt a maxfile on a Kyocera KX160 and brick it. I was wondering if anyone is familiar with being able to recover this phone while in "sleep mode"/ aka powered on while charger is plugged.
I can't seem to remember if this was possible, and since I don't have the handset available right now, I can't try.
I do, however, remember being able to recover a bricked handset by accessing the files while the handset was plugged into the charger and deleting the maxfiles. I just can't recall if it was the KX160 or another handset.
We have been passing NSTL stating that the KX160 will brick when maxfiled until just recently - they insist that we can do maxfile testing on the KX160.

In respose to the question about recovering the Kyocera KX160...
I don't think I have had to recover a KX160, but a lot of similar Kyocera phones (KX16, KX21, etc) can be recovered by just connecting them to apploader and deleting just one file (the mif file of your test application is easiest). Suprisingly, most Kyoceras seem to connect to apploader even if they are doing that funky repeated boot to the spash screen and reset thing. They'll even connect if the phone is just plain off in many cases (no charger needed).
I hope this random posting on an old-ish thread helps a few people.
Good Luck!

In respose to the question about recovering the Kyocera KX160...
I don't think I have had to recover a KX160, but a lot of similar Kyocera phones (KX16, KX21, etc) can be recovered by just connecting them to apploader and deleting just one file (the mif file of your test application is easiest). Suprisingly, most Kyoceras seem to connect to apploader even if they are doing that funky repeated boot to the spash screen and reset thing. They'll even connect if the phone is just plain off in many cases (no charger needed).
I hope this random posting on an old-ish thread helps a few people.
Good Luck!

I was able to recover a KX2 today in standby mode from MaxFile. Able to delete the files so that the phone could power up, but the EFS was still corrupted. It was reporting incorrect file size values. It's still being sent to QUALCOMM to be flashed, but at least we were able to recover it from the brick mode.
We don't have a KX160, so we aren't able to reproduce. But, when I worked with you, I seem to remember that we were able to recover it in standby mode.

I was able to recover a KX2 today in standby mode from MaxFile. Able to delete the files so that the phone could power up, but the EFS was still corrupted. It was reporting incorrect file size values. It's still being sent to QUALCOMM to be flashed, but at least we were able to recover it from the brick mode.
We don't have a KX160, so we aren't able to reproduce. But, when I worked with you, I seem to remember that we were able to recover it in standby mode.

Just managed to brick a Nokia 6315i, but was able to MaxFile full, run the application, and exit app. When attempting to run the app again, I hit the SEND key during our splash screens, the phone powercycled, and bricked in that "continuous reboot" mode.
Now, it doesn't power on at all. There's a new one to add to the list. Speaking of list, does anyone (or QUALCOMM) keep a list of phones that can be easily bricked to avoid accidentally bricking a phone?

Just managed to brick a Nokia 6315i, but was able to MaxFile full, run the application, and exit app. When attempting to run the app again, I hit the SEND key during our splash screens, the phone powercycled, and bricked in that "continuous reboot" mode.
Now, it doesn't power on at all. There's a new one to add to the list. Speaking of list, does anyone (or QUALCOMM) keep a list of phones that can be easily bricked to avoid accidentally bricking a phone?

Pretty much any of them, it'd be a shorter list of the ones you can't brick easily.
I'd suggest writing your own maxfiles or having the developer wrap the filesystem calls in a wrapper than can test the fail modes..

Pretty much any of them, it'd be a shorter list of the ones you can't brick easily.
I'd suggest writing your own maxfiles or having the developer wrap the filesystem calls in a wrapper than can test the fail modes..

I think I have just bricked my starcomm8945 by filling the system memory in the apploader and recycle handset power....
I get this white screen to appear saying
"Mc.c 01256 fs"

I think I have just bricked my starcomm8945 by filling the system memory in the apploader and recycle handset power....
I get this white screen to appear saying
"Mc.c 01256 fs"

Its sounds likely, just keep rebooting it and trying to connect apploader or qpst you might get lucky and get it connected, then start deleting.
Its worked in the past for me on some phones.

Its sounds likely, just keep rebooting it and trying to connect apploader or qpst you might get lucky and get it connected, then start deleting.
Its worked in the past for me on some phones.

motorola v325 here.
Tonight I loaded my own app and now the phone is in a continuous reboot loop.
This is my first "brick" experience. Is there nothing I can do to fix it? I need this phone. This has been a pretty disappointing experience.

motorola v325 here.
Tonight I loaded my own app and now the phone is in a continuous reboot loop.
This is my first "brick" experience. Is there nothing I can do to fix it? I need this phone. This has been a pretty disappointing experience.

same as before, keep trying to connect to it with apploader or pst, and delete the mif

same as before, keep trying to connect to it with apploader or pst, and delete the mif