问题描述

我终于(用户代码从 0x2000 开始)会影响这些调试设置中的任何一个吗?

更新:听从 dwelch 的建议，我确实设法让一些基本的 OpenOCD 命令正常工作(reset init、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 命令行(类似的东西)

在 Telnet 会话中:

<代码>>停>mdw 0x0000

以及类似的东西，以查看您正在与该部分交谈.

如果您已经编译了一些程序，您可以简单地加载并运行它们，例如，如果您制作了一个仅 ram 的程序(告诉链接器 .text、.data 等都在 0x10000000)那么

<代码>>load_image/path/to/myprog.elf>恢复 0x10000001

(是的，加 1 使其变得奇数，这是一个拇指处理器不会运行 ARM 指令(lsbit = 0 是手臂模式 lsbit = 1 是拇指模式).

重新编译后重新运行:

<代码>>停>load_image/path/to/myprog.elf>恢复 0x10000001

然后，在基于 ram 的程序显示出生命迹象后，请担心闪烁等问题.

如果这些都不起作用，那么 gdb 只是在此之上又增加了一层复杂性，并且会使其更难弄清楚.

就引导加载程序而言，答案取决于您是尝试从 ram 运行还是从程序运行到 rom.如果从 ram 运行，您可以接管系统并占用所有 ram，一些芯片 (stm32) 有一些您可以调用的例程，这些例程需要一些 ram 不受影响，但如果您要接管芯片，您可以拥有所有 ram，如果它不知道二进制文件(使用elf文件或ihex或srec或几乎任何不是.bin的东西都很好，如果工具支持它)，这是一个告诉链接器和调试器的问题.

如果您要写入闪存，那么您最好确切地知道闪存的哪一部分可能包含引导加载程序，引导加载程序如何将您的代码移交给您的代码，等等，并再次告诉链接器和调试器这些信息.您可以轻松擦除/删除引导加载程序，具体取决于引导加载程序的位置和您正在执行的操作(这些 lpc 和 st 部件中的许多都有引导加载程序、串行或 USB，它们在一定程度上可以防止偶然错误，但您通常仍然可以擦除它们并如果您不小心，请更换它们.

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).