Page 1 of 3 123 LastLast
Results 1 to 20 of 51
  1.    #1  
    I have had the problem reported by many that TomTom 5.12 does not retain the settings or the current route when leaving the application and returning.

    I've been able to remedy the problem on my Treo. I had made the mistake of launching TT off of the SD card in the beginning. I won't post the details now, but I've submitted a bug to TomTom and it has to do with retaining filename case between files on the SD card and the Palm's internal memory. However, the only solution I've found requires you to lose any settings you might have been able to save.

    Anyway, the solution is to do the following:
    - Make sure start.prc and/or cn.prc are in main memory
    - Delete start.prc and cn.prc from your SD card's /Palm/Launcher folder if you have copies there.
    - Using FileZ or Resco Explorer locate all the files with a Creator of MniC in main memory
    - you'll see the start.prc and/or cn.prc as well as several .dat, .mac, and .cfg files (note how several are duplicates and only differ by the case of several letters - that is the root of the bug).
    - delete all the .mac, .cfg, and .dat files.
    - go back to your launcher, and launch TomTom from main memory. It will crash and reset your Treo. that's alright.
    - when the Treo has rebooted, try and run TomTom from main memory again. This time, it should not crash. You ought to be able to make changes, plan routes, etc. and have any of those changes retained when you leave TomTom and then relaunch it.

    I recommend that you never launch TomTom from the SD Card. That seems to mess things up.

    Conrad

    keywords: TomTom 5.12 retains retaining saves loses settings routes route
  2.    #2  
    I discovered another bug in 5.12. Whenever Navigator is launched, it increases the files lock count (you can inspect this attribute in Resco explorer, possibly in FileZ). Eventually the file becomes "over-locked" and the Treo resets.

    I believe the problem described in the first post is also minimized by _not_ locking Navigator with Resco Locker.
  3. #3  
    I have not had either of these problems even running the app from SD, but I believe you. I even now have TomTom on my SD with Zlauncher. Works great. Even when calls come in. I bounce the fone app ad back again. What I really like is I still have 10 MG of ram left with 50+ apps and games because I found out TomTom will not run with only 5.5 free.

    Derek
  4. #4  
    Quote Originally Posted by computerfixitguy
    I have not had either of these problems even running the app from SD, but I believe you.
    I don't have the problems either. Might be because I never had a version earlier than 5.12 - I seem to remember reading somewhere that the duplicates bug doesn't appear in this circumstance.

    Quote Originally Posted by computerfixitguy
    I even now have TomTom on my SD with Zlauncher. Works great. Even when calls come in. I bounce the fone app ad back again. What I really like is I still have 10 MG of ram left with 50+ apps and games because I found out TomTom will not run with only 5.5 free.
    If you install as directed by TomTom you get the app and seven other files in device memory. The app (start.prc) is only 59 k and the other files total only about 30 k. Is it really worth moving this to the SD?

    I bought TTN5 together with the TomTom MkII bluetooth GPS receiver three weeks ago. So far the hardware and the application have behaved flawlessly. The only thing I'd like to see is updated GB maps; thus far they haven't caused me any problems and missing features (for instance two roundabouts on the A11) have been an annoyance rather than a hinderance, but it's not hard to imagine that a dated map could cause real inconvenience.
    Last edited by marcol; 10/25/2005 at 05:39 AM.
  5.    #5  
    I haven't tried moving TT to the SD card via a transfer-when-run utility like ZLauncher, PowerRun, Initiate, etc. I simply copied the prc to the /Palm/Launcher directory via the builtin application launcher. Also, I have only used 5.12 as well - I never installed any earlier versions. I have been able to duplicate the bug repeatedly, and reliably. BTW, if you'd like to see for yourself, try deleting all the TomTom config files (after making a backup first), then launch TT again. After the second launch, you ought to end up with the same duplicate files. I'm a little curious if a transfer-when-run utility alleviates this problem, so I'll experiment some tonight.

    The lock count bug is easy to reproduce. Try launching and exiting TT 15 times. By the 15th time or sooner, it will reset from the "chunk over-locked" error. I drove several hours with TT and after a few calls coming in, and my re-launching TT likewise several times, I had this reset. I suppose it doesn't affect a lot of people, but I just wanted to make sure the info was out there for a couple of people it might impact.
  6. #6  
    Edit: deleted post
  7. #7  
    Quote Originally Posted by Conrad
    I haven't tried moving TT to the SD card via a transfer-when-run utility like ZLauncher, PowerRun, Initiate, etc. I simply copied the prc to the /Palm/Launcher directory via the builtin application launcher. Also, I have only used 5.12 as well - I never installed any earlier versions. I have been able to duplicate the bug repeatedly, and reliably. BTW, if you'd like to see for yourself, try deleting all the TomTom config files (after making a backup first), then launch TT again. After the second launch, you ought to end up with the same duplicate files. I'm a little curious if a transfer-when-run utility alleviates this problem, so I'll experiment some tonight.
    You're correct in that I get two pairs (great_britian-24A02C86.mac and great_britian-24a02c86.mac and CurrentMap.dat and currentmap.dat) but these duplicates were there before I deleted the config files and, as I said above, I've had no problems with TTN retaining any settings or retaining the current route. Are these the duplicates you're seeing? How do you know the duplicates are the cause of the forgetfulness problem?

    Quote Originally Posted by Conrad
    The lock count bug is easy to reproduce. Try launching and exiting TT 15 times. By the 15th time or sooner, it will reset from the "chunk over-locked" error. I drove several hours with TT and after a few calls coming in, and my re-launching TT likewise several times, I had this reset. I suppose it doesn't affect a lot of people, but I just wanted to make sure the info was out there for a couple of people it might impact.
    Yep. Crashed on the 15th launch: 'MemoryMgr.c, Line:2659, Chunk over-locked'. Never had a problem in normal use though and I've defininately launched Navigator more than 15 times! Is the lock count reset by other things (Hotsyncing?)
  8. #8  
    Quote Originally Posted by marcol
    Yep. Crashed on the 15th launch: 'MemoryMgr.c, Line:2659, Chunk over-locked'. Never had a problem in normal use though and I've defininately launched Navigator more than 15 times! Is the lock count reset by other things (Hotsyncing?)
    I checked. Lock count isn't reset by Hotsync.

    I've contacted TomTom and asked them to fix this bug.
  9. #9  
    After I upgraded to FQ 1.17 on CIngular I restored from Hotsync backup and everything was working great. Until I started to notice TomTOm not retaining routes. I tried the workaround and only one file keeps being duplicated currentmap.dat and CurrentMap.dat, but the settings are retained.

    I am experienceing another issue though running TomTom 5.12. When I receive a phone call and answer it TomTom starts up again but doesn't immediately see my GlobalSat BT-380 bluetooth GPS receiver. It takes about 20-30 seconds and then the BT screen pops up asking me to select a BT device. Any ideas how to fix this?
  10. #10  
    Quote Originally Posted by marcol
    Yep. Crashed on the 15th launch: 'MemoryMgr.c, Line:2659, Chunk over-locked'. Never had a problem in normal use though and I've defininately launched Navigator more than 15 times! Is the lock count reset by other things (Hotsyncing?)
    That error isn't good. See these threads:
    http://discussion.treocentral.com/sh...ht=Line%3A2659
    http://discussion.treocentral.com/sh...ht=Line%3A2659
  11. #11  
    Quote Originally Posted by MarkY
    Thanks for the links. They're a bit worrying but I'm not sure that the problems are the same even though the error messages are. The resets we've discussed in this thread can't be described as random or spontaneous. They occur in one very specific circumstance: the 15th launch of TomTom Navigator 5.

    I'm no expert in this (I'm indebted to Conrad and his posts in this thread for much of the little knowledge I have), but as best I can understand it, whenever TTN5 is opened it locks one or more memory chunks and increments the lock count by one. I think this is normal behaviour. When it closes, however, the lock count is not decremented as should be. Thus each time the TTN5 is opened the lock count is increased by one. Palm OS allows the lock count to reach 14 before an error is returned. See:

    http://www.palmos.com/dev/support/do...ry.html#993231

    You can examine the TTN5 lock count and see that it increases by one with each launch using RescoExplorer 2.52:

    http://www.resco.net/palm/explorer/default.asp

    Using Resco to examine the lock count completely conviced me that the problem occurs on the 15th launch of TTN5. Never happens on launches 1-14, never makes 16.

    I've contacted TomTom about this and it's with their test team; they say "We shall get back to you when we have some feedback... Sorry no time scale at this time".

    FWIW, my device (unlocked GSM Firmware 01.28, Software 1.13, Hardware A) generally seems pretty stable. I get the occassional crash, perhaps one every week or two. According to the System Error Log the last one was 17/11/05 while running Xiino "Emul68KMain.c Line403, illegal instruction 7920 at address 7315DAB6". I can live with this level of instability (but obviously it would be better if it never crashed). I appreciate the heads-up though and I'll keep an eye on my device for any appearance of the over-lock error in any other circumstance.

    Has anyone with the "MemoryMgr.c, Line:2659, Chunk over-locked" error in the threads you linked to looked at lock counts?
  12. #12  
    Quote Originally Posted by marcol
    Has anyone with the "MemoryMgr.c, Line:2659, Chunk over-locked" error in the threads you linked to looked at lock counts?
    In pretty much every case from those threads, the MemoryMgr error happens even when the Treo has been hard reset (returned to factory defaults), although it takes a bit of waiting to see it happen.

    In my case, I could return it to factory default and just leave it on the table for 30-minutes and it would spontaneously reset. Palm and Sprint put up no argument that it was a hardware problem. In fact, I restored my new unit in the parking lot of the Sprint store with a BackupMan backup I made prior to going into the store and have not had the error repeat in almost 2 months now. My usage has stayed the same and the only change has been the Treo itself. Clearly it's a hardware problem as it relates to that specific MemoryMgr error.
  13. #13  
    Quote Originally Posted by MarkY
    In pretty much every case from those threads, the MemoryMgr error happens even when the Treo has been hard reset (returned to factory defaults), although it takes a bit of waiting to see it happen.
    .
    .
    .
    My usage has stayed the same and the only change has been the Treo itself. Clearly it's a hardware problem as it relates to that specific MemoryMgr error.
    I can't find any specific reference to the "MemoryMgr.c, Line:2659, Chunk over-locked" error on the palmsource site. This is what they say about the Memory manager:

    "The Palm OS Memory Manager is responsible for maintaining the location and size of every memory chunk in the dynamic heaps. It provides an API for allocating new chunks, disposing of chunks, resizing chunks, locking and unlocking chunks, and compacting heaps when they become fragmented."

    and this is what they say about locking data chunks:

    "Chunks maintain a lock count. A count of zero indicates that the chunk is movable. Every time you lock a chunk, its lock count is incremented. You can lock a chunk a maximum of 14 times before an error is returned. (Unmovable chunks hold the value 15 in the lock field.) Unlocking a chunk decrements the value of the lock field by 1. When the lock count is reduced to 0, the chunk is again free to be moved by the operating system."

    http://www.palmos.com/dev/support/do...ry.html#993734

    Again with caveat that I have no expertise in this, it seems reasonable to suppose that a "Chunk over-locked" error refers to a situation when the lock count exceeds the maximum allowed by the OS (i.e. 14). The question is, is this due to faulty hardware (the RAM chip), due to faulty software (not decrementing the lock count value), or can it be due to either faulty hardware or faulty software? Obviously I don't know the answer to this and it would be really great if someone with a lot more knowledge than me could chime in at this point. I do agree with you, MarkY, that your experience points to a hardware error, but equally I think mine points to a software error. It is quite possible I suppose that TTN5 could be exposing an underlying hardware fault (RAM faulty in such a way that data chunks become unlockable? - but if this is so why do I only ever see the "Chunk over-locked" error with TTN5?). I suppose also that the fact a hard reset doesn't cure the problem you saw doesn't conclusively prove that it's a hardware problem - perhaps the compressed ROM image containing the OS had been corrupted? - note that at least one user with the MMNotify error says this has been fixed with a ROM update:

    http://discussion.treocentral.com/sh...0&page=7&pp=20

    (evildead, post 122).

    Anyway, I've reached way beyond myself with this debate (in mitigation, I really do want to know what's going on here and I'm just trying my best to do that!) and will finish by saying I'm glad, MarkY, that your new device is working well for you (and I hope mine continues to be stable too).
  14. jorang's Avatar
    Posts
    318 Posts
    Global Posts
    377 Global Posts
    #14  
    JoranG
    Treo650 Unlocked GSM (Cust ROM 1.71/1.20 ENA w/ FAT32.prc) - TomTom Navigator v5 (Western Europe Maps)
  15. #15  
    Quote Originally Posted by jorang
    Interesting that this update does not yet appear if you log on to US version support site. Also, the imbedded link goes to information about the European version of Navigator 5. This could be just another instance of Tomtom shorfall in keeping their support site up to date but I wonder if there are significant differences in the US and European versions other than the maps.
  16. #16  
    Anybody in U.S try 5.20 yet?
  17. qwalls's Avatar
    Posts
    162 Posts
    Global Posts
    168 Global Posts
    #17  
    I installed it, but haven't had much time to play with it other than making sure it still works and checking the version number.
  18. #18  
    Quote Originally Posted by qwalls
    I installed it, but haven't had much time to play with it other than making sure it still works and checking the version number.
    Were you udpating a US or European version of Navigator 5?
  19. #19  
    Just installed the update using Missing Sync 5.0.2 on a Mac. (Funny process employing the 'TomTom conduit'. The previous version I had (GB) came on an SD card. You chaps with the US version may have seen this conduit before, but it was new to me.) Installed ok but the conduit wasn't removed after the update had finished -- it didn't do anything on subsequent syncs so I just moved it to the Disabled Conduits.

    Initial observations (very preliminary, I haven't even had the chance to use with the GPS unit yet!):

    1) Version is now 5.201 (5344)

    2) First attempt to launch Navigator failed with a 'Not enough dbcache memory' error. Never seen that before -- may be that the app has been made more NVFS aware.

    3) The lock count error is now gone! The 'start' application (which launches TTN5) no longer exhibits an increase in lock count with each launch. I've launched it multiple times (>20) and the lock count is still zero. There's no crash on the 15th launch and no "MemoryMgr.c, Line:2659, Chunk over-locked" error. Hurrah!

    MarkY, I think this pretty strongly indiicates that at least sometimes the "MemoryMgr.c, Line:2659, Chunk over-locked" error is a result of a software and not a hardware problem.

    4) When the app is launched and there's no GPS around it now says 'GPS signal was lost X sec ago' up until 20 seconds when the message switches to 'No GPS device!' (which is how it used to start). Seems that the connection software has been tweaked.

    jorang, thanks for posting the link.
  20. #20  
    Quote Originally Posted by marcol
    Initial observations (very preliminary, I haven't even had the chance to use with the GPS unit yet!):

    1) Version is now 5.201 (5344)
    Did you install 5.20 over 5.00 or over 5.12?

    Waiting for your feed back, but your seems to be good news!!!!

    What about Hotsync error? Probably with mac is different from Windows.

    Tx.
    Ciao.
    Vittore
    ------------------------------------------------------------------------------------------------------------------------------------
    HS Treo 180 -> HS Treo 270 -> Palm Treo 650 GSM (1.71-1.20ENA Custom) + Treo BT Headset + TomTom 5.201 & Holux GPS 236 BT Slim
Page 1 of 3 123 LastLast

Posting Permissions