Infinite loop in PSOS_INIT()

Oct 08, 2004 5 Replies

Hi,



Problem Summary: While executing the BSP code for our target board (on ARMulator, an ARM instruction set simulator) the processor goes into an infinite loop at PSOS_INIT(). We have no clue as to why this happens. Please read below for more details. Thank-you!



Details: We are using ARMulator to simulate a system that has an ARM946ES processor, a UART connected to a Keyboard, an Interrupt Controller, and a Timer, apart from other components. The UART, Keyboard, Interrupt Controller and Timer are simulated as ARMulator extensions, and other components are not simulated. PSOS is used in the real hardware system. We compiled the code (for the real hardware system) as a .axf image, loaded the image in ARM Extended Debugger (AXD), and executed the code. We found that the processor went into an infinite loop, in the function PSOS_INIT() (called from the function SysInit in the file Sysinit.c of PSOS BSP).



This is the register dump, when ARMulator is in the infinite loop: Registers Bank: Current (SVC mode) Index Name Value #1 r0 0x00000F0D #2 r1 0x00000F0D #3 r2 0x00000F0D #4 r3 0x00000F0D #5 r4 0x00000F0D #6 r5 0x00000001 #7 r6 0x00000000 #8 r7 0x00000000 #9 r8 0x60000093 #10 r9 0x405233E0 #11 r10 0x60000093 #12 r11 0x00000000 #13 r12 0x00002000 #14 r13 0x40525068 #15 r14 0x0027CD18 #16 pc 0x0027B2F4 #17 cpsr 0x60000093 #18 spsr 0x00000000



This is the snapshot of ARMulator disassembly:



0027b2e4 [0xeafffffd] b 0x27b2e0 ; (pSOS_Ienter + 0x930)
0027b2e8 [0xe10fa000] mrs r10,cpsr
0027b2ec [0xe38a8080] orr r8,r10,#0x80
0027b2f0 [0xe129f008] msr cpsr_cf,r8
0027b2f4 [0xe1a00000] nop ;;;;}}} Infinite
0027b2f8 [0xeafffffd] b 0x27b2f4 ;;;;}}} Loop
0027b2fc [0xe8bd00f0] ldmfd r13!,{r4-r7}


If someone can help us in identifying the cause of the problem, and overcoming this, it will be of great help. Also, it will be extremely useful, if someone lists various possible scenarios/exceptional conditions under which PSOS_INIT drives the CPU to an infinite loop. In our case, it goes into an unconditional infinite loop.



Thank you for your time.


Regards, Arun


snip

endSnip

The loop you are in looks very much as if it might be the pSOS idle task. If your own tasks are not running, for whatever reason, this would be where you would end up; it's normal! I suggest that you look to see that your tasks are properly formed (with infinite loops, so they never return) and properly created/initialised.

Also, as you seem to be working on a BSP, it's worth checking whether you have actually put any of your own tasks into the system, yet!

Another thought... Doesn't pSOS need a "start" call as well as an "init" call? (I can't remember; it's been a while since I used it). If you don't make that call, there might be some way for your initialisation code to run straight into the idle task.

Regards,

-- Peter Bushell http://www.software-integrity.com/

I'm not familiar with pSOS, but aren't the instructions at 2e8 to

2f4 in the listing above DISabling interrupts? In that case, this seems to be some fatal error handling routine -- something is catastrophically wrong, so disable interrupts and hang, to force a reset (if there is a watchdog) or at least prevent startup to an unsafe state.

I'm too lazy to look up what bit 7 of cpsr actually does, so I might be totally out to lunch, in which case just ignore me.

Apologies! Vic is quite right. I, too, was lazy and didn't check the code properly. So ignore my previous post. Sorry I couldn't help.

-- Peter Bushell http://www.software-integrity.com/

There is only one place in psos for ARM with a similar code sequence.

;************************************************************************ ;* halt: halt the processor * ;* INPUTS: NONE * ;* OUTPUTS: NONE * ;************************************************************************ Function halt MRS r10, cpsr LDR r8, [k_data, #kd_intrmask] ORR r8, r10, r8 MSR cpsr_cf, r8

0 NOP ; This NOP is necessary to allow halt ; to be single stepped. B %BT0

Looks like halt, or some variation has been called.

IIRC, when pSOS has a configuration error it first attempts to do a divide by zero operation, then it just loops if there is no DivByZero handler.

My GUESS would be that you have something misconfigured. Can you verify that pSOS has already started correctly? Note also that pSOS early in its startup checksums itself, so you cannot have (software) breakpoints set in the pSOS code itself during this time. And depending on how stepping is implemented on ARMulator, that may mess up the checksum too. Failing checksum is a sure way to get pSOS to go into its KFATAL call (DivByZero and/or infinite loop).

spammers snipped-for-privacy@pandora.orbl.org wrote:

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required