I'm using Yagarto/Eclipse/Flash Magic. I have a LPC1768 Blueboard. When I first got it, it had some kind of code on there that flashed the LED. I loaded my own code to do the same, and it now doesn't seem to be able to vector off and run. I talk to it through Flash Magic. I can talk to it through a serial terminal and issue the Synchronized and crystal commands, however I'm not seeing anything on the scope at the crystal, and the LED doesn't blink. In fact both LEDs seem to go to an intermediate state and I'm reading 1.7V. I haven't hooked anything up to the board that I would consider to have caused this. I tapped into the USB power (That is how I'm powering it, through USB) to get ~5V over to my level converter. I've uploaded another hex file I found on the web and it does the same thing. Is it how I'm using Flash Magic maybe? Is there another program I should try? It has worked for me in the past with the LPC2138. My experience with that chip was that when I fryed it, it was truly fryed and I couldn't load code or anything else. I'm getting a fresh board delivered today, but I don't want a repeat.
Since you can "talk" to the controller with FlashMagic I don't think you "bricked" the device. At least the UART and the internal clock-generation still work. Did your compare/verify after flashing? FlashMagic offers an option for this. If this works too I expect the problem is in the application code. I have not done much with LPC17xx and can not point you to a simple example. Did you ask the board-manufacturer or seller if they can send you just the hex-file of the preinstalled application for tests? Maybe the code gets linked for addresses in RAM. Double check the linker-script, startup-code and maybe the disassmebly (objdump). At least a minimal vector-table should be located at address 0. The first DWORD value in the table should be a valid RAM address since it's use as initial stack-pointer. The second value should be the address of the reset-handler. If you are using the CM3 systick, check if the 16th(IRC) value in the table is the address of the systick-ISR. You may also try with my SD-Card example, it's made for LPC1766 and includes a lot of code which is not needed for a simple test but at least a LED-blink is also included. You may have to change the LED-connection (Port, Bit) in the defines to reflect your board's hardware. I have tested with the GNU toolchain as in Codesourcery G++ lite for ARM-EABI but if you use the latest Yagarto-release (ARM-EABI target) there should be no changes needed to build the project with Yagarto too. http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html#chanfat_lpc_cm3
I'm getting the same results with you example. The only thing I changed were: 1) Call make instead of cs-make in Eclipse. 2) Change location of hex file in the flash magic settings along with the device type. I have not talked to the manufacturer, but I do have a fresh board here. I tried pulling the hex off that, but my test editor messed up the formatting I believe, and I couldn't get it on to the broken board. What I did notice, however, is that the board must stuck in reset. I say this because it behaves just as the new board does when I reset with BSL pulled low. I just have to figure out why I can't get it to vector off and do anything.
I also tried changing over the *.ld and *.cfg files that project to those created for the LPC1768. That just made a big mess. I have more learning to do.
I'm really perplexed by what's happening between the code and the hex file. I can compile your example above for the LPC1766, but that hex file does not get the chip out of ISP. I'm using the latest of : CodeSourcery/Eclipse/FlashMagic. I found another example project for the LPC1766 on the net, and that hex file works fine. On the other hand, I can't get that one to build. What could be causing this thing to get stuck?
KennyB wrote: > I'm really perplexed by what's happening between the code and the hex > file. I can compile your example above for the LPC1766, but that hex > file does not get the chip out of ISP. - Do you have something connected to the BSL pin (P2.10 IRC)? - IRC Flash magic has a checkbox to insert the correct checksum during the transfer. Is this option activated? It should be enabled by default. Application-code will not start if the checksum in the vector-table is not correct.
Hmmm, the checksum block is grayed out for me. A quick look at the manual doesn't make it obvious why that is the case. Anyways I finally got it working today. It seems like there are a lot of examples floating around out there that may indeed need that box to be checked. Thanks for your help.
You're program works great. I did not change the LED to values to match my board, and the LED was stuck in a half way state. This makes it appear as though the board is in ISP (same behavior, visually) I was able to start my own project based on your work, thank you.
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.