32MB Fuze V1, Checksum error

[ranma]

I've only used openocd for JTAG so far, but it worked well for me (using a FT2232 board for the JTAG interface).  What kind of parallel JTAG interface did you get? Is it 3V compatible?
For openocd something like http://www.rockbox.org/wiki/pub/Main/SansaAMSJTAG/openocd.cfg
should work, but you'll have to change the interface settings to those required for your parallel interface.

Also, usually if you upgrade the RAM with one of bigger size it generally should work with the old rams settings (but you don't get the bigger size until you've switched to updated settings). If you get checksum errors that's an indication that maybe the ram isn't compatible after all or you've got some bad soldering joints.

For example, on my WRT54GL I replaced the original 16MB ram chip with a compatible 64MB ram chip and it will boot just fine (though in 16MB mode) directly after the upgrade, with the old ram settings.  Then, after flashing the new settings and rebooting I had 64MB of ram.

[sss]

The JTAG cable is the one from this auction: http://cgi.ebay.com/PC-JTAG-Programmer-Adapter-Debugger-w-JTAG-Cable-New-/250637375168?pt=LH_DefaultDomain_0&hash=item3a5b26d6c0 .  It is supposed to adapt to the target voltage.

Regarding the settings here: http://www.rockbox.org/wiki/pub/Main/SansaAMSJTAG/openocd.cfg , I found those yesterday and tried them in openocd for linux (debian version from repository). Here is my config:

Code: [Select]

telnet_port 4444
gdb_port 3333

interface parport
parport_port 0
parport_cable arm-jtag #have already tried wiggler and wiggler_ntrst_inverted settings here
jtag_khz 6000
##use combined on interfaces or targets that can't set TRST/SRST separately <-Tried the below setting, didn't seem to help
#reset_config trst_and_srst srst_pulls_trst

jtag_ntrst_delay 100

set _CHIPNAME as3525
set _ENDIAN little
set _CPUTAPID 0x00922f0f

jtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm920t -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm920t
$_TARGETNAME configure -work-area-phys 0x200000 -work-area-size 0x4000 -work-area-backup 1

[ranma]

The JTAG cable is the one from this auction: http://cgi.ebay.com/PC-JTAG-Programmer-Adapter-Debugger-w-JTAG-Cable-New-/250637375168?pt=LH_DefaultDomain_0&hash=item3a5b26d6c0 .  It is supposed to adapt to the target voltage.

Hmm, judging from the picture it's just using a 74hc244 octal tri-state line driver/buffer, which is not a proper level-shifter AFAICS.
It may still work though...

Regarding the settings here: http://www.rockbox.org/wiki/pub/Main/SansaAMSJTAG/openocd.cfg , I found those yesterday and tried them in openocd for linux (debian version from repository). Here is my config:

Code: [Select]

interface parport
parport_port 0
parport_cable arm-jtag #have already tried wiggler and wiggler_ntrst_inverted settings here

The question here is, was there accompanying documentation of the jtag signal to parallel port pin mapping?
If you're unlucky you'll have to edit the openocd source to add the specific mapping and recompile...

[sss]

Hmm, judging from the picture it's just using a 74hc244 octal tri-state line driver/buffer, which is not a proper level-shifter AFAICS.
It may still work though...

I noticed the simple design and figured it was just another instance of the Chinese using common chips in unusual ways to fit needs.  They do that a lot.  Reminds me of the Chinese flashlights that use more LEDs to make up for a lack of proper current regulation.

[ranma]

BTW, comparing
http://www.frozeneskimo.com/electronics/wp-content/uploads/Schematics/jtagwigglersch.png
and the pic in the auction you linked to I'd say your interface is most likely wiggler compatible.

[sss]

That's what I figured.

I might try swapping the #2 and #5 wires around (relative to the fuze), those are nTRST and TCK.  The reason being that the clip+ has a similar eight pin jtag connection with those two pins in opposite positions.  I read somewhere that nTRST isn't even important with arm and that it could simply be left disconnected.

In the meantime I am waiting for another fuze (it's in the mail) I ordered that's almost totally scrap.  I plan on (gently) pulling off the ram module under hot air, cleaning the module and the pads completely (so they are nice and even), and then swapping between one of my good 32MB chips and the old 8MB ESMT chip WITHOUT soldering them to the board.  Light pressure should be enough to keep sufficient electrical contact.

Some of the rest of my fuzes, although sold as "junk", I have managed to repair and they are working fine so I don't want to toy with those yet.  My original fuze is still attached to a jtag cable and I don't want to disturb it much, small wires tend to break off if agitated enough.

[ranma]

That's what I figured.

I might try swapping the #2 and #5 wires around (relative to the fuze), those are nTRST and TCK.  The reason being that the clip+ has a similar eight pin jtag connection with those two pins in opposite positions.  I read somewhere that nTRST isn't even important with arm and that it could simply be left disconnected.

Well, it's important enough.
It should be at least pulled up, since the device has an internal weak pulldown and a low-level on nTRST means 'reset the JTAG state-machine', so you won't get anywhere while it's low...

In the meantime I am waiting for another fuze (it's in the mail) I ordered that's almost totally scrap.  I plan on (gently) pulling off the ram module under hot air, cleaning the module and the pads completely (so they are nice and even), and then swapping between one of my good 32MB chips and the old 8MB ESMT chip WITHOUT soldering them to the board.  Light pressure should be enough to keep sufficient electrical contact.

That would be a neat feat to pull off.
I think you can also buy TSOP sockets, but those ain't cheap.

You can figure out the JTAG pinout manually, you just need a debounced switch for manual clocking and some inverters and leds to monitor the pad logic level.
You already know Gnd and Vcc.
Then choose one pin as TRST,  one as TCK.
Use the remaining pins as TMS (use a resistor to drive them so you can still see if the device tries to use one of them as TDO and drive out the result).
Set TRST high.  Set TMS high and clock a few times (IIRC 5?) until you are sure to have reached the test logic reset state.
Clock in TMS 0 1 0 0 (and leave at 0).
Then you should be in the 'shift DR' state.
Send clocks until one of the 'TMS' pins starts toggling (TDO).
If no pin starts toggling you have chosen the wrong pins for TRST and TCK, repeat with a different pin combination.

If you succeeded you know now TRST, TCK and TDO, finding out TMS and TDI should be pretty easy now.

That's how I figured out the pinout on my C200v2.

Your player may also have SRST pad on the JTAG connector, you can find that one using one of the working fuzes.
If pulling one of the pins low using a 10K resistor resets the device then that's SRST.

[sss]

Before I do anything else, I'm going to try pulling up nTRST with a 10 or 15kohm resistor and giving jtag another go the way it is.  I read about another rockbox user needing to do this with his sansa (forget which model), but at the time I thought he did it to address a flaw in the design of the wiggler he assembled to connect with.  Now that I am hearing this again I think it's worth a shot.  By the way, the scrap fuze I ordered came, but it's a V2 and it doesn't have any external ram  .  Nice to have a spare V2 for testing but not what I was looking for at the moment.  I am going to stick with only 2GB fuzes in the future since most of those seem to be V1s.  I might still try the memory swap test I was planning on doing but I'll have to do it on one of my fully functional V1 fuzes.

[sss]

SUCCESS    Got back to this project after finishing several other affairs and getting a new bus pirate to JTAG with.
Posted my JTAG findings in the Wiki here: http://www.rockbox.org/wiki/SansaAMSJTAG

I was having poor luck with my cheap parallel interface so I upgraded to something more useful and I do not regret it!


Now that I have JTAG working, I'm wondering what commands I need to enter to get the registers set correctly so that the extra ram can be properly used (?)

[sss]

I also succeeded in upgrading the player memory 
I will post photos when I get a chance.

Most of the posters were right (so was my initial intuition).  So long as the ram is compatible, there is no need to mess with any settings (at least to get the player running).  Recognizing the additional ram of course does require special firmware settings.

Here's what happened:

*Got sick of waiting for a few extra semi-broken players to test (USPS lost my damn package), modded another working V1 fuze and somehow it became completely non-working despite doing a perfect soldering job.  Heat must have killed some unusually sensitive component, not worth my time figuring out which one (CPU?)
*Went back to the fuze I had connected to JTAG wires.  Took those off since they were in the way (lot of work for nothing but now we have the Fuze JTAG pinout).  Fluxed the ram chip again, went over my joints another time and NOW the thing boots!    Apparently there was in fact a bad joint somewhere I had long overlooked.  I couldn't believe it.

Well it was fun, I have a bunch of extra chips so I will get to work on whipping up a few 32MB fuzes out of what I have left and what I can find.
I have a few friends who wanted one, so after I'm done with those, I will put together a handful for rockbox users who've always wanted a 32MB fuze!

Sorry this project took so long!  I had a few other priorities and I really stuck this on the back burner for quite a while!  Had I known for a fact it was just a bad joint all along, I would have gotten on this a lot sooner.

[gevaerts]

Congratulations! Now go for the 64MB Fuze!

[sss]

If you get me 64MB modules I can get you a 64MB fuze.  They are rare and VERY expensive unless you find some "surplus" (and where would you get surplus 64MB SDRAM chips??)

I have a stock of proper 32MB chips so the next mods I do will use those.
My current modded player has a 16MB chip (original was only 8MB), yet even 16MB was enough to run the Doom II Community Chest III wad (one of the most massive and memory hungry level-packs I could find):
note that the rest of the memory is used by rockbox and of course that's why it doesn't show all 16MB

http://i56.tinypic.com/4hs092.jpg

http://i55.tinypic.com/15of4uc.jpg

http://i55.tinypic.com/rk27ht.jpg

http://i53.tinypic.com/10rijyx.jpg

It runs great!

Like I said (and expected) in previous posts, all I needed to change was:

the memory model definitions in firmware/target/arm/as3525/memory-init.S (pick one):

Code: [Select]

#define MEMORY_MODEL 0x5

(8MB)

Code: [Select]

#define MEMORY_MODEL 0x9

(16MB)

Code: [Select]

#define MEMORY_MODEL 0xD

(32MB)

Code: [Select]

#define MEMORY_MODEL 0x11

(64MB)

and the "export MEMORYSIZE=XX" variable in both the firmware and bootloader makefiles (generated from the tools/configure script).

If you only compile and install only rockbox it will display the newly available memory BUT IT WON'T BE ABLE TO USE IT ALL.  If you use beyond the 8MB boundary you would get an error and the player would crash, because the bootloader is still compiled for use with an 8MB fuze.  After compiling both rockbox AND the new bootloader (BL file is fed into mkamsboot to generate new fuzea.bin) with the new makefiles and the updated memory-init.S file, I had no more of these errors and I could use as much ram as I pleased.  Remember that the patched firmware must be read and applied by booting into the open firmware once.
-------------------EDIT:
After assembling a few fuzes with 32MB chips, I've found that funman was right about one thing:

Also, in memory_init.S, an important part is:

    ldr     r1, =DRAM_ORIG+(0x2300*MEM)
    ldr     r1, [r1]

Which I believe "programs the SDRAM mode".
The exact address from which we read (0x2300*2 on 2MB models, 0x2300*8 on 8MB models) will program some settings of the SDRAM; but it might not necessarily be 0x2300*32 on 32MB models.

For the 16MB fuze this did not need to be changed to work.
My 32MB fuzes were a completely different story.  When testing I ended up with a totally black screen and very unresponsive fuze until I did a jumper unbrick (http://www.rockbox.org/wiki/SansaAMSUnbrick) and installed a bootloader compiled correctly (the RB firmware should be compiled right too but the bootloader is first and foremost).
I changed

Code: [Select]

ldr     r1, =DRAM_ORIG+(0x2300*MEM)

to

Code: [Select]

ldr     r1, =DRAM_ORIG+(0x2300*16)

and my 32MB test fuze booted fine.  I tried both 32 and 8 in place of 16 just to test and my 32MB test fuze completely failed to boot (unlit black screen).
___

Update:
Although my 16MB fuze is stable, the 32MB fuzes are not.  I need to tweak more settings it seems...

[sss]

Just want to point out I am continuing this thread over here so you don't need to scroll through three pages of conversation: http://forums.rockbox.org/index.php?topic=26059.0

I am attempting to lead extremely thin wire under the BGA chip, reflow the solder to stick the wire to the J-5 ball, and connect the other end to the A12/pin 36 lead on the ram chip.  The BGA balls do not afford a lot of wiggle room so the wire needs to be crazy thin.  Damn Sandisk for not routing a trace to A12!