nobody wrote on Monday, June 26, 2006:
Hi,
When I try to run FreeRTOS + Demo apps on the Keil MCB2100, I get
some strange results that do not occur when I use simulation. In
particular, I get stuck around 0x7FFE252 in the dissasembly and it
just hangs in an infinite loop.
One thing to note is that I am using the H-JTAG debug agent:
http://hjtag.blogspot.com/. Do you think this has anything to do
with my problem?
nobody wrote on Monday, June 26, 2006:
Can you see what code it is in when it hangs, you only give the address.
This type of behavior is normally to do with setting up a clock. If the startup code attempts to setup a peripheral or clock, then polls for an acknowledgement. It can be due to the debug interface having set it up already.
nobody wrote on Monday, June 26, 2006:
Thanks for the help. I don’t see any C code when I view the mixed dissassembly. It gets stuck between the following two instructions:
STMVSDA r8, {r0,r2,r4-r6,r8,r11,r14}
LDRLEBT r0, [r12],#0x0780
Looks like some stack cleanup for a procedure call. The problem appears to be getting worse, as I cannot single step from address 0x0 any longer. It goes right into be stuck whether I run or step.
How do you stop the debug interface from setting up the clocks? SHouldn’t the port run as-is?
rtel wrote on Monday, June 26, 2006:
Yes, the demo should run exactly as downloaded, if you are using the same hardware.
Did you make any changes to the project file? The startup code is particularly important as it sets the processor into the correct mode prior to calling main().
Are you using the startup code from the FreeRTOS.org download?
Can you successfully run the demo projects that come with the Keil compiler? If not then it would most likely be a setup problem rather than a project problem.
Regards.
nobody wrote on Tuesday, June 27, 2006:
Hello,
First, thank you for your quick responses.
I have made no changes to the project file. I am using the project as-is. I can successfully run demo projects for the MCB2100 that came with the compiler (ie: blinky), and I get correct results.
The above mentioned lines of code where I get stuck in the weeds appears to be waiting for some type of character input. I did try connecting to windows hyperterminal, but that did not seem to help.
I tried both the THUMB and ARM versions to no avail.
Some questions to make sure I’m sane:
1) The project "rtosdemo_ARM" from the "ARM7_LPC2129_Keil" directory should run stand-alone, correct?
2) Should the code start blinking LEDs to confirm functionality without needing to anything (once it is downloaded and running of course)?
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.
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.
Thanks for any help.
Kind Regards,
Joe
nobody wrote on Thursday, June 29, 2006:
Hi Guys,
Are you aware of any issues using the H-JTAG debug agent: http://hjtag.blogspot.com/?
nobody wrote on Thursday, June 29, 2006:
I don’t think it has been mentioned in a thread before this one.
Some debug interfaces let interrupts be processed between single steps in the debugger, even if the interrupts are disabled. This is the only major problem I am aware of with debug interface selection. Never seen it on an ARM though.
nobody wrote on Thursday, June 29, 2006:
Hmm, I’m not even stepping/debugging. Just trying to run the darn thing. Is anyone able to confirm some of my doubts from my 3rd post in this thread?
rtel wrote on Friday, June 30, 2006:
>1) The project "rtosdemo_ARM" from
>the "ARM7_LPC2129_Keil" directory should run
>stand-alone, correct?
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
>course)?
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.
Regards.
nobody wrote on Sunday, July 02, 2006:
H-Jtag does not work reliably with Keil uVision. It was on TwentyOne’s list to work on this at various times, but I haven’t seen progress on this front. There was a mention that uVision doesn’t really use the RDI spec properly, but was tuned to the USBJTAG that they sell. You may want to try the IAR port instead. The Kickstart IAR compiler (ewarm) is rock solid with H-JTAG and the FreeRTOS IAR 2129 demo works fine on the MCB2100 board.
Karim
nobody wrote on Wednesday, July 05, 2006:
> 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.
By this, do you mean to change the linker settings within the Keil tools in Options for Target? I tried de-selecting “Use On-chip ROM (0x0-0x3FFFF)” from the target options and I also tried reserving the ROM so that it won’t be used (as well as trying to define some USER classes). None of this seemed to affect anything.
> 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.
If I click “run to main()” from the debug option in Keil, I immediately am sent off into the weeds. If I don’t use this option, I can click on run, and it also goes off into the weeds.
> 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?
My ini file loooked something like this, very simple:
FUNC void Setup (void) {
// <o> Program Entry Point
PC = 0x00000000;
}
LOAD rtosdemo_ARM INCREMENTAL // Download
Setup(); // Setup for Running
g, main
But, I am no longer trying to use this as I don’t think I should be having to.
> 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?
Yes, I can set a breakpoint at main(). However, the code goes off in the weeds in the same place, and never seems to reach main.
>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.
The startup code is as downloaded.
I will try to use the free IAR tools and see what happens. I suspect the problem might just be the combo of H-JTAG + Keil.
nobody wrote on Wednesday, July 05, 2006:
FreeRTOS up and running with IAR tools + H-JTAG no problem!