Thank You for your continued support and contributions!
telnet_port 4444gdb_port 3333interface parportparport_port 0parport_cable arm-jtag #have already tried wiggler and wiggler_ntrst_inverted settings herejtag_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_trstjtag_ntrst_delay 100set _CHIPNAME as3525set _ENDIAN littleset _CPUTAPID 0x00922f0fjtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPIDset _TARGETNAME $_CHIPNAME.cputarget create $_TARGETNAME arm920t -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm920t$_TARGETNAME configure -work-area-phys 0x200000 -work-area-size 0x4000 -work-area-backup 1
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]interface parportparport_port 0parport_cable arm-jtag #have already tried wiggler and wiggler_ntrst_inverted settings here
interface parportparport_port 0parport_cable arm-jtag #have already tried wiggler and wiggler_ntrst_inverted settings here
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...
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.
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).
#define MEMORY_MODEL 0x5
#define MEMORY_MODEL 0x9
#define MEMORY_MODEL 0xD
#define MEMORY_MODEL 0x11
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.
ldr r1, =DRAM_ORIG+(0x2300*MEM)
ldr r1, =DRAM_ORIG+(0x2300*16)
Page created in 0.153 seconds with 21 queries.