Debugging RTEMS application for zedboard

Chris Johns chrisj at rtems.org
Wed May 31 02:08:56 UTC 2017


On 29/05/2017 22:53, Gabriel Brusq wrote:
> 
>>> I compiled rtems-4.11-gdb and I am able to use XMD with gdb (target remote)
> 
>> Excellent. I have not used XMD.
> 
>>> I can debug step by step rtems' helloworld example and continuing until relatively near breakpoints
> 
>> I am not sure I understand.
>>
>> After loading the executable you get a gdb prompt at the entry point to
>> the RTEMS executable? Do the instructions at the entry point match what
>> you expect to see?
>>
>> If you then ...
>>
>> (gdb) display /x $pc
>> (gdb) si
>> (gdb) si
>>
>> .. you can step the instructions?
> 
> Yes the instructions match what expected at the entry point
> and I can step the instructions with no error.
> 

Good.

>>> But when I try to continue until far breakpoints there is a target crash which seems to be linked to JTAG buffer.
> 
>> The JTAG hardware does not have a buffer anywhere in the chain so this
>> must be something in the XDM software.
> 
>>> -- What I've done
>>>
>>> - xmd side:
>>> XMD% connect arm hw
>>> XMD% rst -system
>>> XMD% fpga -f /root/workspace_brusq/xsdk/hw_platform/zynq_design_wrapper.bit
>>> XMD% source /root/workspace_brusq/xsdk/hw_platform/ps7_init.tcl
>>> XMD% ps7_init
>>> XMD% ps7_post_config
>>> XMD% ps7_debug
>>> XMD% dow /root/workspace_brusq/rtems_gdb_hello_C_CortexA9_RTEMS.exe
>>>
>>> - gdb side:
>>> $> cd $EXE_DIR
>>> $> arm-rtems4.11-gdb rtems_gdb_hello_C_CortexA9_RTEMS.exe
>>> (gdb) target remote tcp:132.149.33.111:1234
>>> (gdb) load $EXE_DIR/rtems_gdb_hello_C_CortexA9_RTEMS.exe
> 
>> Does GDB load the executable, if so do you need the XDM dow command?
> 
> If I try to load the executable from gdb without the dow command executed from XMD before, I get:
> Loading section .start, size 0x3b8 lma 0x104000
> /users/ext3/.gdbinit:2: Error in sourced command file:
> Load failed
> 
> (However, after XMD dow command the gdb load is not necessary)
> 

This seems wrong. GDB should be able to write to the DDR memory, it 
needs to do this so breakpoints work. You could limit your focus to 
hardware breakpoints but this is a limited resource.

I would investigate why this is happening.

> 
>>> -- Whet I get when continuing without breakpoint
>>>
>>> - xmd side:
>>> Processor Stop Condition Unknown
>>> Error:
>>>         Cannot access JTAG-DP: invalid ACK value (0x04, expected=0x02)
>>> OR
>>> Cannot flush JTAG buffers
> 
>> Do you have any watchdogs enabled?
> I've tried several values for watchdog, the error remains the same

Disabling it is all that is needed.

> 
> 
>> If there is a memory map, MMU or something similar an early crash can be
>> fatal and JTAG will not be able to recover if something low level on the
>> bus has locked up.
> 
>>> - gdb side:
>>> Continuing.
>>> Remote failure reply: E01
>>> Remote failure reply: E01
>>> Remote failure reply: E01
>>>
>>> Can this error be linked to RTEMS
>>> or should I continue this topic on Xilinx page ?
> 
>> It seems sort of normal for a low level bring up of new tools and hardware.
>>
>> I suggest you test the stepping as I listed before for say 20
>> instructions and then reset reload and issue:
>>
>> (gdb) x /100i $pc
>>
>> and setting a breakpoint inside the range of instructions you stepped
>> before. To set a break point at a specific address use:
>>
>> (gdb) b *0x12345
>>
>> where 0x12345 is the address you want to stop at. If the board fails on
>> the continue and does not break it would seem XDM related. If the
>> breakpoint is hit and gdb stops then it is something further in the
>> start up sequence you need to find.
> 
> I already tried to place breakpoints before the some further instructions reached while stepping.
> Then when I'm continuing from beginning, some breakpoints are reached while others are not (JTAG error occurs before).

If you cannot write to the executable's memory breakpoints will not work.

> According to what you said it seems to be an XMD related error, I will focus more on this point

It seems you are close. It looks like an XDM configuration error of some 
sort. I wish Xilinx would make the XDM process more transparent so we 
can see what it is actually doing. For example, the dow command can 
write to memory so what else is it doing that is not available when 
using gdb?

Chris



More information about the users mailing list