MC33903 on devkit-S12XE

[greghanssen]

Hi.. I'm trying to use the S12XE devkit on a vehicle application and have run into some issues with the MC33903 SBC on the board.. The eval board is setup in DEBUG mode.

First off the demo code (lab4_CAN) has some rather long delays (in the s12xe) after waiting for the SPI tx to be ready before loading SPI0DRH/L for transmit.. is this really needed?  Also it seems this code was brought in from elsewhere as it uses 0x5e90 to "enable 5V-CAN and Vaux" but best I can tell the 33903 doesn't have a Vaux..

Anyway.. my problem is that while cranking the engine the SAFE comes on and CAN0 shuts down (Vsense detect?).  I can also get a fault on the bench by powering up the lab supply (vs plugging in 12V hot.. presumably too long a Vsup ramp from the power supply?).  If left alone it will shut down VDD in 8 seconds.  

The startup is:

0xdf80 (read Vreg H.. presumably to clear the BATFAIL)

0x5a00 (enter into normal mode)

0x5e90 (I changes this to 0x5e08 just to turn on 5V-CAN)

0x60c0 (setup CAN)

At this point I would just like to have it NOT kill CAN0 and potentially power down if it gets a fault.  Is this possible?

If not, and I do have to monitor to check for faults (not using interrupts), should I just send 0x1d80 to read the mode

and possibly turn off the SAFE (it just comes back on again)?  Best I can tell when it faults it's in NORMAL-request mode.  When I read the fix and extend device status (16 bit return from 0x5a00) it looks like the RST bit is on.  The data sheet says "reset has occurred and the flags reporting the reset source are pending to be read"  What are they talking about here?  

In short, is there any way in advance to prevent RST/fail/safe from a Vsense under voltage or slow Vsup ramp?

If not, what is the most efficient set of SPI commands to detect the fault and bring the system back online quickly?

For our first product I'm looking into the more advanced FS6500 but before I go down that path I really need to have the basics working here..

Thanks!

[greghanssen · Accepted solution]

Update.. I'm now able to get it to recover on the bench but not in the car (after a cold crank).

In the main loop I check the upper 8 bit response from 0x5A00 ("fix status") every 80-250ms.

If one of the particular flags is set, I read the corresponding register to clear the flag then send 0xDD80 to clear the SAFE bit without exiting DBG mode (on this devkit).  So for example if VREG-G is set, I read VREG (0xDF00 and 0xDF80)... if CAN-G is set I read CAN (0xE100, 0xE180).. if IO-G is set I read the IO (0xE300, 0xE380) etc.. reading the flags followed by 0xDD80 seems to keep thing purring on the bench.  CAN0 continues and the SAFE led stays off when I take the power supply down to 8V and back.. 

Now I just need to figure out what's happening in the car.  Half the time when I crank the engine the CAN0 stops (which is feeding the EPS so I lose power steering).  If I run the engine for 20-30 seconds then restart it usually works as the 12V is slightly more charged and the warmer engine turns over easier.. But still this is not a solution.  I need to get this thing to fail safe.. not just fail.

[alejandro_cervantes]

Hello Greg, 

Sorry for the delay, for more specific information about the MC33903 I contacted to the person in charge of the SBC.

Hopefully we could receive his feedback shortly.

[greghanssen]

Thanks Alejandro,  I think I've made some progress.

The lab4_CAN code used a "delay" of 300 after verifying the SPI transmit buffer empty is set.. a "delay" is

void delay(long int time){while(time>>0){--time;}}

I've found I can't remove the delay without failing but I can reduce it to about 50.  It's not clear to me why I can't write to the SPI data register as soon as the transmit buffer flag empty is set... is this a peculiarity of the SPI system on the 9s12xe?

I've also found that things work a lot better (more consistently) if I double up each read and write command.  I guess I was under the impression the SPI in the 33903 being 16bits would have the lower 8 bits ready after seeing the upper 8 bits shifted in but this doesn't always seem to be the case.

In the 33903 init phase I'm setting up:

0x4C11 (twice) to enable the CRANK bit

0x4AA0 (twice) to set VDD reset at 0.7x

so for example:

while(!SPI0SR_SPTEF);

delay(50);

SPI0DRH = 0x4A;

SPI0DRL = 0xA0;

while(!SPI0SR_SPTEF);

delay(50);

SPI0DRH = 0x4A;

SPI0DRL = 0xA0;

In my main loop I'm checking the response from 0x5A00 (normal mode watchdog) every 80ms to see if any error flags are set.

If the MSB has 0x01 (VREG_G) then I read VREG_L (twice) and VREG_H (twice).

Similarly if the MSB has 0x02 (SAFE_G) then I read SAFE_L (twice) and SAFE_H (twice).

Also for 0x04 (I/O-G) and 0x10 (CAN-G) I read the corresponding registers..

If any of the above bits are set, after reading the individual registers I send a 0xDD80 to turn off the SAFE mode.

This seems to recover from the engine start that had previously been failing (and killing CAN0).

Interestingly the error that is set on engine cranking is not Vsense as I had suspected.. On a strong battery the voltage dips to 10.0V and the system was fine but on a weaker battery it dropped to 9.3V and the system would fault.. The Vsense shouldn't trigger until 8.0V.

What I see when the engine cranks is an MSB response of 0x04 (i.e., the I/O fault).. specifically when reading

I/O_L and I/O_H I get 0x04 and 0x04 (seriously.. that's after reading 2x).

0x04 on the I/O_L is Vsup1-OV "Vsup1 above Vs_high (17V)"

0x04 on the I/O_H is LP Vdd off "LPvdd off mode selected" ?!?!?

Anyway.. after reading I/O_L and I/O_H in response to I/O_G set in the status response then sending 0xDD80 to turn off SAFE mode, it seems to recover ok now even when the battery is moderately low.

[alejandro_cervantes]

Hello Greg,

The project Lab4 of the quick start package is intended to be just an example of how to set-up the CAN interface, for a final application the project must be tuned to comply with the specifications required.

I cannot tell exactly what is causing the reset on the board and the turn-off of the CAN module, as you are saying the main problem occurs during the cranking, could you provide a snapshot of the behavior of VBAT and VSUP during the cranking?

Another question, what do you mean by the SAFE?

Best regards

[greghanssen]

Thank you for the response Alejandro!

  I can simulate the under voltage on the bench as well as in the car by dipping the power supply down to 8V and back again.. I find it hard to believe the 5V VDD would under voltage with 8V into the regulator.. My assumption is the Vsense input is triggering the fault condition but I don't see how to disable that.  Or.. to easily detect it and bring the system (i.e. CAN0) back.  The devkit has the SAFE pin on the MC33903 tied to a red LED so it's easy to see when the "SAFE" condition is set.  If I don't send any more SPI commands/queries after the SAFE output pin turns on, the CAN0 shuts down immediately and about 8 seconds later VDD shuts down.  From the documentation this might lead me to think it's in LP VDD ON state but I have no idea how it got there.. Right now I'm reading back some info (REG hi/lo, SAFE hi/lo) as well as the 16 bit response from standard watchdog refresh (0x5a00.. even though I believe the devkit is being held in DBG mode so that shouldn't be needed..) I only do it to try and see the 16bit status.  

I think my other problem is that I can't be 100% certain the data I'm getting back from the SPI command is actually correct... The demo SW has big delays between checking SPI TX ready "while(!SPI0_SPTEF);" and loading the SPI TX registers.. Is this really needed?  I'm doing a similar "while(!SPI0_SPIF);" to confirm reception before reading SPI0DRH and SPI0DRL.. 

When I issue the 0x1d80 or 0xdd80 to read the device mode I don't see LP mode but I do sometimes see "normal request" mode.. (?!?!)  These commands will also turn off the SAFE output.. for a few hundred ms.. then it comes back on.  I can't seem to figure out how to truly restore normal operation.. 

I guess my first question would be what is considered best practice for sending and receiving SPI between the s12xe and 33903?  Can I just check SPI0_SPTEF then write SPI0DRH/SPI0DRL then check SPI0_SPIF and read SPI0DRH/SPI0DRL?  Or do I need delays in there?  Sometimes I question the data I'm getting back..

On the other hand if I periodically send 0x1d80 which also returns a "random code" in the bottom bits.. I can see that changing. I'm sending the results to CAN.. CAN0 (which is inop when the SAFE red LED is on) as well as CAN2 and CAN3 which I have setup on the devkit.

So monitoring some of this feedback on CAN2 or CAN3 (i.e. SPI0DRL responding to different queries or all 16 bits SPI0DRH/DRL from 0x5a00) I'll startup up the devkit at 12V and everything comes on fine.  Then I'll turn the fine voltage knob on the PS down to 8V and back.. At 8V the red SAFE comes on and CAN0 shuts off.  I send a 0x5a00 but often times I get back 0000 which doesn't seem likely.  

There must be a way to inhibit this mode when Vsense reacts to 8V on VSUP..  And if there isn't, I need to know what SPI commands I should send to quickly diagnose the problem then what SPI commands to send to clear the fault and restore CAN0 ASAP.. I'd rather not spend tens of ms in my main loop just scanning to see if the SBC has a problem!

Please help!  Thanks :smileyhappy: