PSM Error on warm boot

Hi All,

I have implemented a reset command using the IOCTL_HAL_REBOOT code.
The implementation is as follows:

case IOCTL_HAL_REBOOT:
{
volatile OST_REGS *const v_pOSTReg = (OST_REGS
*)OST_BASE_U_VIRTUAL;

// Enable the Watchdog timer
v_pOSTReg->osmr3 = v_pOSTReg->oscr + 5 * RESCHED_INCREMENT;
v_pOSTReg->ower = 1;
INTERRUPTS_OFF();

// Nothing can save us now
for( ;; ) ;

// Should never get here
return FALSE;
}

This works properly and the device reboots successfully on 9 out of 10
occasions. However, on the 10th the following is reported from the
debug port:

Windows CE Kernel for ARM (Thumb Enabled) Built on Jun 1 2004 at
16:38:37
ProcessorType=02d0 Revision=6
sp_abt=ffff5000 sp_irq=ffff2800 sp_undef=ffffc800 OEMAddressTable =
98381eb0
Sp=ffffc7cc
PSMFSD:DLL Process Attach
PSMHAL:Error (189) from PSMHAL_CFICompatCheck
PSMHAL:IOCtl(INIT):Error on init (189)
PSMFSD_MountDisk: FG_Init failed! status=bd

The platform is based on PXA255 processor, running CE.NET V4.2 using
Intel's IPSM V3.7 library.

My guess is that just prior to the watchdog kicking the processor, the
Flash RAM had a command issued to it that is not complete when the
PSMFSD driver loads.

Is this a correct assumption? and if so, what is the best way to
prevent it from happening?
Do I grab the Mutex before starting the watchdog? Can I even issue a
CreateMutex() in the OEMIoControl() function?

Thanks for your assistance in advance.

Brian Price
brianprice_AT_appliedcs_DOT_com_DOT_au

Paul
Thu Mar 31 10:50:30 CST 2005

I've never seen that happen. You need to talk to Intel and find out what
error 189 is supposed to be. That might tell you what's going on. Maybe
you have a device which shares the bus with the Flash chip and is not being
properly reset or something...

Paul T.

"Brian Price" <brianprice@appliedcs.com.au> wrote in message
news:cf046cbf.0503301806.559532ff@posting.google.com...
> Hi All,
>
> I have implemented a reset command using the IOCTL_HAL_REBOOT code.
> The implementation is as follows:
>
> case IOCTL_HAL_REBOOT:
> {
> volatile OST_REGS *const v_pOSTReg = (OST_REGS
> *)OST_BASE_U_VIRTUAL;
>
> // Enable the Watchdog timer
> v_pOSTReg->osmr3 = v_pOSTReg->oscr + 5 * RESCHED_INCREMENT;
> v_pOSTReg->ower = 1;
> INTERRUPTS_OFF();
>
> // Nothing can save us now
> for( ;; ) ;
>
> // Should never get here
> return FALSE;
> }
>
> This works properly and the device reboots successfully on 9 out of 10
> occasions. However, on the 10th the following is reported from the
> debug port:
>
> Windows CE Kernel for ARM (Thumb Enabled) Built on Jun 1 2004 at
> 16:38:37
> ProcessorType=02d0 Revision=6
> sp_abt=ffff5000 sp_irq=ffff2800 sp_undef=ffffc800 OEMAddressTable =
> 98381eb0
> Sp=ffffc7cc
> PSMFSD:DLL Process Attach
> PSMHAL:Error (189) from PSMHAL_CFICompatCheck
> PSMHAL:IOCtl(INIT):Error on init (189)
> PSMFSD_MountDisk: FG_Init failed! status=bd
>
> The platform is based on PXA255 processor, running CE.NET V4.2 using
> Intel's IPSM V3.7 library.
>
> My guess is that just prior to the watchdog kicking the processor, the
> Flash RAM had a command issued to it that is not complete when the
> PSMFSD driver loads.
>
> Is this a correct assumption? and if so, what is the best way to
> prevent it from happening?
> Do I grab the Mutex before starting the watchdog? Can I even issue a
> CreateMutex() in the OEMIoControl() function?
>
> Thanks for your assistance in advance.
>
> Brian Price
> brianprice_AT_appliedcs_DOT_com_DOT_au

brianprice
Fri Apr 01 01:31:43 CST 2005

Hi Paul,

Thanks for your response.

A previous article in this group from November 2002 "Problem of PSM
3.51" states

"189 means, basically, that PSM didn't find the FLASH where you told
it, in
plat_api.c, to look. It might mean that you've just got the wrong
physical
address listed in there."

I take it from this that when the PSM attempts to read the flash id, it
is unable to. Therefore, my suspicion that something else is in
progress (e.g. a block erase).

Brian P

Paul
Fri Apr 01 10:10:13 CST 2005

Well, we don't really know what it does. The list of error codes is,
apparently, a closely-held trade secret of Intel (really, just ask the
support guys for a complete list and see what happens), so we don't know
whether there's just a check for the ID, whether it actually tries to do
something to detect the end of the Flash, etc. It just means that,
generally because of hardware causes (or you put the wrong address in the
table), it couldn't find the Flash that you described in the table. It's
certainly possible that something is in progress and you're right, but there
*is* a reset pin on the device and, if you're strobing reset, which I bet
you are, that should terminate any operation of that sort.

Paul T.

<brianprice@appliedcs.com.au> wrote in message
news:1112340703.395430.167460@l41g2000cwc.googlegroups.com...
> Hi Paul,
>
> Thanks for your response.
>
> A previous article in this group from November 2002 "Problem of PSM
> 3.51" states
>
> "189 means, basically, that PSM didn't find the FLASH where you told
> it, in
> plat_api.c, to look. It might mean that you've just got the wrong
> physical
> address listed in there."
>
> I take it from this that when the PSM attempts to read the flash id, it
> is unable to. Therefore, my suspicion that something else is in
> progress (e.g. a block erase).
>
> Brian P
>

brianprice
Fri Apr 08 02:16:04 CDT 2005

Thanks for your response Paul.

I have looked into the reset circuitry, and no we don't strobe the
reset to the Flash RAM when a watchdog reset occurs. This means that we
could be interrupting an erase or program operation which take
considerable time and most likely have the Flash RAM in an unreadable
state.

We will revisit our reset circuit.

Thanks again
Brian Price

Dean
Fri Apr 08 08:32:45 CDT 2005

Keep in mind that on reset, the CPU (I assume we're talking XScale) starts
over at the reset vector. Assuming the flash is also at the reset vector,
you would not be able to boot if the flash was not in read array mode. So
this may not be your problem...

--
Dean Ramsier - eMVP
Vibren Technologies
http://www.vibren.com/Products/schema_bsp.htm


<brianprice@appliedcs.com.au> wrote in message
news:1112944564.204762.94620@z14g2000cwz.googlegroups.com...
> Thanks for your response Paul.
>
> I have looked into the reset circuitry, and no we don't strobe the
> reset to the Flash RAM when a watchdog reset occurs. This means that we
> could be interrupting an erase or program operation which take
> considerable time and most likely have the Flash RAM in an unreadable
> state.
>
> We will revisit our reset circuit.
>
> Thanks again
> Brian Price
>

brianprice
Sun Apr 10 19:15:26 CDT 2005

Thanks Dean.

Yes it is an Xscale, and yes it boots out of the flash RAM (that did
occur to me eventually).

It still remains that on a watchdog initiated reboot that we do not
actually reset the peripheral chips, and this may cause other driver
problems later.

Brian Price