S9KEAZ64 MSCAN proper steps for wake up

cancel
Showing results for 
Search instead for 
Did you mean: 

S9KEAZ64 MSCAN proper steps for wake up

611 Views
julian_yeoh
Contributor I

Hi all, firstly I would like to apologise if this question has already been answered. I have seen a lot of questions on these boards that are related to MSCAN but so far I have not found a question/answer that is exactly similar.

PSEUDO CODE (steps before entering Stop mode):

1) Set SLPRQ = 1
2) Wait until SLPAK == 1
3) Set WUPE and WUPIE to 1
4) 10 ms Delay (executing other tasks, ISRs)
5) Enter STOP mode (interrupts are NOT globally disabled)

Usually the above steps in our source code allow the MSCAN to wake the S9KEAZ64 up from STOP mode. However I discovered that if a new CAN packet arrives during step #4 above, then MSCAN wakes up and automatically resets SLPRQ and SLPAK to 0. If this happens, MSCAN will not wake the MCU from STOP mode because SLPRQ and SLPAK are no longer 1.

Is there a way of overcoming this? The delay in Step #4 is more than 10 milliseconds. Should I enter STOP mode immediately after SLPAK becomes 1? If so, what is the maximum delay that can be used.

Labels (1)
Tags (2)
0 Kudos
5 Replies

441 Views
julian_yeoh
Contributor I

Thanks, that was a lengthy explanation, but I think you did not understand my main question. :-)

Capture2.PNG

I think that even with a very fast CPU, SLPAK can still change from a 1 to a 0 at the above location. Could you please confirm this? We just need to know whether it works 100% of the time.

0 Kudos

441 Views
Robin_Shen
NXP TechSupport
NXP TechSupport

Yes. It will. Just as the AN2255 said.
So you need to take the above measures to avoid it.

0 Kudos

441 Views
Robin_Shen
NXP TechSupport
NXP TechSupport

Hi Julian Yeoh,

You can refer to the solution mentioned in the AN2255. Let other CAN node don't send message within a few milliseconds.

note AN2255.png

Or can you ensure other interrupt don't happen during these steps. For example: Arrange this process in the rest of the time gap.

Or execute this process in a higher priority interrupt. For example: Systick interrupt

Or set a flag once you want to execute this process, check this flag at the bottom of other interrupt. If the flag was set, check the SLPAK again.

Best Regards,

Robin

 

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

441 Views
julian_yeoh
Contributor I

Hi Robin_Shen,

Firstly I would like to thank you for your quick reply!

Actually I have previously gone through the document AN2255/D and it seems that in a nutshell the solution is to simply check SLPAK again at the very "LAST MINUTE", even though we have already checked SLPAK before. However it seems like an important piece of information that is missing is the maximum allowed delay between checking SLPAK and entering STOP mode. Even if we write a very straightforward check in C such as shown below, the number of machine instructions that is consumed depends on the compiler. I tried to verify using the debugger and it seems like this problem can still occur :-(   (although I am not sure if my method represents a real world scenario)

if ( SLPAK == 1 )

{

    // SLPAK can still change to 0 here even though the probability is very very very low

    EXECUTE_STOP;   // I put a breakpoint at this line - when it pauses I sent a CAN message - SLPAK becomes 0

}

So the question is:

What is the maximum permitted delay between checking that SLPAK is set and entering STOP mode? (how many MSCAN or CPU cycles...)

If anyone has this information could you please forward it to me. Thanks in advance :-)

Capture.PNG

Figure 2 from document AN2255/D

0 Kudos

441 Views
Robin_Shen
NXP TechSupport
NXP TechSupport

I have consult this with AE team, here is the feedback from Enwei:

 

1. In fact, the AN2255 is very good reference and has explained the exact MSCAN low-power mode requirements and recommended program flowchart we can provide for our customer;

 

2. Yes, as customer said, the MSCAN  SLPAK  bit check(depends on user implementation C code and compiler optimization, several CPU cycles may need)and also the STOP assemble instruction( WFI, 2 CPU cycles excluding time spent waiting for an interrupt or event ) will still consume several CPU cycles before the CPU core really enter into STOP mode:

pastedImage_21.png

3. for customer's question:"What is the maximum permitted delay between checking that SLPAK is set and entering STOP mode? (how many MSCAN or CPU cycles...)", the max delay here is equal to the minimum time between SLPAK set and be cleaned again(the next CAN frame arrive and wake up the MSCAN ), so it actual means next CAN frame arrival interval--the Inter-frame space defined in BOSCH CAN spec.

pastedImage_6.png

If current CAN node is not a error passive node, the minimum inter-frame space is 3 bit intermission + Bus idle (an arbitration length, 12 bit for standard frame with 11-bit ID):

pastedImage_8.png

so the the minimum time interval is 15 * CAN bus bit period, which depends on the CAN bus communication baud rate you are using.

for example, a 500kbit/s CAN bus, the bit period is 1/500KHz = 2us, so the the minimum time interval is 15 * CAN bus bit period = 30us.

 

Based on the above discussion, let's consider a typical configuration of KEA part with MSCAN, use FEE mode to generate a 40MHz CPU core clock with a 8MHz external crystal as reference, the CPU instruction cycle will be 1/40MHz = 25ns, so 30us is 30/0.025 = 1250 instruction cycles, CPU can run ~1000 assembly instructions(for most CM0+ Thumb-2 ISA are single-cycle)for many low-power preparation works.

 

PS: the debug breakpoint customer made is meaningless for KEA CPU core is running with MIPS,the breakpoint cannot simulate the fast case in real world.

 

Based on the above, the following two suggestions for customer reference,

1. make the MSCAN sleep request and ACK check at the last of MCU low-power mode preparation, and simplify the step 3 as much as possible to short the time(suggest to configure the MSCAN wake up feature when MSCAN initialization, for MSCAN wake up feature only works in MSCAN sleep/shutdown mode, and does not work in normal mode):

pastedImage_26.png

2. as said in AN2255 , at high-level application, it is suggested that the CAN network operational modes are handled by network management software(for most automotive ECU, CAN network management is a MUST). For example, a specific message can be broadcast telling every node to go into sleep mode at the same time.

0 Kudos