Hi,
I am haveing trouble with an LPC-E2124. Whenever I give it power from a 5V power source I have to use the physical reset button to make the code start, but when I apply power from using the USB connection it restarts just fine which leads me to believe the code is fine. Any help would be appreciated.
Do you have the jumper “JRST” in or out ?
It might be the slow rise time of the power supply that is causing the problem. A proper reset chip should help, but you will probably have to redesign the board.
Leon
I have the JRST jumper in to have it reset with the USB power, but I have tried both with the 5V power supply.
Can you explain your situation a bit more.
Do you mean after you flash the device and apply USB power it boots ok, but when you apply 5v you have to press the reset button to start?
Or do you mean that after flashing the unit with 5v supply you have to press the reset button to start it, but do not with USB power?
Okay,
After I have the program flashed onto the device whenever I take power from it and give it power again from a USB source, it restarts on its own just fine. But when I give it power from a 5V power supply I need to hit the physical reset on the board.
ya, you see the FT232BM chip is connected to the Reset pin of the ARM.
when you connect power to it, the USB IC tickles the RESET line.
However, if powered from 5V source it cannot do this.
you could tie a 3 pin (power, gnd, Reset out) Reset device onto the board to solve this problem. for now you may want to try making C8 a bit larger. Say something on the order of 10uf.
Okay, looking at the schematic one more time I see the RST connection. If that is the case then I will need to check Rowley’s website one more time to see if I can do a software fix before I add a reset circuit. Thanks for everyone’s help.
Oh ya, Rowley’s has a solution for it.
you need to do the following…
STARTUP_FROM_RESET has not been defined when assembling the startup code. Some versions of the ARM startup code won’t start up the application from reset by default, this is to workaround problems with the ARM reset by allowing the debugger to reset the CPU and run programs from a known reset CPU state on each run. Not allowing the application to startup from reset also acts as a safety net if you accidently download a program in FLASH that crashes and prevents the debugger from taking control over JTAG rendering the target unusable over JTAG. To define STARTUP_FROM_RESET select the startup code in the the project explorer, right click, select Properties and then add STARTUP_FROM_RESET to the Preprocessor > Preprocessor Definitions project property.
I saw that a while ago and had tried it but it looks like it’s for reset in general. I believe that you have to define STARTUP_FROM_RESET in the Preprocessor Definitions to simply be able to start your controller by hitting the reset button. The problem seems to be that powering the device with a 5V supply never toggles the reset. But I don’t know if the controller needs the reset signal to start or if the processor starts running when it gets power.
well, put a small reset device on the reset pin and your problems will be solved.
---------------------------------------------------------asmodean989:
I saw that a while ago and had tried it but it looks like it’s for reset in general. I believe that you have to define STARTUP_FROM_RESET in the Preprocessor Definitions to simply be able to start your controller by hitting the reset button. The problem seems to be that powering the device with a 5V supply never toggles the reset. But I don’t know if the controller needs the reset signal to start or if the processor starts running when it gets power.
Modern CPU has BOD ( Low voltage = turn off CPU)
CPU needs to have Vcc applied full up and fast .
First hardware problem solved .
Loader must not have “control” or selection ,
embedded , so its difficult for you to change
your mind , when you boot ARM .
Dont allow Loader to make decisions in firmware
to “select” debugger or other .
Loader must select ( I.E. UART0 , then USB , then SD card )
but exhaust those and lastly , read mobo switches .
This way , you can remove your h/w and
wait for Loader to exhaust , then you gain control
thru the mobo switches/keyboard .
Now key in “peek” to get error code .
INT to your keyboard if
Loader error .
Peek some error codes
Use a part of ROM to store 10kB Forth .
Now you can debug in Forth from Keyboard .
Forth is asmbler/disassembler/debugger .
This is a new method , faster to debug BootUp .
It can be used at all s/w levels , even debug
a Linux kernel . You simply chain INTs and
the INT takes control , allows your low level
keyboard . Its hacker …