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 .
Would you mind sharing your flash.ini file for programming the external flash. We are evaluating the LPC1788 device with hardware developed for the LPC2478 (supposed to be drop in electrically).
I have developed a small blinky program that operates from internal flash and uses external SRAM (Cypress CY7C1061) with no problems. When i try to move to external flash and use an adjusted flash.ini file and updated .flm file for our external flash (Spansion S29GL128), the flashing seems to run with no problem to verification where it errors out with "Contents missmatch at: 80000000H (Flash=FFH Required=6EH)!" (and continues for 63 more locations).
I would like to see if i am doing something wrong in my ini file. If i can get my program to external flash then i will test the debugging from ext flash and report back.
Thanks,
Lee
Hi Lee,
I tried to send my XFlash.ini file but this forum-thingy rejected the message because it was longer than 7000 bytes.
I am not too familiar with this forum - is it possible to send attachments, or is there a 'files' sections somewhere (as in most yahoo groups) ?
Regards, Wolf .
I have uploaded the external flash initialisation file (for uVision / uLink) to this temporary folder.
www.mkt-sys.de/.../lpc1788_external_flash_init_script.txt
(the file will be removed in a couple of days, it's just a temporary storage)
I don't think the bug is in this script, because programming and verifying works as it should. I can also access DATA in that area (through the debugger, but also from the LPC during runtime).
Cheers, Wolf .
Thanks Wolf,
Your ini file pointed me in the right direction. I am now able to download to the external flash.
I have tried to reproduce your problem, single stepping into the external memory. I can single step from internal to external across the memory boundary with no problem. However when I try to set a breakpoint in the External Flash, I get a dialog box with the following text: "This target device does not support all the defined breakpoints! Please reduce the number of breakpoints and start again."
This message is produced even when the only breakpoint I am trying to set is in external memory.
I can set breakpoints in internal flash and debug but definitely not external flash. The code is definitely in and running from the external flash though.
Hello Lee,
Thanks for testing. I get the same error here, "device does not support all the defined breakpoints", even though not a single breakpoint has been set.
It's interesting to know that you can step from internal into external memory. That doesn't work here- the debugger immediately quits when trying. So there must be some other problem here. Maybe because the project was once written for the LPC2478, and then carefully(!) modified for the LPC1788 by editing the *.uvproj and *.uvopt with a text editor (which is something that Keil surely doesn't recommend, but I didn't want 'click together' a brand-new project since there are hundreds of sourcecode modules in my project). Of course the startup files were replaced, scatter loading file adjusted for the new target, etc etc.
I will keep trying.
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