We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi All,
Apologies because the same (or at least similar) topic has already been asked in http://www.keil.com/forum/19204/ , but for some reason it's impossible to post a reply there (thread declared as "Read-Only").
Marc Crandall never got an answer for his question:
> Am I correct in thinking that I should be able to add breakpoints to the code in external NOR? <
I am facing a similar problem: LPC1788 (Cortex-M3), toochain MDK-ARM Version 4.22a . Target is an LPC1788 with both external SDRAM (32 bit wide) and external Flash (16 bit wide).
Breakpoints in internal Flash: No problem Breakpoints in external Flash don't work.
Single-stepping over an instruction which 'jumps' from internal Flash into external Flash causes the debugger to lose control, i.e. no more single-step. I can stop the debugger after that, and see that the CPU executes the proper code in external Flash (actually a custom bootloader).
Suggestions ?
All the best, Wolfgang .
Hi Erik,
After working on another project, I returned to the LPC1788 now and found:
Your assumption is correct. Of course the EMC (External Memory Controller) must be initialized before using the external FLASH (and external RAM, too). This is something the debugger "doesn't know".
> just for kicks, try to set a breakpoint in external flash when stopped on a breakpoint in internal flash after all initialization has finished. <
Indeed, the debugger must be stopped before I can set a breakpoint in EXTERNAL memory. Furthermore, it must be stopped *after* the application (my startup) has initialized the memory.
After that, a breakpoint can be set in external memory, and it really fires when the application "gets there". So, after all, it's a bit inconvenient but it can be done. My workaround is to locate modules which must be debugged in INTERNAL FLASH (even if in the final release they don't belong there), which allows setting breakpoints on-the-fly, without stopping the target.
All the best, Wolf .
Hello,
I have the same problem: Not possible to set breakpoints in ext. memory. So I talked a lot with the Keil / ARM support. Result:
It is not possible to set breakpoints (exactly Hardwarebreakpoints) in ext. memory.
Why: Look at: silver.arm.com/.../download.tm
ARMv7-M Architecture Reference Manual -> Debug Architecture -> Flash Patch and Breakpoint unit -> FPB unit operation
The Cortex-M3 have a limit with breakpoint above 1GB (0x4000 0000). But the LPC17xx include all extern Memory with addresses above 0x8000 0000! So there is no chance to set Hardwarebreakpoints in ext. Memory!
So there is only one way with "Softwarebreakpoints". Keil tools (Ulink2 und UlinkPro) don't have. Seggers "J-Trace for ARM Cortex-M3" debugger with the Softwarebreakpoints option doesn't work at the moment (there is still a request). The Lauterbach support answered very fast and told me there can (but I don't test it because I don't have one).
So this is the biggest FAIL of the LPC17xx especially with the old LPC2468 there was no problem! Unbelievable but true! Best regards
John