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 .
Greetings all,
Just in case anybody still reads this thread:
I finally managed to get my 'large' project for the LPC1788 running ('large' because a part of the code resides in the LPC's internal FLASH, but a large portion is stored in EXTERNAL Flash).
There was a huge number of pitfalls. Here just the most important ones, maybe useful for fellow developers:
- forget about executing code in external FLASH memory. Instead, locate everything which doesn't fit into internal FLASH into the external FLASH, modify your startup to initialize the external SDRAM (which you will definitely need for a large project anyway) early enough - before the scatter-loading thingy hidden in __main tries to copy parts of the executable code from external FLASH (ROM) to external SDRAM.
- Also beware of the MPU (memory protection unit). By default, it prevents execution of code in external SDRAM. Details at " while debugging. They just happen, especially when the debugger tries to access memory which your own startup hasn't initialized the EMC (static and dynamic memory controllers).
- Turn off memory display windows if you don't need them while debugging. They tend to make the debugger painfully slow, especially when the debugger periodically tried to read memory areas which are not accessable at that moment (for various reasons).
- Keep the serial interface accessable. While developing your own startup, you will sometimes have to "rescue" the board with NXP's FlashMagic ("Erase All") because the JTAG debugger is unable to access the board (reprogram or start debugger session), if your code "does something wrong very early". Add a delay loop shortly after 'Reset_Handler', and make sure that delay loop doesn't access anthing placed in EXTERNAL memory by the linker (the loop will crash because in Reset_Handler the external memory will not work yet).
If you still have the choice between 16- and 32-bit data bus for the SDRAM, and need to drive a large TFT (800 * 480 pixel in my case), go for 32 bit. Otherwise the maximum framerate may be too low, and the framebuffer access eats up most of the available bandwidth of the external memory interface.
Good luck, Wolf .
I work with ST, not NXP, but with the ST external flash must be enabled before its use. Thus any attempt to set a breakpoint in external flash before it is enabled will fail. I do not have code in external flash, just data, but any attempt to do anything there before the enable routine has processed (i.e., in my case, after the initializations in main() has finished, is futile.
just for kicks, try to set a breakpoint in external flash when stopped on a breakpoint in internal flash after all initialization has finished.
Erik
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