The manual says that if p0.14 is low while reset is low, forces on-chip boot-loader to take over control of the part after reset. However, when I connect this pin to ground, while the user code is executing (Blinky), the program stops! When I connect it to the 3.3V pin on the motherboard, Blinky starts running again! And all this time reset is never low. Is this supposed to happen? It doesn't seem so according to the flowchart in the manual.
See this:
UM10139 Chapter 21: Flash memory system and programming Rev. 02 — 25 July 2006 User manual LPC214x
Page 295.
A a LOW level after reset at the P0.14 pin is considered as an external hardware equest to start the ISP command handler.
Pin P0.14 that is used as hardware request for ISP requires special attention. Since P0.14 is in high impedance mode after reset, it is important that the user provides external hardware (a pull-up resistor or other device) to put the pin in a defined state. Otherwise unintended entry into ISP mode may occur.
That's a low level immediately after reset, right? I fiddled with the pin minutes after reset was low- isn't the pin state checked only immediately after reset?
The pin informs the boot loader to activate software download mode if held low when the reset signal is released. This function can be disabled by using one of the higher code-protect modes, in which case you will only manage to enter the software download mode if your own program internally jumps to the NXP boot loader.
But the pin is also a normal GPIO pin. And it can be configured as an external interrupt pin. If configured as external interrupt, then the program must have a working interrupt handler to make sure that the program doesn't locks up when you draw the signal low.
Another thing is - as mentioned - that that the chip has a weak pull-up. In a noisy environment, you may have to add external pull-up to reduce the risk of falsely trigging an interrupt.
But I haven't configured it as an external interrupt. It's behaving as if reset is perpetually low and I am sure it's not.
I'll describe what I did in detail:
1. Blinky is running 2. I connect p0.14 to ground 3. I reset, and the program stops 4. Now I connect p0.14 to a 3.3V pin, and Blinky starts running again, without having pressed reset 5. From now on I can start or stop the program by connecting p0.14 to 3.3V or ground, without using reset
What's happening?
PS - I am a beginner
If reset is perpetually low, then it will not matter what you do with any other signals - as long as the reset signal is active, no program will run.
As soon as reset is released, the NXP boot loader will run. It will sample the p0.14 pin and the code protect mode and it will compute the checksum for the interrupt vector table.
If the flash is considered empty (incorrect checksum for the interrupt vector table) it will enter programming mode.
If p0.14 is activeated and code protect allows it, it will enter programming mode.
But as soon as the NXP boot loader has jumped to the end-user program, p0.14 will be a pin just like every other pin on the processor. There is no special hardware involved with p0.14, so there is nothing magically happening at any time. If the program fails when p0.14 gets held low after your program has started, then there are a couple of choices: - your program has a bug - you have floating processor pins, making other signals also changing state - and you have a software error related to these other signals, or maybe it's the reset line that is floating. - you have a hardware error on the board - a solder bridge or similar - that results in a short of supply voltages, reset line or similar when you draw p0.14 low. - your chip is not correctly flashed, so in some situations the processor will reach invalid code.
Anyway - as soon as your program has started, there is nothing special anymore with p0.14, so it's a standard search for sw or hw errors.
If using a JTAG interface, you should be able to see if the program gets stuck in any infinite loop somewhere - for exampple in an exception handler after having accessed an invalid or unaligned memory address or having processed an invalid instruction.
You can also try to reduce the size of your code - just limiting it to a minimalistic main loop that flashes a LED but doesn't do anything else. If the problem goes away, you can try to add in more and more of the original code.
Just a quick footnote based on your last post.
Are you really sure that your "blinky" is blinking because the program is running as expected? Maybe the program is constantly being reset, so your program turns on the LED and then get reset so the LED is turned off. Then boots again and lights the LED.
If you for some reason gets a repetitive reset of the chip, it will look like the program is working and blinking the LED while p0.14 is held high. But as soon as p0.14 is held low, the next reset of your program will result in the NXP boot loader sampling p0.14 again.
Do you have enough power to the board, so you don't get a reset from any supervision chip? May you have the watchdog enabled but failing to kick the watchdog? Is there any possibility that the main loop may exit, so your program leavles main()?
What have you done to verify that your program really continues to run? Do you have multiple LED, so you can let the individual LED display a ticking counter? Or what happens if you let the program gradually change the blink frequency by either increasing or decreasing the delay time for each new iteration?
Gaah, I found the problem >.< ... the manufacturer has incorrectly labeled a ground pin, it's actually 5V. I've been giving a 5V input to p0.14, thinking it's 0. Can these pins handle 5V? Then too, I'm sure it's a hardware problem, the software is just Blinky, it's flashing LEDs connected to pins 1.17 to 1.20
Thanks for your reply Per, The Blinky is the same as the example code given in Keil Examples, except I am only blinking pins 17-20 instead of 16-23.
=:0
I hope you've fed that back to the manufacturer!
I have to find him first! @Andy Sorry to post this in this thread, but is the LPC2148 a good 'beginner' chip? (I found it lying around) By beginner I mean I already knew C (though not embedded C), but basically learned assembly etc through the net in the past 2 weeks. And I can't find a decent usb bootloader (it's a pain to flash through serial port, I need to use a usb-serial port converter) I don't understand, why doesn't it come preloaded with a usb bootloader?
Good that you found the problem.
I think it's a good beginner chip. LPC23xx would be even better, but LPC21xx is also quite nice.
The chip manufacturer is NXP - or is it on a board that's mis-labelled?
"I found it lying around"
That's never a good way for a beginner to start! It might have been left lying around because it was faulty; It might have been damaged whilst lying around; etc, etc,...
For a beginner, I'd recommend that you start with a proper kit - then at least you should be fairly sure that you have working hardware.
I'd also recommend that you choose a complete kit; ie board, tools, debug adaptor, tutorials, samples, etc all bundled. Then, again, you should be fairly sure that everything should work together, and you don't have to mess about trying to gather a compiler from here, and a debugger from there, and some patches from somewhere else to make it all work, and examples that refer to features you don't have...
Personally, I found the Luminary Micro Stellaris kits very good (dunno if it's changed since TI bought them, though). They led the way with complete boards with integrated debug - many others now do the same.
If this is for work, then be careful to evaluate suppliers and ensure that they can provide you with adequate support.
Thanks Per and Andy!
The board is mislabeled @ Andy Andy yeah, I don't have a proper kit, I basically scavenged for compilers and debuggers and I am facing all the problems you have mentioned. Thanks for your suggestions, I will buy a complete kit.
Well, I found a brand new board (but from the same manufacturer) and tried a modified version of Blinky:
1. I blink 4 LEDs in succession, with the frequency increasing after each iteration in 10 steps, and then it repeats. Basically, 1>. I know the program is running and 2>. there isn't any problem of repetitive reset or 3>. of external interrupt.
2. My code does nothing to pin 0.14, so it is set to defaults, as a gpio, input direction.
3. I thought that by applying 5V to the pin something is going wrong, but now, I apply 3.3V and get the same problem!
I press the reset button and the program stops.
Now, I apply 3.3V to p0.14 and the program starts again...without pressing the reset button! On top of that, when I stop applying 3.3V to the pin and then start again, the program stops! And I can do this forever.
It seems to be a hardware problem, but can I be sure? It's a new board, but from the same manufacturer.
Here's a link to the schematic: rapidshare.com/.../arm_mini_sche.zip