Finally, I found the cause of my GDB errors. :-) GDB was masking the high 16
bits of the address as the remoteaddresssize was set to 16 bits. I set it to
32 in my .gdbinit script and everything works fine now. Did no one else face
this problem earlier? The "show architecture" command on my gdb console
gives "The target architecture is set automatically (currently arm)". Did
you set remoteaddresssize paramater in your .gdbinit or did you use some
other parameter?
Now, I just have to figure out if it is possible to halt the target right
out of reset.
-Rahul.
On Fri, Dec 5, 2008 at 12:41 PM, Rahul Balani <[EMAIL PROTECTED]> wrote:
>
> When you use "reset halt" - OpenOCD stops the CPU at the reset vector, ie:
>> 0x00000000
>> (or 0xffff0000 depends on the chip)
>>
>> thus, you cannot access sdram until you use a series of "mww ADDRESS
>> DATA"
>> to configure the sdram, and example of this can be found in
>>
>> ${INSTALLDIR}/lib/board
>> - at91rm9200-dk.cfg
>> - eir.cfg
>> - hammer.cfg
>>
>> What is missing is the one for your board.
>
>
> I understand that if I use "reset halt" and then try to access any part of
> SDRAM without initializing it using mww commands, I will get a write abort.
> But, the log in my previous post just showed how openocd crashed right after
> issuing "reset halt". I did not even _try_ to access SDRAM through the .cfg
> script, gdb or telnet interface! So, the point is that the target could not
> be halted right after reset. I read the "reset config" section from the
> openocd manual and will look into the i.mx21 and the board (CSB735)
> reference manual to see if I can find something about srst and trst signals
> for the processor or the board. BTW, is the Olimex ARM-USB-OCD schematic
> available online?
>
>
>>
>> =======================
>>
>> rahul> (gdb) set *(0xC0200000)=5
>> rauhl> [above does not work]
>>
>> Don't forget the "mon mww 0xc0200000 5"
>>
>
> Yes, I tried this command and it worked, however the "set" or the "load"
> commands from gdb do not work. See the log snippet below:
>
> (gdb) mon resume
> (gdb) mon halt
> target state: halted
> target halted in ARM state due to debug-request, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0xc8025c28
> MMU: disabled, D-Cache: disabled, I-Cache: enabled
> (gdb) mon mww 0xC0200000 2
> (gdb) set *(0xC0200004)=3
> Cannot access memory at address 0xc0200004
> (gdb) mon mww 0xC0200004 2
> (gdb) mon resume
>
> I was able to verify from the serial console (see below) that correct
> values were written into the above memory locations using mww commands.
>
> uMON>dm
> 0xC0200000
> c0200000: 02 00 00 00 02 00 00 00 31 4c 4c ce 33 c4 ec ec
> ........1LL.3...
> c0200010: 33 ec cc ed 33 4c cc c4 33 cc dc cc 33 cc cc cc
> 3...3L..3...3...
> c0200020: 33 cc cc cc 33 c8 cc cc 33 cc cc c8 33 cc cc cc
> 3...3...3...3...
> uMON>
>
> Can you please send me an openocd log file showing a successful set/load
> into memory using gdb? I want to see the format of X-packets sent and the
> openocd response. Maybe its a memory map problem that makes gdb send the
> address as 0x0 instead of 0xC0200000.
>
> Thanks,
> Rahul.
>
>
>> Hmm, can you try other memory locations.
>> ie: the UART....
>>
>> you should be able to write to the data register and see a byte come out
>> on (hyperterm) or type a key on (hyperterm) and see the RXREADY bit set to
>> true, and if you display the rx data register, then display the status bit
>> again - the RX READY should go away.
>>
>> ====
>> end
>> ====
>>
>> -Duane.
>>
>>
>>
>
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
