The J-Link data looks definitley messed up. It is almost as if it starts to load every linker section at 0x20000000. But not quite . Perhaps an inspection of the -d3 debug log might reveal something. I dont have a J-Link so I can't test it.
I did load the test-ram.elf on my STR-P711 with a ftdi interface and thats works OK. Just out of curiosity, does the test program run ? It seems strang to load the vector table at 0x200001cc . Vector tables are usually placed at the beginning of memory or at an address aligned to a larger power of 2. Regards, Magnus Michael Fischer wrote: > Hello Magnus, > > >> Do you know if this is an OS X, gdb, J-Link or general OpenOCD problem ? >> What happens/does not happen when you try to download ? >> > I think this is an OpenOCD problem with the jlink interface. > > I have make some test, compared against a FT2232 device working under > Mac OS X. > > Here I have used the GDB-6.8, and load the test_ram.elf. The command line > look: > > arm-elf-gdb -x ./prj/hitex_str7_ram_oocd.gdb test_ram.elf > > Attached is the elf and gdb file too. > > In the GDB window I get the information that the following addresses was > used: > > (gdb) load > Loading section .text, size 0x1cc lma 0x20000000 > Loading section .vectors, size 0x40 lma 0x200001cc > Loading section .rodata, size 0x4 lma 0x2000020c > > Now I take a look at these addresses: > > (gdb) monitor mdw 0x20000000 16 > 0x20000000: e1a00000 e1a00000 e1a00000 e1a00000 e1a00000 e1a00000 e1a00000 > e1a00000 > 0x20000020: e3a0020a e59f1104 e5801050 e3a0020a e3a01000 e5801044 e3a0020a > e3a01000 > > (gdb) monitor mdw 0x200001cc 16 > 0x200001cc: e59ff018 e59ff018 e59ff018 e59ff018 e59ff018 e59ff018 e59ff018 > e59ff018 > 0x200001ec: 20000000 20000118 2000011c 20000120 20000124 00000000 20000128 > 2000012c > > (gdb) monitor mdw 0x2000020c 1 > 0x2000020c: 00000007 > > Here I could found some data. You can find the log in the jtagkey.txt > > Now the same procedure with the jlink, here the log can be found in > jlink.txt > > At the address of 0x20000000 other information can be found: > > (gdb) monitor mdw 0x20000000 16 > 0x20000000: 00000007 2000012c e59ff018 e59ff018 e59ff018 e59ff018 e59ff018 > e59ff018 > 0x20000020: 20000000 20000118 2000011c 20000120 20000124 00000000 00000007 > 2000012c > > Here it looks thet the last 0x0000007 from address 0x2000020c was written at > 0x20000000. > But this is only a assumption. If I try to check the address 0x20000000 > again: > > (gdb) monitor mdw 0x20000000 16 > 0x20000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff > ffffffff > 0x20000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff > ffffffff > > I got other data. > > Do you have a hint for me what can I check to provide more information? > > Best regards, > > Michael > > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
