rtel wrote on Friday, June 30, 2006:
>1) The project "rtosdemo_ARM" from
>the "ARM7_LPC2129_Keil" directory should run
Correct. The demo includes the startup code etc. required to run. All you should (in theory) need to do is compile and download. It has only been tested with the uLink debugger interface though. Although, the debug interface should not make a difference to the execution of the code.
When I have used a wiggler on an LPC device I was only able to download and execute the code from RAM. There was no way to set breakpoints when executing from ROM as far as I could see.
>2) Should the code start blinking LEDs to
>confirm functionality without needing to
>anything (once it is downloaded and running of
Yes - assuming you are using the same hardware so the LED’s are connected to the same port pins. The demo application functionality is described on the Keil/ARM documentation page of the FreeRTOS.org site.
Some debug interfaces will automatically set a break point at the code entry point or on main() so after downloading you will need to click ‘run’ before anything happens. Power cycling the hardware should always cause it to execute.
>3) Do I need to attach a hyperterminal-type
>program via a serial cable to the board? I tried
>this, and it didnt seem to help.
No. The demo contains a couple of tasks that communicate on the COM port but this requires a loopback connector rather than a connection to a dumb terminal. Not having the loopback connector in place will not prevent the code from executing though. Again the requires hardware setup is explained on the port documentation page.
>4) I tried using a .ini file to set the PC to
>0x0, load the image, run setup(), and go to main
>(similar to the .ini files used by the board
>projects that came with the compiler). Using
>this, the code actually lit P1.19 and P1.21-
>P1.23 (instead of having them all stay lit, as
>is the case when the board is powered up or when
>I run the demo app without the .ini), but again
>the code just seems to go off and get stuck in
>the weeds. Also in this case, I can’t see the
>code in memory.
The setup needs to:
+ Configure a Supervisor mode stack.
+ Configure an IRQ mode stack.
+ Set the processor to Supervisor mode before calling main().
Did you ini do this?
I would normally suggest cutting down the demo to its bare bones when having difficulties getting it up and running, but in your case it sounds like you are never even reaching main(). Can you set a break point in main before running the code?
Take look though the startup code and see if there is anywhere that the code loops waiting for something to occur in the hardware during the initialisation routine.