Eclipse GDB“init”和“运行”使用OpenOCD的ARM LPC1768的设置？ [英] Eclipse GDB "init" and "run" settings for ARM LPC1768 using OpenOCD?

问题描述

我终于（用户代码从0x2000开始）会影响任何的这些调试设置？

更新：采取dwelch的建议，我确实设法使一些基本的OpenOCD命令工作（重置初始化， mdw ， mww ， load_image 等）。奇怪的JTAG-DP STICKY错误是我的ram链接描述文件，发现一个项目模板LPC1758 ， RAM链接描述文件，只是不得不修改LPC1768和load_image的内存大小。

我仍然想知道如何正确配置eclipse用于GDB调试。

解决方案

也许一次尝试一步。

启动openocd，可能是像-f interface / jlink.cfg -f target / lpc1768.cfg这样的东西，听起来像你这样工作。

第二个telnet localhost 4444或任何Windows命令行（类似的东西）

在电话会议中：

 >暂停
> mdw 0x0000 
  

和类似的东西，看到你在说话。

如果你已经编译了一些程序，你可以简单地加载它们并运行它们，例如，如果你制作一个只有ram的程序（告诉链接器.text，.data等都是0x10000000 ）然后

 > load_image /path/to/myprog.elf 
>简历0x10000001 
  

（是添加1，使其奇怪，这是一个拇指处理器不运行ARM指令lsbit = 0是arm模式lsbit = 1是thumb模式）。

重新编译后重新运行：

 > halt 
> load_image /path/to/myprog.elf 
> resume 0x10000001 
  / pre> 
 
 
然后担心闪烁等等，你有基于ram的程序显示生命迹象。
 
 
 
如果没有一个是工作，那么gdb只是一个更复杂的水平，这将使得更难找出。
 
 
 
就引导程序而言，答案是这是否要从ram或程序运行到rom。如果从ram运行，您可以接管系统并使用所有ram，某些芯片（stm32）有一些可以调用的例程，那些需要一些ram不要触动，但如果你接管芯片，你可以拥有所有的ram，这是一个告诉链接器和p也许调试器如果不知道从二进制（使用elf文件或ihex或srec或几乎任何不是.bin的东西，如果该工具支持）。 
 
 
 
如果您要写入闪存，那么您最好知道Flash的哪些部分可能包含一个引导加载程序，该引导程序可以将其移交给您的代码等，并再次告诉链接器和调试器这个信息。您可以根据自己的位置和您在做什么（很多这些lpc和st部件有引导程序，串行或usb，有些保护免受错误的擦除/垃圾邮件），但您仍然可以通常擦除它们，如果您不小心，请更换它们。）
 
 
 
几小时之前，我刚刚从亚洲eBay获得了一个el-cheapo lpc1768板，我完全按照我上面描述的方式进行操作。关注github用户dwelch67，大概在mbed_samples如果不是lpc1768_samples，如果我创建一个通用的，我最终将有样例程序和说明，使用openocd加载和运行从ram以及写入闪存。
 
I finally figured out how to get code running on this LPC1768 mini board, however now I'm trying to get debugging working.

The toolchain I'm using is: Yagarto + Eclipse (Indigo) (w/ GDB Hardware Debugger) + OpenOCD. My JTAG interface is: Bus Blaster V2 board.

I found one guide that walks through a similar setup, but it's for a different JTAG interface so not very useful. There's also this post regarding an LPC1768 example, but the gdb commands aren't for OpenOCD.

At this point the only command I know for sure (for init) is target remote localhost:3333 (for connecting to the OpenOCD gdb server).

What settings and gdb commands should I be using in this dialog?



(Ignore  the "SAM7X256", just re-using a screenshot from one of the above links. I'm using an ARM LPC1768)

Also, does the fact my board uses a secondary bootloader (user code starts at 0x2000) affect any of these debug settings?

UPDATE: Taking dwelch's advice, I did manage to get some basic OpenOCD commands to work (reset init, mdw, mww, load_image, etc). The weird "JTAG-DP STICKY" error was something with my ram linker script, found a project template for the LPC1758 with a RAM linker script, just had to modify the memory sizes for the LPC1768 and load_image worked great. 

I'd still like to know how to properly configure eclipse for GDB debugging though.
解决方案
Perhaps try one step at a time.  

Start openocd, probably something like -f interface/jlink.cfg -f target/lpc1768.cfg  or whatever, sounds like you have that working.

second telnet localhost 4444 or whatever the windows command line is (something similar)

WITHIN THE TELNET SESSION:
> halt
> mdw 0x0000
and stuff like that to see that you are talking to the part.

if you have already compiled some programs you can simply load them and run them, for example if you make a ram only program (tell the linker .text, .data, etc are all at 0x10000000) then
> load_image /path/to/myprog.elf
> resume 0x10000001
(yes add 1 to make it odd, this is a thumb processor wont run ARM instructions (lsbit = 0 is arm mode lsbit = 1 is thumb mode).

To re-run after re-compiling:
> halt
> load_image /path/to/myprog.elf
> resume 0x10000001
then worry about flashing, etc after you have ram based programs showing signs of life.

If none of that is working then gdb is just one more level of complexity on top of that and going to make it harder to figure out.

As far as the bootloader goes, the answer is it depends are you trying to run from ram or program to rom.  If running from ram you can take over the system and take all the ram, some chips (stm32) have some routines you can call and those require some ram to be untouched, but if you are taking over the chip you can have all the ram, it is a matter of telling the linker and perhaps the debugger if it doesnt know from the binary (using elf files or ihex or srec or pretty much anything that is not a .bin is good, if the tool supports it).  

if you are going to write to flash then you had better know exactly what portion of flash might contain a bootloader, what that bootloader does to hand off to your code, etc, and again tell the linker and the debugger this information.  you could easily erase/trash the bootloader depending on where it is and what you are doing (a lot of these lpc and st parts have bootloaders, serial or usb, that are somewhat protected from casual mistakes, but you can still usually erase them and replace them if you are not careful).

I just got an el-cheapo lpc1768 board from asia on ebay that hours ago I did exactly what I am describing above.  Keep an eye on github user dwelch67, probably in the mbed_samples if not a lpc1768_samples if I create a generic one where I will eventually have sample programs and instructions for using openocd to load and run from ram as well as write to flash.

                        
这篇关于Eclipse GDB“init”和“运行”使用OpenOCD的ARM LPC1768的设置？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！