Gecko
Registered user
Trawling around the web I came across this write up from some guy who like me feels that his GPS V unit's only real failing is the lack of memory. Unlike me this guy has started looking to find a way to increase his unit's 20mb into something much more useable - 100mb for example !!! Now a GPS V with 100mb memory get's my attention.
Warning this gets really technical - so the question to the techies - is is he really onto something here and could it be done ?
Newsgroups: sci.geo.satellite-nav
From: Matrix
Subject: GPS V memory upgrade
Date: Wed, 06 Aug 2003 15:23:05 GMT
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.
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.
UPDATED STATUS
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.
So what's the verdict - is he onto a breakthrough in GPS V memory and userbility ??
Warning this gets really technical - so the question to the techies - is is he really onto something here and could it be done ?
Newsgroups: sci.geo.satellite-nav
From: Matrix
Subject: GPS V memory upgrade
Date: Wed, 06 Aug 2003 15:23:05 GMT
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.
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.
UPDATED STATUS
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.
So what's the verdict - is he onto a breakthrough in GPS V memory and userbility ??
