S32 - MPC57 Model Based Design Simulink CAN Toolbox

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32 - MPC57 Model Based Design Simulink CAN Toolbox

Jump to solution
1,107 Views
petervlna
NXP TechSupport
NXP TechSupport

Hello,

My customer has some questions regarding MBDT:

I am planning to use CAN toolbox in your microcontroller unit. I need to enable and diable CAN transmit data online. But I could not see any Enable/Disable İnput in the CAN Transmit Block(FCAN_Send). How can I solve that issue?

2. I want to learn what happens when our CAN cable is disconnected while we receiving a heartbeat( periodic) message ?
What value will be read on Can Receive block?

a. Will it give an error or a warning that no message received in timeout period?
b. Will read value show as 0?
c. Will read value show the last incoming data?

regards,
Peter

1 Solution
973 Views
constantinrazva
NXP Employee
NXP Employee

Hello petervlna,

I'm not sure if I understood correctly what the user is trying to achieve here. Let me go through some details of how our toolbox works and what blocks we have available for the FCAN.

Our toolbox generates code in one of 3 places:

  • Initialization code (for configuring peripherals, clocks, pins, etc) get generated in a function that is called once, at the beginning of the application
  • Main loop code - this is where the code for action blocks gets generated - so here is where you'll see calls for blocks like FCAN Send. This main loop is controlled by a timer for which you can set the period by setting the discrete step parameter of the model
  •  ISR code - we have many blocks that handle various events and can trigger a subsystem when those get generated. For example, in the CAN ISR you can have the block trigger a subsystem (where you can put any block you want, so you have full control) for events like Rx Complete, Tx Complete, Rx FIFO Complete, etc. Another useful example here is the PIT block - you can set up this timer to trigger periodically a subsystem of your choosing. This means you can achieve some scheduling by using this, independent of the main loop control.

To get back to the questions - you don't have enable/disable on the CAN Send block, but you can control when you start the transfer by other means - this is how it was intended to be used. The most basic approach would be to have a variable checked in the main loop, and when it gets to a certain value, you trigger a subsystem in which you put the CAN Send block. This scenario only requires a standard IF block and an IF Subsystem action block.

For the other question, if the CAN cable is disconnected, depending on the timing, 1 of 2 things would happen: either no part of the frame will get sent (if the decoupling would be done between transfers) - and in this scenario you will get no CAN messages - either only part of the frame will be sent (this is the unlikely scenario where it gets decoupled when a transfer is ongoing) - in this scenario, error frames will be generated on the bus, but this won't affect you as the hardware error counters inside the transceiver will make sure to stop the flooding of the bus. The bottom line is that you won't get any message from the receive block, as there is no valid CAN frame put on the bus. If you use the blocking mode of the receive block, you can set-up a timeout value in ms and that will make sure to stop the receiving state after a period. You can check the status with another block we have available, the CAN Transfer Status.

We have a webinar on the topic of CAN - if the user is interested, he can watch it here.

You can share the link to this topic with your customer so he can jump in - maybe this direct contact would be more efficient.

Hopefully I clarified some things with this post for your customer.

Kind regards,

Razvan.

View solution in original post

3 Replies
974 Views
constantinrazva
NXP Employee
NXP Employee

Hello petervlna,

I'm not sure if I understood correctly what the user is trying to achieve here. Let me go through some details of how our toolbox works and what blocks we have available for the FCAN.

Our toolbox generates code in one of 3 places:

  • Initialization code (for configuring peripherals, clocks, pins, etc) get generated in a function that is called once, at the beginning of the application
  • Main loop code - this is where the code for action blocks gets generated - so here is where you'll see calls for blocks like FCAN Send. This main loop is controlled by a timer for which you can set the period by setting the discrete step parameter of the model
  •  ISR code - we have many blocks that handle various events and can trigger a subsystem when those get generated. For example, in the CAN ISR you can have the block trigger a subsystem (where you can put any block you want, so you have full control) for events like Rx Complete, Tx Complete, Rx FIFO Complete, etc. Another useful example here is the PIT block - you can set up this timer to trigger periodically a subsystem of your choosing. This means you can achieve some scheduling by using this, independent of the main loop control.

To get back to the questions - you don't have enable/disable on the CAN Send block, but you can control when you start the transfer by other means - this is how it was intended to be used. The most basic approach would be to have a variable checked in the main loop, and when it gets to a certain value, you trigger a subsystem in which you put the CAN Send block. This scenario only requires a standard IF block and an IF Subsystem action block.

For the other question, if the CAN cable is disconnected, depending on the timing, 1 of 2 things would happen: either no part of the frame will get sent (if the decoupling would be done between transfers) - and in this scenario you will get no CAN messages - either only part of the frame will be sent (this is the unlikely scenario where it gets decoupled when a transfer is ongoing) - in this scenario, error frames will be generated on the bus, but this won't affect you as the hardware error counters inside the transceiver will make sure to stop the flooding of the bus. The bottom line is that you won't get any message from the receive block, as there is no valid CAN frame put on the bus. If you use the blocking mode of the receive block, you can set-up a timeout value in ms and that will make sure to stop the receiving state after a period. You can check the status with another block we have available, the CAN Transfer Status.

We have a webinar on the topic of CAN - if the user is interested, he can watch it here.

You can share the link to this topic with your customer so he can jump in - maybe this direct contact would be more efficient.

Hopefully I clarified some things with this post for your customer.

Kind regards,

Razvan.

973 Views
ykarata1
Contributor IV

Hi constantinrazvan.chivu,

Thanks for your detailed reply.

Actually I managed to enable/disable CAN Transmit blocks by putting them in an enabled subsystem in Matlab. With these systems transmitted CAN messaged can be controlled online. 

About the CAN line disconnection, there is still something I did not understand.

Either CAN_H or CAN_L or both is disconnected. CAN_RX hardware will get

1. NO signal or

2. absent signal which will cause Error signal. 

On each case what will I see at the display that is depicted below. Figure is obtained NXP CAN example. I just added a display.

What will I see on the display as data?

a. ERROR - since no data is coming 

b. ZERO - since no data is coming FCAN_Rx_Complete_Isr will give data as 0.

c. LAST DATA that READ when CAN line is LIVE- Last data that has been read when CAN line was still operating.

pastedImage_1.png

If answer is a, that means I can detect CAN line disconnection. What if answer is b or c, How can I detect CAN line disconnection?

Thanks.

0 Kudos
973 Views
constantinrazva
NXP Employee
NXP Employee

Hello ykarata1@ford.com.tr ,

Sorry for the late reply - I somehow missed that there was 1 more reply on this post. In this case you are talking about, you will not trigger the RX Complete event, as that is only triggered when the whole frame was received (uncorrupted). 

Currently we don't have error handling enabled, but I can think of other ways in which you can detect disconnection - the simplest example I can think of is by sending an 'am I alive?' dummy message on the bus - then you can have an ISR block with TX Complete event - if this does not trigger, you know that you have been disconnected. This can be done with our toolbox, but the downside is you don't have an interrupt as soon as you've been disconnected. You can control the sampling time of this 'am I alive?' check, so you can go as often as you want, but the higher the frequency of this message, the higher the load on the bus. In reality I don't see this having a big impact, as you don't end up having very high bus loads, it's just not that clean of an approach. I can think of other ways if you have some bus management that you already do - you might send a RTR and if you get something back for that, it means you're still on the bus. This might be better from a design standpoint, but you still end up sending something on the bus. The reason I mentioned this is that if you already have some sort of RTR going on the bus, you could double it's use for this check.

The conclusion is that you can detect it, but it has the downside that you'll have to do some sort of polling, at a frequency of your choosing.

Kind regards,

Razvan.

0 Kudos