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.
I have seen quite a few people reporting similar problems in the forum but very few of the posts had any response or had useful information. Any help anyone can provide would be appreciated.
I am getting the “cannot access memory” error as soon as I try to program the flash or enter debug mode. This just started after using uVision/ULINK2 for a day with a couple of dozen compiles & downloads that worked fine. I made a change to the code and started getting this error when trying to go into the debugger.
If I use Flash Magic to erase the flash I can program the micro once but then get the error after that. If I use Flash Magic to erase and program the micro the code executes properly. In the debugger I can’t seem to be able to set breakpoints or single step the code when it was programmed through Flash Magic or that would at least be a painful work around. It almost looks like a code protection problem but I’ve verified in the hex file that the CRP location contains the value I set in the startup.s file (either all 1’s or all 0’s). I've also verfied in the .map and .hex files that I'm not trying to put code in non-existant memory.
This is my setup: - LPC1774 on custom board, using internal Flash for code, have SDRAM but can’t get to the point of initializing it - uVision 4.70 - ULINK2 (don’t know firmware version but it was upgraded when uVision 4.70 was installed) - Problem happens using JTAG or SWO
I’ve restarted and even re-installed uVision. I created a new project and copied all my source files (but no uVision project files) and was able to program the device once but got the error when trying to go into the debugger or re-program the micro.
Note that it is a common issue that "bad code" can deactivate the JTAG interface.
So when writing code that is intending to play around with the clocking of a processor, a "good" program should have some dummy code that introduces a suitable delay before starting to play with the chip configurations.
In case the code is bad and locks up the JTAG interface, then you can reset the chip, and have the JTAG interface lock on and pick up the processor before it has time to reach the buggy code.
The code protect bytes doesn't do anything to protect the chip. All they do, is to instruct the internal boot loader to your wishes. So that boot loader can look at the code protect value and decide to ignore accepting commands on the serial port after boot. And the boot loader can decide to deactivate the JTAG interface to block external debugging.
But just as the internal, factory-supplied, boot loader can disable the JTAG interface, your own code can also manage the same feat.
If you can store a minimalistic program that flashes LEDs without breaking the JTAG interface, then try to bring in more and more code and see where it starts to fail.
Per, thank you so much for your help. I had a problem in the code that setup the PLL that killed the clocks. I was selecting the external oscillator which isn't populated on the board yet. Doing a reset would re-select the IRC as the clock source which is why the error wouldn't be reported sometimes. Thanks again.