GPS V memory upgrade
Matrix
20Mb of maps is about one third of what I currently need and the memory
limit makes me upload the same maps over and over again. So I've decided
to investigate what could be done to increase the flash size.
This is how a GPS V unit looks inside:
http://nic.ath.cx/GPSV/GPS1.jpg
http://nic.ath.cx/GPSV/GPS2.jpg
and these are the memory chips used:
AM29LV160BB-90 - 16 Mbits Flash (1Mx16) 3.3V
CY7C1041BV33-12 - 4 Mbits SRAM (256Kx16) 3.3V
TC58256 - NAND Flash (32Mx8) 3.3V (TSOP48)
The first flash holds the firmare for their 16 bit processor (ARM core)
and the third one holds the base map and the downloaded maps.
There are many other Flash NAND memory chips with 64M/128M/256M
capacities which are pin to pin compatible and command compatible.
The only difference between them is the address cycle. For the 32M
versions the data bus pulses 3 times to send A0-A7, A9-A16, A17-A24
For the bigger capacity versions a 4th cycle is needed to send A25-Ax.
The lower capacity NANDs ignore the 4th cycle address so all these
memories could use the same (4 cycle) address sending subroutine.
A 128M chip costs less than 100$ and increases the uploaded map
capacity more than 5 times. This will also increase your (serial
interface) transfer time to 4 hours but you'll only do it once.
To replace the chip one can use a hot air pen torch to remove
the old chip and solder the new TSOP48 package instead (half of
the pins are not-connected which makes soldering even easier).
Because I don't know the procedure of loading the basemap I plan
to read the old chip in a programmer and copy the file at the
beginning of the new chip.
This alone will not work if the firmware doesn't have provisions
to interogate the NAND ID and switch to a 4 cycle address routine.
In this case I can either ask Garmin to change this in their
firmware or I can read the other flash myself (to avoid agreeing not to
reverse engineer their firmware when downloading a firmware upgrade).
The firmware is not encrypted or compressed and can be easily
disassembled with IDA (interactive disassembler) switched to
ARM instruction codes. Then find the address build routine which
has the address passed as a 32bit value and generate a 4th cycle
from the MSB of the address.
Before proceeding with this experiment I'd like to know if
anyone ever tried this or has more information about this subject.
Robert Elsinga =8-)
>This is how a GPS V unit looks inside:
> http://nic.ath.cx/GPSV/GPS1.jpg
> http://nic.ath.cx/GPSV/GPS2.jpg
>and these are the memory chips used:
> AM29LV160BB-90 - 16 Mbits Flash (1Mx16) 3.3V
> CY7C1041BV33-12 - 4 Mbits SRAM (256Kx16) 3.3V
> TC58256 - NAND Flash (32Mx8) 3.3V (TSOP48)
>The first flash holds the firmare for their 16 bit processor (ARM core)
>and the third one holds the base map and the downloaded maps.
I never heard of anyone doing this, but I would very much like to know
if this worked or not! It would mean that I could buy a US GPS V cheap
and relash it with the Atlantic basemap, together with a nice large
memorychip. If I know it works, I wouldn't mind paying US$500,- for
this.
And; can I use the photo's and text for the GPS V FAQ (with source if
you like that)?
--
Robert Elsinga =8-) e-mail: robert (at) elsinga.org/elsinga.net
Personal website: www.elsinga.org, Home @ N 52"55.812', E 05"51.509'
Voice: +31 871 90 11 11 (EUR 0,41/min), fax2mail: +31 842 22 76 82
Matrix
> And; can I use the photo's and text for the GPS V FAQ (with source if
> you like that)?
You can do whatever you want with the text and images.
(I'm the type of guy who writes OSS software in his spare time.)
Robert Elsinga =8-)
>Robert Elsinga wrote:
>> And; can I use the photo's and text for the GPS V FAQ (with source if
>> you like that)?
>
>You can do whatever you want with the text and images.
Okay. Want any link to your email address on that page?
>(I'm the type of guy who writes OSS software in his spare time.)
The grease in the machine. =8-)
Thomas Lindberg
"Matrix" <e...@nic.ath.cx> wrote in message
news:slrnbj27...@flop.halnet...
consumer grade GPS, Garmin 45 if my memory serves as it should, there was
and project somewhere to remove this limit by reprogram the PROM. The
problem the guy encountered was a mechanical one: how to get the display to
work again. Then Garmin removed the 100kt limit and all his effort was in
vain.
Thomas
Dominic Sexton
<thomas.h...@telia.com> writes
>Way back in the bad old days when Garmin had a 100knots speed limit on the
>consumer grade GPS, Garmin 45 if my memory serves as it should, there was
>and project somewhere to remove this limit by reprogram the PROM. The
>problem the guy encountered was a mechanical one: how to get the display to
>work again.
Tim Hogard
http://web.abnormal.com/~thogard/gps/grmnhack.html
>Then Garmin removed the 100kt limit and all his effort was in
>vain.
Hardly - Tim didn't have to buy a new receiver he already had one
without the limit so I wouldn't say it was in vain.
--
Dominic Sexton
http://www.dscs.demon.co.uk/
David
want to do it to mine.
David
"Matrix" <e...@nic.ath.cx> wrote in message
news:slrnbj27...@flop.halnet...
Ken
GPS V... ;-)
Ken
Dongil Park, M.D.
At the first time, I used an English version of Korean city navigation map
installed in gpsv.
It had whole Korea in 19 Mb memory.
Of course the map was a little old fashioned to current raod status.
In the March, I sent my gpsv to Garmin and changed hardware to GPS V Korean
version.
It has 28Mb ram and Korean character display. Rom version is 2.00K.
In spite of memory expansion to 28 Mb, I can not put the latest map of
Korean City Navigator as a hole.
I must separate the small Korean peninsula into several segments to fit in
28 MB.
Sometime I eagered to open the box as Matrix did.
But I do not want to break the warranty period. So I am waiting to pass it.
And in some days, someone may help to expand memory enough to save whole
Korea in my gpsv.
Cheers, Matrix.
Dongil Park, M.D.
"Matrix" <e...@nic.ath.cx> wrote in message
news:slrnbj27...@flop.halnet...
Holger Issle
> I am very pleased with my GPS5 unit except one thing - the memory capacity.
> 20Mb of maps is about one third of what I currently need and the memory
> limit makes me upload the same maps over and over again. So I've decided
> to investigate what could be done to increase the flash size.
Just one question: How do you think you could reseal the package to
keep it real waterproof? I use my MAP76S on the motorbike even in
rain, would love to have 128MB, but it really needs to be waterproof
to IPX7 and still float.
--
Ciao,
Holger (GUS-KOTAL, GUS#1100)
90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm
95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 50 Mm (Die Renndrecksau!)
cu @ http://www.issle.de
Peter
> On Wed, 06 Aug 2003 15:23:05 GMT, Matrix <e...@nic.ath.cx> wrote:
>
>
>>I am very pleased with my GPS5 unit except one thing - the memory capacity.
>>20Mb of maps is about one third of what I currently need and the memory
>>limit makes me upload the same maps over and over again. So I've decided
>>to investigate what could be done to increase the flash size.
>
>
> Just one question: How do you think you could reseal the package to
> keep it real waterproof? I use my MAP76S on the motorbike even in
> rain, would love to have 128MB, but it really needs to be waterproof
> to IPX7 and still float.
I believe the V uses the same case as my III+ - that unit comes apart eaily
by removing the screws and without any damage to the rubber-like seal
between the two halves of the case. Putting it back together again should
restore the waterproofness as long as you properly tighten the screws to
lightly compress the seal. Of course this unit doesn't float so if you
need that you'll need to attach some foam to the back.
For other designs there isn't any incompatibility between waterproofness
and larger memory sizes. Both the Street Pilot series and the Meridian
series include removable, large-capacity memory cards and meet the same
IPX7 specification as the 76S and V. Making them float is just a matter of
making the case large enough so the overall density is less than water.
Matrix
> It has 28Mb ram and Korean character display. Rom version is 2.00K.
> In spite of memory expansion to 28 Mb, I can not put the latest map of
> Korean City Navigator as a hole.
Your "expansion" is in fact just a smaller basemap. The whole NAND memory is
32MB and you will never be able to go above that value.
This upgrade bussiness could be hard or easy depending on how Garmin wants to
play it. If they are in favour of this upgrade they might add the small change
in their next firmare release (or it might already be there, I haven't checked
yet). If they would like to force you to buy their next shiny new color GPS
with lots of memory they won't support this hack.
From the hardware point of view I'm pretty sure that the only necessary
modification is changing the NAND chip but this new chip has to have firmware
support. For Garmin who has the sources this change will be probably half an
hour of work if it's not already there. For me it will be a few days of work
and it won't be portable.
Because I will be obliged to work directly on the binary I will have to
disasemble it (not an easy process) and change two things: the address
generation routine and the ROM checksum. Because my modified routine will be
slightly bigger I will have to relocate it to some free space and then modify
all the calling addresses to point to the new location. Once I've done this I
will have to take care of the integrity verification routine and compute the
new image checksum and store it in place of the old checksum.
I have no problem to do these mods because I have access to all the equipment I
need. I will work directly on the firmware image stored in flash and program it
in a programmer. I might even replace the firmware chip with a socket or use a
ROM emulator while I try different images. For the other people though extra
work will be needed to map the flash content to the .rgn files from their
upgrades. Those files might have a header and extra checksums and probably a
load start address in the flash.
The flash upgrade procedure through the serial interface is performed in two
possible ways: 1) either they have a protected boot region in the flash where
the bootloader is and that region never gets erased therefore the firmware is
loaded above that address 2) they load the bootloader in RAM and flash the
whole chip. Method 2 has the disadvantage that if something goes wrong during
the upgrade you end up with a GPS which needs service.
Today I'll just solder a few wires and hook up the ALE, /WE and CLE signals
to the logic analyser to see how the memory access is done.
To answer some other posts:
- the sealing is not a problem since there is a rubber pressed against the two
halfs of the case and tou can reseal the unit as many times you want as long
as you treat the screws nicely.
- don't link my email address since this is a temp address and it's whitelisted
anyways (do people still use their real email address when posting on usenet?
gosh! ;-)
Robert Elsinga =8-)
>- don't link my email address since this is a temp address and it's whitelisted
> anyways (do people still use their real email address when posting on usenet?
> gosh! ;-)
All my e-mail addresses are real. =8-) I know, owning a few domains is
a help. =8-)) But I will not display your from: address on the FAQ
page.
Still very interested!
Matrix
> Today I'll just solder a few wires and hook up the ALE, /WE and CLE signals
> to the logic analyser to see how the memory access is done.
Well, I haven't hooked the logic analyser but I did a much better thing, I've
disassembled the firmware. To be more precise the processor has an ARM7 core
(r13=sp, r15=pc) and the code was nasty to disassemble because it supports two
simultaneous encodings: "Thumb" which is a 16bit encoding and the normal 32bit
encoding. This made the disassembly process quite painful because I had to
tell my Interactive Disassemble when it couldn't guess by itself when to switch
from one to the other. Since this was a ROM image the data was mixed with the
code and also needed my hints to disassemble correctly. Anyways after 3 hours
of work I had a very raw listing. The processor runs a multi-threaded real time
system with semaphores and more than 130K from the 1.5M of firmware are text
messages translated from english to french, german etc.
The very good news is that I've found the following structure in firmware:
DCB 0xA4, 0, 0, 0, 0, 0x6F, 1, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
DCB 0xEA, 0, 0, 0, 8, 0x6F, 1, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
DCB 0xE5, 0, 0, 0, 0x10, 0x6F, 1, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
DCB 0xE3, 0, 0, 0, 0x10, 0x6F, 1, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
DCB 0xE6, 0, 0, 0, 0x18, 0x6F, 1, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
DCB 0x73, 0, 0, 0, 0x20, 0x6F, 1, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
DCB 0x75, 0, 0, 0, 0x28, 0x6F, 1, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
DCB 0x76, 0, 0, 0, 0x30, 0x6F, 1, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
DCB 0x79, 0, 0, 0, 0x38, 0x6F, 1, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
If you compare this with a fragment of code from the Linux MTD driver:
struct nand_flash_dev {
char * name;
int id;
int chipshift;
unsigned long erasesize;
char page256;
};
struct nand_flash_dev nand_flash_ids[] = {
{"NAND 1MiB 5V", 0x6e, 20, 0x1000, 1},
{"NAND 2MiB 5V", 0x64, 21, 0x1000, 1},
{"NAND 4MiB 5V", 0x6b, 22, 0x2000, 0},
{"NAND 1MiB 3,3V", 0xe8, 20, 0x1000, 1},
{"NAND 1MiB 3,3V", 0xec, 20, 0x1000, 1},
{"NAND 2MiB 3,3V", 0xea, 21, 0x1000, 1},
{"NAND 4MiB 3,3V", 0xd5, 22, 0x2000, 0},
{"NAND 4MiB 3,3V", 0xe3, 22, 0x2000, 0},
{"NAND 4MiB 3,3V", 0xe5, 22, 0x2000, 0},
{"NAND 8MiB 3,3V", 0xd6, 23, 0x2000, 0},
{"NAND 8MiB 3,3V", 0xe6, 23, 0x2000, 0},
{"NAND 16MiB 3,3V", 0x73, 24, 0x4000, 0},
{"NAND 32MiB 3,3V", 0x75, 25, 0x4000, 0},
{"NAND 64MiB 3,3V", 0x76, 26, 0x4000, 0},
{"NAND 128MiB 3,3V", 0x79, 27, 0x4000, 0},
... one can clearly see that it's the NAND flash structure with the
corresponding device IDs.
This is a very clear indication that NAND flashes which are supported by
GPS V are all the 3.3V chips with sizes from 2MB to 128MB.
The manufacturers are any of the following four:
TOSHIBA (0x98), SAMSUNG (0xec), FUJITSU (0x04), NATIONAL (0x8f)
Now I'm very confident to change my NAND chip once I've copied the info
from the old one. I do have some 64MB chips laying around but I would
like to use a 128MB one which I have to order. I would rather not
desolder/solder twice the memory. Depending on my mood tomorrow I will
try with the 64M one or wait a couple of days to get the 128M chip.
Matt
I think the work you are doing is great and I find it embarassing that
Garmin hasnt done it themselfes ... I assume the reason why they have
19MB only is cost of the memory?
However IMO it is illegal to dissasemble program code ... I think this
is part of the DMCA or someother BS ...
I am not trying to scare you just pointing it out so that some
a******* doesnt burn you
Matt
Matrix <e...@nic.ath.cx> wrote in message news:<slrnbj4s...@flop.halnet>...
Burnie M
>
>However IMO it is illegal to dissasemble program code ... I think this
>is part of the DMCA or someother BS ...
Only in the US, you know 'the land of the free'
Robert Elsinga =8-)
>This is a very clear indication that NAND flashes which are supported by
>GPS V are all the 3.3V chips with sizes from 2MB to 128MB.
>The manufacturers are any of the following four:
>TOSHIBA (0x98), SAMSUNG (0xec), FUJITSU (0x04), NATIONAL (0x8f)
>
>Now I'm very confident to change my NAND chip once I've copied the info
>from the old one. I do have some 64MB chips laying around but I would
>like to use a 128MB one which I have to order. I would rather not
>desolder/solder twice the memory. Depending on my mood tomorrow I will
>try with the 64M one or wait a couple of days to get the 128M chip.
This indeed looks very promising!
Matrix
> However IMO it is illegal to disassemble program code ... I think this
> is part of the DMCA or some other BS ...
Yeah, lucky you Americans. Fortunately I don't live in such a
democratic country as yours ;-> (not that the IP I'm posting from
is very relevant of my actual location but I'm not on US soil)
Heck, my daytime job is chip reverse engineering although the
interest in Garmin is purely personal.
Garmin has no reasons to be pissed if a few geeks upgrade the
memory in their units. It would be quite a different matter
if I would reveal how to change the unit S/N and clone it.
That will get them pissed. I have no incentive to do that
though since I bought my own maps.
Matrix
> Now I'm very confident to change my NAND chip once I've copied the info
> from the old one. I do have some 64MB chips laying around but I would
> like to use a 128MB one which I have to order. I would rather not
> desolder/solder twice the memory. Depending on my mood tomorrow I will
> try with the 64M one or wait a couple of days to get the 128M chip.
I was in the mood ;-) but still got stuck a couple of days.
I've desoldered the Toshiba chip using a Portasol butane pen hot
air blower. This one has a very narrow nozzle (3mm) and I've
desoldered both sides of pins very nicely without bending any
or stressing the PCB in any ways. I did though separate the
LCD screen from the board before to make sure that the heat
doesn't damage the screen.
When I've tried to read the chip with my super-duper-expensive
programmer I've noticed that these high capacity NAND chips
were not supported :-( So I've ordered an el-cheapo USB Smartmedia
reader to use instead. I will use the TSOP48 to DIP adaptor
and solder a few wires to the Smartmedia socket. All Smartmedia
cards use this kind of NAND flash with a different connector.
For those of you who need a cheap reader/programmer an other
alternative (with extra soldering involved) is to buy a USB
flash pen (64M or 128M), use the chip from the pen in the GPS
and use the pen to read/program the old chip. In Linux:
"dd if=/dev/sda of=gpsbackup"
and then with the bigger chip
"dd if=gpsbackup of=/dev/sda"
... but wait until I do it first and confirm it's working ;-)
Burnie M
>On Sat, 09 Aug 2003 13:36:07 +0000, in article
><slrnbj9u...@nic.nicnet> Matrix <e...@nic.ath.cx> wrote:
>
>> Yeah, lucky you Americans. Fortunately I don't live in such a democratic
>> country as yours ;-> (not that the IP I'm posting from is very relevant
>> of my actual location but I'm not on US soil)
On Sun, 10 Aug 2003 08:58:32 +0100, Brian Morrison
<sc...@fenrir.org.uk> wrote:
>I expect Dmitry Sklyarov will tell you that from the US legislature's
>perspective it makes no difference whether you are actually under their
>jurisdiction or not, they will still pursue you if pressed by the company
>involved.
"...and it is politically in their own interests to do it"
Mbrenner99
Assume that you actually get the GPS V to work with a new 128MB chip. Isn't it
going to take hours and hours to program it with your serial port?
Is the processor going to choke the first time you try to look up a street and
the database is huge? Seems like searches will take forever.
Just wondering
MB
Burnie M
many people are using 128MB removeable cards in that.
I agree that neither unit is really fast enough.
Richard Rosenberger
Matrix,
Just found your message (I copied below) about the GPS V memory upgrade.
Let me introduce myself first: I am a service technician from the
Netherlands, and I and my wife run a small company in Palm PDA service.
(http://www.pdatechcenter.nl)
We do a lot of SMD soldering and are capable of doing flash and RAM
upgrades of
different kind of Palm models.
Last year, I bought a GPS V, and found 19 Mb is not enough to store a
large part of the Netherlands, so
we need to load maps on a regular basis.
I love the model, I use it on my motorcycle, and in the car, but 19 Mb
is simply not enough.
I tried the following:
I removed the 32 Mb flash ROM and replaced it with a 64 Mb blank chip.
After this I was able to upload maps, and the uploaded maps were
routable, with
the exception, if the route was outside the uploaded map boundaries I
received a
'routing error' message. I was NOT able to upload more than 19 Mb
(mapsource simply
would not upload more than 19 Mb, I even hacked the registry setting..)
Now, for your information I used a relatively 'old' version of
Mapsource, and
in the new version Garmin changed some code (read release notes) how to
handle
the 'free' memory space in the GPS units. Also my test was done with OS
version 2.08,
and now we are running 2.30. It might be worth it to test it with the
latest versions we have now.
My idea was that the GPS 'tells' mapsource how much memory is actually
free. If that is true,
than the OS does not 'see' the upper 32 Mb. At the other hand, if a
basemap
of Singapore is loaded, the GPS has 28 Mb free space with he original
chip. My guess is
that the information about the memory size is also stored in the chip
where the basemap
is loaded, and this is communicated with Mapsource, if an upload is
initiated.
Another problem I have is how to store the basemap in the new flash
chip. I have a programmer
capable of programming most flash chips (Labtool 148c) but this type of
chip is
not supported. So I cannot read or write the chip with my current
programmer.
With the problems I ran into, I gave up the idea to commercially do the
upgrades, like I do for
the Palm and Sony PDA's. But now there is more information available,
and a software tech. (you)
that can disassemble and 'read' the code, I hope we can corporate with
each other to
get this to work. I would even buy a new Flash programmer if needed. I
do have a source for chips.
I tested it with a chip extracted form a 'pendrive' It might be worth to
even try to upgrade
the unit to 128 Mb. for testing you might buy a 256 Mb USB pendrive and
extract the 2 128 Mb chips
to use.
I hope to hear from you, and let me now if can be of any help.
Finally, I would like to excuse me for my bad English. My native
language is Dutch.
With kind regards,
Richard Rosenberger. ric...@sfinx.demon.nl
Robert Elsinga =8-)
<ric...@sfinx.demon.nl> wrote:
>I tried the following:
>I removed the 32 Mb flash ROM and replaced it with a 64 Mb blank chip.
>After this I was able to upload maps, and the uploaded maps were
>routable, with
>the exception, if the route was outside the uploaded map boundaries I
>received a
>'routing error' message. I was NOT able to upload more than 19 Mb
>(mapsource simply
>would not upload more than 19 Mb, I even hacked the registry setting..)
>Now, for your information I used a relatively 'old' version of
>Mapsource, and
>in the new version Garmin changed some code (read release notes) how to
>handle
>the 'free' memory space in the GPS units. Also my test was done with OS
>version 2.08,
>and now we are running 2.30. It might be worth it to test it with the
>latest versions we have now.
Mapsource 5.0 should not have this fixed 19Mb upload for a V, at least
the check is removed from the maps section...
>Another problem I have is how to store the basemap in the new flash
>chip. I have a programmer
>capable of programming most flash chips (Labtool 148c) but this type of
>chip is
>not supported. So I cannot read or write the chip with my current
>programmer.
This would mean you would be able to reprogram a US GPS V with the
Atlantic basemap, if you had the right tool? You could make a lot of
money with that... =8-)
I hope this can turn into a joint effort, making it possible to have a
GPS V with larger memory. I would love to have my V upgraded to 128Mb,
so I can load the entire Benelux area. I would take the extreme upload
times for granted, as I can also upload less maps if I wanted.
Marcel.
Rosenberger says...
> With the problems I ran into, I gave up the idea to commercially do the
> upgrades, like I do for
> the Palm and Sony PDA's. But now there is more information available,
> and a software tech. (you)
> that can disassemble and 'read' the code, I hope we can corporate with
> each other to
After you guys solved the hardware, software and legal problems, take
some time to hack the upload routine of the V and get it running at a
much higher baudrate.
gr, Marcel.
Richard Rosenberger
Mapsource does the check, but AFTER the maps are compiled. i am not sure
Mapsource *asks* the GPS howmuch memory is free. If it does, the next
question is of the GPS' *does see* the extra memory, and tell mapsource
about the amount of free memory. In my previous attempt, i soldered an
empty chip in the GPS, hence i had 64 Mb free memory space. Mapsource
refused to upload more than 19 Mb alhough i hacked the registry setting
to tell mapsource the unit has 64 Mb free memory available. Mapsource
simply resetted it to 19 Mb.
If i have some spare time next weekend, i will retry the operation with
the newer versions of the software. I might be able to program the chip
with the newer version eprom programmer software.
My guess is, that Matrix is testing too. I hope he will email me direct,
so we can share information, and work together on this project.
And yes, despite the legal stuff, we *might* be able to reprogram the
basemap. So, US to atlantic and v.v.
Anyway, we have some work to do. Another option is to upload a newer
version of the basemap into the flash from a Vista or SP III. It might
also be possible to erase parts of the basemap (US/Asia for Atl.
versions, and Europe/Asia for US versions) to save memory. (see the post
from the guy ho has only Korea, and 24 Mb free memory to upload maps.
Richard
Matrix
> Mapsource does the check, but AFTER the maps are compiled. i am not sure
> Mapsource *asks* the GPS howmuch memory is free. If it does, the next
> question is of the GPS' *does see* the extra memory, and tell mapsource
> about the amount of free memory. In my previous attempt, i soldered an
> empty chip in the GPS, hence i had 64 Mb free memory space. Mapsource
> refused to upload more than 19 Mb alhough i hacked the registry setting
> to tell mapsource the unit has 64 Mb free memory available. Mapsource
> simply resetted it to 19 Mb.
I've finally managed to solder my new chip inside the unit too.
I took the NAND chip from a Sony memory stick since it was half
the price of a new NAND chip. Use a cutter and carefully open
the memory stick package: http://nic.ath.cx/GPSV/mstick128.jpg
and you've got yourself a cheap 128MB flash NAND chip.
I've also purchased a Dazzle 8in1 USB programmer (which works
in Linux with the USB storage module) to transfer my basemap
from the old chip to the new one. I've soldered wires from the
Smartmedia connector to a DIP to TSOP48 adaptor but after testing
with a dummy chip I've noticed data misalignment between read
and writes. These are probably the result of my wires which are
increasing the signals load and because the Dazzle programmer
is a high speed one (USB 2.0). So I've postponed the basemap
transfer for sometime later. I'm amazed that expensive programmers
don't handle these flash NANDs since they are so easy to interface.
One can always solder these chips into cheap USB programmers or pen
drives to read/program them.
In your GPSV you'll find either a Toshiba TC58256AFT or a
Samsung K9F5608U0A-YCB0 chip (both are 32MB 3.3V NANDs).
You will want to replace this chip with any of the following:
Samsung Toshiba
64MB (512Mb) K9D1208U0A-YCB0 TC58512FT
128MB (1Gb) K9D1G08U0M-YCB0 TH58100FT
I've replaced mine with a 128MB chip directly taken out of a
memory stick without even erasing it (so it had a few Sony
strings and format data) and it is working fine.
The NAND flash holds _only_ the basemap and the other maps.
All the other information like waypoints, track data and
other settings are stored in the firmware flash since I
haven't lost them after soldering the new chip.
As a conclusion: upgrading your memory chip is easy and harmless.
Now the Mapsource software side still needs some work.
While trying to load a larger set while it says "building index"
you will get the following error:
The map set is too large.
Please choose a smaller map set.
which is a unicode string from the file MapSource_Lang.dll
My guess is that the software doesn't even bother to query
the unit's memory size and uses some fixed values. If you
disconnect the serial cable from the unit right after its
presence is detected the "building index" still goes on and
finishes with the same error.
I've started the program's disassembly but just the initial
analysis takes a few hours and I'll need some more time
to figure this one out (and my girlfriend claims all my
weekends!). Meanwhile could someone please confirm me that
version 5.0 is newer than 5.0.3-beta (which is weird) ?.
I've started the work on the beta version and I'll probably
need to start the analysis again with version 5.0.
Also could someone please capture the initial data on the serial
interface while programming the GPS ? My environment here is
winblouz running in vmware in a virtual disk and sharing
the serial ports with the Linux host and I can't capture this
data from the Linux side. Besides I don't even have the right
tools for winblouz.
If I don't "fix" the Mapsource this week I'm afraid you'll
have to wait 3 weeks until I'm returning from my vacation.
Robert Elsinga =8-)
>As a conclusion: upgrading your memory chip is easy and harmless.
Great! =8-)
>Now the Mapsource software side still needs some work.
>
>While trying to load a larger set while it says "building index"
>you will get the following error:
> The map set is too large.
> Please choose a smaller map set.
>which is a unicode string from the file MapSource_Lang.dll
>
>My guess is that the software doesn't even bother to query
>the unit's memory size and uses some fixed values. If you
>disconnect the serial cable from the unit right after its
>presence is detected the "building index" still goes on and
>finishes with the same error.
Okay, so you need to patch Mapsource to tell it a GPS V will hold over
100 Mb.
>I've started the program's disassembly but just the initial
>analysis takes a few hours and I'll need some more time
>to figure this one out (and my girlfriend claims all my
>weekends!). Meanwhile could someone please confirm me that
>version 5.0 is newer than 5.0.3-beta (which is weird) ?.
It is... =8-}
>I've started the work on the beta version and I'll probably
>need to start the analysis again with version 5.0.
>Also could someone please capture the initial data on the serial
>interface while programming the GPS ? My environment here is
>winblouz running in vmware in a virtual disk and sharing
>the serial ports with the Linux host and I can't capture this
>data from the Linux side. Besides I don't even have the right
>tools for winblouz.
If you give me an URL where to get the software and tell me what to
do, no problem. If I need extra cables, it would be another thing...
>If I don't "fix" the Mapsource this week I'm afraid you'll
>have to wait 3 weeks until I'm returning from my vacation.
Which would be no problem for me, except I'm curious as hell. =8-)
I guess the complete package (instructions how to do this yourself and
the v5.0 patch) would also require some time. And I wouldn;t do it
myself, so I still depend on someone here in the netherlands to do it
for me. Arranging that also takes time.
So, take your time to do it right. =8-)
J. Charles Holt
other units, such as the Rino or eTrex series? I can't even figure out
how to get my Rino apart to see whether it uses the same type of
memory chip (I undid the six screws, but it feels as if it's glued
together or something, as there's equal resistance all around the
perimeter).
Has anyone tried this yet? How slow is the unit?
Dale DePriest
Did you read the thread? Your question is way premature. No one has it
running on the V yet or any other Garmin unit.
Dale
--
_ _ Dale DePriest
/`) _ // http://users.cwnet.com/dalede
o/_/ (_(_X_(` For GPS and GPS/PDAs
gps_mapper
You can eventually try mine uploader instead of MapSource - just
before it start uploading maps it asks GPS for amount of the free
memory.
You can get uploader from http://gps.chrisb.org - the name is
'sendmap' (you can have some troubles with the linux version becaucse
of the used library version - if you have them - I can recompile)
just after issuing command
sendmap port_name img_file1 img_file2 ...
(
windows: sendmap com1 12345678.img
linux: sendmap /dev/ttyS01 12345678.img
)
you will see on the screen what is available memory ( what tells GPS )
If you want - I can create a special version of 'sendmap' which will
not care of the amount of free memory the GPS tells.
Hope - that can help.
Stan
J. Charles Holt
> J. Charles Holt wrote:
> > Does anyone know if this type of upgrade would work for some of their
> > other units, such as the Rino or eTrex series? I can't even figure out
> > how to get my Rino apart to see whether it uses the same type of
> > memory chip (I undid the six screws, but it feels as if it's glued
> > together or something, as there's equal resistance all around the
> > perimeter).
> >
> > Has anyone tried this yet? How slow is the unit?
>
> Did you read the thread? Your question is way premature. No one has it
> running on the V yet or any other Garmin unit.
>
> Dale
Yes, I read the thread in full. Apparently I misunderstood some of the
problems still being dealt with. My apologies for being overeager.
Jan B
...
>Now the Mapsource software side still needs some work.
>
>While trying to load a larger set while it says "building index"
>you will get the following error:
> The map set is too large.
> Please choose a smaller map set.
>which is a unicode string from the file MapSource_Lang.dll
>
>My guess is that the software doesn't even bother to query
>the unit's memory size and uses some fixed values.
I don't know but at least the models that use cartridges have to be
queried, such as Emap . So why would they build that info into
Mapsource?
/Jan
Robert Elsinga =8-)
(Jan B) wrote:
>I don't know but at least the models that use cartridges have to be
>queried, such as Emap . So why would they build that info into
>Mapsource?
My guess is that the size of the memory is encoded on the 32Mb chip.
Something like "start user memory"/"end memory". At least I hope so,
since that would make the upgrade independant of the firmware and
mapsource. =8-)
Richard Rosenberger
>In article <4v9ijvcktcsa2h6t1...@4ax.com>, Richard Rosenberger wrote:
>> Mapsource does the check, but AFTER the maps are compiled. i am not sure
>> Mapsource *asks* the GPS howmuch memory is free. If it does, the next
>> question is of the GPS' *does see* the extra memory, and tell mapsource
>> about the amount of free memory. In my previous attempt, i soldered an
>> empty chip in the GPS, hence i had 64 Mb free memory space. Mapsource
>> refused to upload more than 19 Mb alhough i hacked the registry setting
>> to tell mapsource the unit has 64 Mb free memory available. Mapsource
>> simply resetted it to 19 Mb.
>
>I've finally managed to solder my new chip inside the unit too.
>I took the NAND chip from a Sony memory stick since it was half
>the price of a new NAND chip. Use a cutter and carefully open
>the memory stick package: http://nic.ath.cx/GPSV/mstick128.jpg
>and you've got yourself a cheap 128MB flash NAND chip.
>
Ok, i use a pendrive for sourcing the 64 Mb chip.
I soldered <again> the 64 Mb chip into the unit. I did some experiments
with Sendmap (mentioned elswhere in this thread) With the original chip
I received 19906560 bytes available. Without ANY chip i received 0 bytes
available, and with the (empty) 64Mb chip i received 19922944 bytes
available. ( the difference is 16384 bytes (!))
So, probably Mapsource IS checking the available space like sendmap
does. My guess is, the GPS ignores the 4th cycle needed to address
address line 25.
Now, To be certain MapSource queries the GPS i checked the registry
value Mapsource writes after uploading maps it can be found at
HKEY_CURRENT_USER\Software\GARMIN\MAPSOURCE\SETTINGS -> UnitAvailSpace
With the original chip it says 19906560
I uploaded a map to the empty 64 Mb chip and MapSource wirtes the
new value in the registry. (19922944).
BTW this only works with MapSource 4.xx. MapSource 5 does not write the
value to the registry.
This proves:
1) the GPS does not "see" the extra 32 Mb
2) the GPS does not "see" the free space by absence of the basemap
3) MapSource DOES query the GPS howmuch space there is free.
Problems to solve:
1) Get the GPS to recognize the extra memory,
2) write teh basemap into the new chip.
My programmer can handle the 32 Mb chip, but NOT the
64 or 128 Mb chip. So, i have an image file of the atlantic basemap,
which allows me to reprogram the US and oceanic devices....
I complaned by the programmer manufacturer....
Matrix, it would be nice to be able to communicate with you using
e-mail. Can you mail me your email address?
Richard
Csaba Kálmán
Somewhere in your earlier post you wrote:
>The firmware is not encrypted or compressed and can be easily
>disassembled with IDA (interactive disassembler) switched to
>ARM instruction codes.
I'm not so experimented in reverse engeneering as you, please give me a
little help. When I try to disassemble the firmware (any .RGN file), it
loads as a binary file. What options (loading segment, offset, processor
type, etc.) should I set to become a usable result. What is the entry point
for the initial autoanalisys?
I'm very pleased if you can help me!
Thanks and good luck for the project,
Csaba
(I'm posting to the forum because your email address does not work :-( )
Robert Elsinga =8-)
<ric...@sfinx.demon.nl> wrote:
>Problems to solve:
>1) Get the GPS to recognize the extra memory,
Maybe the size (or free mem) is written somewhere on the memory chip.
The original has the correct values there (thus, it works), the empty
one has all 000's there, reporting zero. And the 64Mb copy of the 32Mb
one has the values of the original, reporting 19Mb.
This would be compatible with the SP3, which accepts different memory
sizes (but the SP3 would have some etra code to "format" an empty
memory card).
>2) write teh basemap into the new chip.
A simple 32Mb to 64Mb copy, leaving the last 32Mb empty would do the
trick, I guess.
Richard Rosenberger
<g...@elsinga.org> wrote:
>On Fri, 22 Aug 2003 14:54:48 +0200, Richard Rosenberger
><ric...@sfinx.demon.nl> wrote:
>
>>Problems to solve:
>>1) Get the GPS to recognize the extra memory,
>
>Maybe the size (or free mem) is written somewhere on the memory chip.
>The original has the correct values there (thus, it works), the empty
>one has all 000's there, reporting zero. And the 64Mb copy of the 32Mb
>one has the values of the original, reporting 19Mb.
No, the chip is empty.
>
>This would be compatible with the SP3, which accepts different memory
>sizes (but the SP3 would have some etra code to "format" an empty
>memory card).
Yep.
>
>>2) write teh basemap into the new chip.
>
>A simple 32Mb to 64Mb copy, leaving the last 32Mb empty would do the
>trick, I guess.
Yes, but my programmer will not support the big chip. But this issue can
be solved l8er. First i need to get the darn GPS 'see' the upper 32 Mb.
Rich.
Robert Elsinga =8-)
<ric...@sfinx.demon.nl> wrote:
>>>Problems to solve:
>>>1) Get the GPS to recognize the extra memory,
>>
>>Maybe the size (or free mem) is written somewhere on the memory chip.
>>The original has the correct values there (thus, it works), the empty
>>one has all 000's there, reporting zero. And the 64Mb copy of the 32Mb
>>one has the values of the original, reporting 19Mb.
>
>No, the chip is empty.
So an empty 32Mb chip reports 19Mb and an empty 64Mb chip also?
Hmmm... this would mean the firmware needs patching...
>>>2) write teh basemap into the new chip.
>>
>>A simple 32Mb to 64Mb copy, leaving the last 32Mb empty would do the
>>trick, I guess.
>
>Yes, but my programmer will not support the big chip. But this issue can
>be solved l8er. First i need to get the darn GPS 'see' the upper 32 Mb.
Yep.
BTW, in the dutch gps_nl yahoogroup, there is quite a lot of talk
about the mem upgrade. I guess there would be at least 10 customers
there, myself not included. =8-)))
Marcel.
Rosenberger says...
If everything else fails, maybe a simple switch could be used to select
the lower or upper half of the 64MB chip, which in effect would mean two
times 19MB space for maps.
And then we need, of course, a clever way of switching.
Of
groet, Marcel.
Dale DePriest
Robert Elsinga =8-) wrote:
> So an empty 32Mb chip reports 19Mb and an empty 64Mb chip also?
> Hmmm... this would mean the firmware needs patching...
More likely you will need an address line on the circuit board to go to
the upper 32K of memory and then maybe firmware changes.
Robert Elsinga =8-)
wrote:
>If everything else fails, maybe a simple switch could be used to select
>the lower or upper half of the 64MB chip, which in effect would mean two
>times 19MB space for maps.
A compromise... but when we have no alternative.... This could also be
done with 4x19Mb and a 128Mb chip. =8-)
>And then we need, of course, a clever way of switching.
Which would be a hardware switch, since the software can;t be used to
switch something it doesn't know its there. And it shouldn;t kill IP7
waterpoof status, I guess. This would be a real challenge!
Al
"Marcel." <sle...@hotmail.com> says...
> If everything else fails, maybe a simple switch could be used to select
> the lower or upper half of the 64MB chip, which in effect would mean two
> times 19MB space for maps.
> And then we need, of course, a clever way of switching.
No HW switch to select the memory (read the memory datasheet).
From an old post of Matrix:
>There are many other Flash NAND memory chips with 64M/128M/256M
>capacities which are pin to pin compatible and command compatible.
>The only difference between them is the address cycle. For the 32M
>versions the data bus pulses 3 times to send A0-A7, A9-A16, A17-A24
>For the bigger capacity versions a 4th cycle is needed to send A25-Ax.
>The lower capacity NANDs ignore the 4th cycle address so all these
>memories could use the same (4 cycle) address sending subroutine.
Good work,
Al
Matteo
squeezing their brains about this project - it's really what the gpsV
is missing.
A couple of ideas:
1) if there is a socket for nand memories, it could be a good idea to
put a socket in place, so that one can hold some already programmed
chips with the various parts of the world and just unscrew the unit
and put them in, rather than solder/unsolder the chip itself.
2) if we would ever get to a good disassembly of the code, it should
not be that complex to implement support for memory cartridges like
MS, SD and alike... the connector that is actually used for power and
serial signals could be a good socket for connectiong those devices as
well , provided that we find a way not to degrade the signals too much
- obvisouly this is a MAJOR change with respect to #1 - but it's
really be wonderful to have SD on GPSV!!!
regards
mat
Matrix <e...@nic.ath.cx> wrote in message news:<slrnbk4n...@nic.nicnet>...
Scott Nelson
Have you left us? I haven't heard any more from you.
Scott
Matrix" <e...@nic.ath.cx> wrote in message
news:slrnbj27...@flop.halnet...
> I am very pleased with my GPS5 unit except one thing - the memory
capacity.
> 20Mb of maps is about one third of what I currently need and the memory
> limit makes me upload the same maps over and over again. So I've decided
> to investigate what could be done to increase the flash size.
>
> This is how a GPS V unit looks inside:
> http://nic.ath.cx/GPSV/GPS1.jpg
> http://nic.ath.cx/GPSV/GPS2.jpg
> and these are the memory chips used:
> AM29LV160BB-90 - 16 Mbits Flash (1Mx16) 3.3V
> CY7C1041BV33-12 - 4 Mbits SRAM (256Kx16) 3.3V
> TC58256 - NAND Flash (32Mx8) 3.3V (TSOP48)
> The first flash holds the firmare for their 16 bit processor (ARM core)
> and the third one holds the base map and the downloaded maps.
>
> There are many other Flash NAND memory chips with 64M/128M/256M
> capacities which are pin to pin compatible and command compatible.
> The only difference between them is the address cycle. For the 32M
> versions the data bus pulses 3 times to send A0-A7, A9-A16, A17-A24
> For the bigger capacity versions a 4th cycle is needed to send A25-Ax.
> The lower capacity NANDs ignore the 4th cycle address so all these
> memories could use the same (4 cycle) address sending subroutine.
>
> A 128M chip costs less than 100$ and increases the uploaded map
> capacity more than 5 times. This will also increase your (serial
> interface) transfer time to 4 hours but you'll only do it once.
> To replace the chip one can use a hot air pen torch to remove
> the old chip and solder the new TSOP48 package instead (half of
> the pins are not-connected which makes soldering even easier).
>
> Because I don't know the procedure of loading the basemap I plan
> to read the old chip in a programmer and copy the file at the
> beginning of the new chip.
>
> This alone will not work if the firmware doesn't have provisions
> to interogate the NAND ID and switch to a 4 cycle address routine.
> In this case I can either ask Garmin to change this in their
> firmware or I can read the other flash myself (to avoid agreeing not to
> reverse engineer their firmware when downloading a firmware upgrade).
>
> The firmware is not encrypted or compressed and can be easily
> disassembled with IDA (interactive disassembler) switched to
> ARM instruction codes. Then find the address build routine which
> has the address passed as a 32bit value and generate a 4th cycle
> from the MSB of the address.
>
> Before proceeding with this experiment I'd like to know if
> anyone ever tried this or has more information about this subject.
>
Richard Rosenberger
<mes...@cablespeed.com> wrote:
>Matrix,
>Have you left us? I haven't heard any more from you.
>
>Scott
Matrix took 3 a week vacation, he will be back next week.....
Richard
Scott Nelson
Is he still pursuing this project?
Thanks,
Scott
"Richard Rosenberger" <ric...@sfinx.demon.nl> wrote in message
news:dmsulv07q2heloa81...@4ax.com...
Richard Rosenberger
Richard
On Wed, 10 Sep 2003 18:10:25 -0700, "Scott Nelson"
Bill Sumrall
<ric...@sfinx.demon.nl> wrote:
>B4 he left for vacation, he was....
>
>Richard
-----------
I hope he presses on with the project. Could vault him up to the
super-rich category, if he isn't there already.
Bill
Richard Rosenberger
Any news? have you read the thread?
Hope to hear from you...
Richard
On Fri, 12 Sep 2003 23:00:08 +0200, Richard Rosenberger
<ric...@sfinx.demon.nl> wrote: