FreeMASTER CAN error message too small

[michelet1]

Hello,

I found a problem in the CAN communication between uC s32k148 and freemaster.

In particular if I do Test Connection I get device alive then if I start the communication on the freemaster side with start communication I get the error response message too small.

On the uC side I respond to the communication with a message from FMSTR_STS_OK.

I think to understand that when I start the communication on the freemaster side he performs a configuration part and expects a specific response from the uC so I get this error. How do I understand which answer I have to give on the uC side to Freemaster so that I don't get the error message response too small?

Thanks

[MichalH]

Hello,

the CAN communication plug-in reports error "CAN/LIN response too short" when the PC returns the CAN frame marked with the "Last"  flag before the full message (which consists of multiple CAN frames) is received.

Your "alive" test finishes well because it uses just a single CAN frame. Longer replies seem to fail in your case. I have seen this problem when MCU driver does not properly wait until one CAN transmission is finished and it starts to send another one too soon so it overwrites the unsent frame in outgoing buffer .. so effectively, it only sends the last one.

Did you do any modification to the MCU driver code or to the FreeMASTER example application?

Thanks,
Michal

[michelet1]

Hello,

I am using an application for the micro that already contains the code for the CAN.I wanted to use this code and integrate it with that of freemaster. When the uC receives a message, it respond FMSTR_STS_OK with FMSTR_ProcessCanTx();

I think that's the problem because you see that freemaster expects to get a more articulate message when I start communication.How do I figure out how to compose the message to send to freemaster so that you don't complain with response too short?

Thanks

[iulian_stan]

Hi @michelet1 ,

Are you using S32 Design Studio as your development environment ? If so, could you tell what version are you using (is it S32 for ARM or S32 for S32 Platforms) ?

Unfortunately I don't have a S32K148 board, but I could provide a working example for S32K144 (should be rather straightforward to adjust it for a K148).

Kind regards,
Iulian

[michelet1]

Hello,

I have S32 Design studio for ARM.

Thanks very much

[iulian_stan]

Please find attached an archive containing S32K144 project made with S32 Design Studio for ARM Version 2.2. It is based on the S32K1xx SDK version 3.0.0 that comes with the default installation and uses minimal configuration required to run FreeMASTER in Polling mode over CAN.

Note: I added some custom code to disable Transmission abort mechanism, see the following thread for more details.

Regards,
Iulian

[michelet1]

hello,
thank you very much for the project.

I have looked at the various files and it is very similar to mine except that I use short interrupt instead of polling.

What I cannot understand is that I see the CAN freemaster functions FMSTR_ProcessCanRx FMSTR_ProcessCanTx but I don't functions for the preparation of the message that is the length of the message that I want to transmit etc ... I think this is the problem since on Freemaster the error response too short keeps coming out because freemaster expects a longer message but I always send FMSTR_STS_OK.

ie there is a specific message that I have to send to freemaster for the response too short error to disappear?
Thanks

[iulian_stan]

The response message is constructed in the FMSTR_SendResponse function. pcm_pTxBuff and pcm_nTxTodo variables store the location of to the message buffer and its size.

Do you have a CAN analyzer to inspect full messages received on the host (PC) side ? If so, you could compare their content with pcm_pTxBuff , or share it with us so we can also take a look.

[michelet1]

yes,

I tried to look through vector can analyzer.When I press the start communication button on freemaster I see several frames passing through the can that I think belong to the same message.

I report the sequence of frames and their content that freemaster sends: D1BB, 72C040, D1BB , 72C040,73BF0041, D1BB, 72C040.
on Side uC every time I receive a message I used the FMSTR_SendResponse configuring it in this way:
* pcm_pCommBuffer = FMSTR_STS_OK;
FMSTR_SendResponse (pcm_pCommBuffer, 1U);
I understand that as soon as I press start communication, freemaster sends a certain sequence of frames.

However, on the uC side, I simply configured the FMSTR_SendResponse with FMSTR_STS_OK.I think it is wrong to always answer FMSTR_STS_OK but how can I understand on the uC side which message to reply? I think it comes from this what that freemaster display error response too small.

Thanks

[iulian_stan]

As you already guessed this approach won't work because, each FreeMASTER request expects a  corresponding response (usually status + data payload). Communication library code should be kept unchanged.

Regarding your frames - I could not interpret them, could you please extract only the data payload.

Just to clarify what I was trying to get from them: each CAN frame (inside its data section) should contain a partial or entire FreeMASTER message of minimum 3 bytes (start of message + status + CRC).

You can inspect it by putting break points on FMSTR_CAN_PUTBYTE macro, inside FMSTR_TxCan function (or inspect CAN RAMn0 register before FMSTR_CAN_TX call inside the same function call).

Regarding your log: the first two commands FreeMASTER tool sends when you press the connect button is - try getting board information. The first one (0x20) is expected to fail because because it checks for a newer protocol version, hence the name "SendRecvPacketV4" (the response should be 0x32 0x82 0x73 that's what I get and is independent of the target). The next one (0xc0) should succeed (first byte of the response buffer should be 0x00 and total length 37 bytes) and return a valid message.

This would confirm that communication library works on the embedded side and  we can further investigate the communication between target and host.

[michelet1]

I on the uC see the last frame sent by freemaster which is the one related to the 0xc0 command.
The complete frame I see on the micro is 72C040 where:
72 hex is the control byte and corresponds to 01110010
then C0 which I think corresponds to the 0xc0 of the command
finally there is 40 which I think is the CRC?otherwise I can't understand the meaning of 40.
Since I get this frame from freemaster how should I answer uC side?do I have to send 37 bytes of which the first one is 0x00? I now answer with frame 320000 where 32 is the control byte 00110010 and instead 0000 is the command FMSTR_STS_OK=00 and then the CRC
i can't figure out what to answer from the uC to freemaster when I get this 72c040 frame? why do I think the response too small error is just because I answer with frame 320000 when I get from freemaster 72c040?is this reasoning right?
Thanks

[iulian_stan]

You are right about the incoming message. After FreeMASTER driver processes this message it should produce an output of 37 bytes of payload (36 data + 1 CRC). Next, a CAN frame can carry at most 8 bytes of data thus that payload will be split among 6 CAN frames. Each CAN frame will carry 1 control byte (that will be used by the PC tool to reconstruct the original message) + 7 bytes of the original data. Let's say the message that is returned by the driver on the hardware is: pcm_nTxTodo[37] = 0x00 0x01 0x02 ... 0x35 0xYY. Where 0x00 == FMSTR_STS_OK, 0x[B1] ... 0x[B35] == mesasge, 0x[CRC] == CRC. Note: 0x[B1] ... 0x[B35], 0x[CRC] should be computed by FreeMASTER driver (if it is not the driver may be corrupted). Next it will send 6 can frames with the following data:

1. 0x27 0x00   0x[B1] 0x[B2]  0x[B3]  0x[B4]   0x[B5]   0x[B6], where 0x27 informs that this is the first message
2. 0x87 0x[B7] 0x[B8] 0x[B9] 0x[B10] 0x[B11] 0x[B12] 0x[B13], where 0x87 marks an intermediary message
....
5. 0x87 0x[B28] 0x[B29] 0x[B30] 0x[B31] 0x[B32] 0x[B33] 0x[B34]
6. 0x92 0x[B35] 0x[CRC], where 0x92 stands for last message

I hope this gives you a better understanding of what you should expect.

[michelet1]

hello,
thank you very much for the explanation.
Now the communication mechanism is clear to me. The point that keeps haunting me and that I still do not understand is the following:
On uC side I tried to connect FMSTR_Isr to the CAN0 of my application on the uC.When from FreeMASTER I start the communication shoots FMSTR_Isr and runs FMSTR_ProcessCanRx()--> inside this function I can correctly read the message received 72C040. After the FMSTR_ProcessCanRx() is performed, always inside FMSTR_Isr, call the FMSTR_ProcessCanTx() which however comes out immediately as there is no message ready to send.

Because I noticed that the preparation of the message is done in FMSTR_SendResponse but in FMSTR_Isr() they are called first FMSTR_ProcessCanRx() and then immediately FMSTR_ProcessCanTx().
That is, the driver should already prepare the message to be answered on 37 bytes or do I have to prepare it by hand by calling FMSTR_SendResponse which in turn leans on FMSTR_ProcessCanTx()? This step in the uC side response is the most critical for me because it's not clear to me how the uC-side driver responds to FREEmaster.
Thanks

[iulian_stan]

Hi,

In short interrupt mode "The raw serial (SCI/CAN) communication is handled by the FMSTR_Isr interrupt service routine, while the protocol decoding and execution is handled by the FMSTR_Poll routine. Call the FMSTR_Poll during the idle time in the application main loop." (FreeMASTER Driver User Guide)

So I what you observe in FMSTR_Isr is the expected behavior. You need to make sure you call FMSTR_Poll periodically in your main loop to trigger message processing routine that ultimately calls FMSTR_SendResponse.

[michelet1]

thank you again for the explanation.

Now it is also clear to me the communication mechanism.

 there is still something that is not at all clear to me.... if I have understood correctly it is I who must compose the message on 37 bytes(6 frames) of response from the uC to FreeMASTER. So I'm going to have to make different FMSTR_SendResponse calls where I send one frame at a time, is this reasoning correct? If it is correct,how do I understand that I have to answer 37 bytes that is this information you gave me earlier in this discussion but I have not found any documentation that talks about how to compose the response messages to send to freemaster from uC.

Thanks 

[iulian_stan]

No, you do not have to compose that message nor call FMSTR_SendResponse function manually. This is part of FreeMASTER Driver internal mechanisms that are handled internally by the library and are out of the user scope (thus are not documented).

The only functions that users may call/use in their custom code are described in Driver API (ch.3 UG). Minimal use-case would include FMSTR_Init, FMSTR_Isr, FMSTR_Poll.

[michelet1]

hello, thank you for the explanation now the mechanism is clear to me.
There is, however, a problem that I just can't understand: I'm using short interrupt and uC side I can see the reception of the 72C040 frame.
This always uC-side frame prepares the response message on 37 bytes(36 + checksum) from FMSTR_Poll-->FMSTR_RxDone-->FMSTR_ProtocolDecoder-->FMSTR_SendResponse.
What is not clear to me is why only 3 frames are sent (being on 36 bytes should be 6 frames):I tried to put breakpoints and the first frame is sent passing through
FMSTR_SendResponse()-->FMSTR_ProcessCanTx()
second frame is sent passing through FMSTR_Isr() and FMSTR_ProcessCanTx()
third frame is sent by passing directly into FMSTR_TxCan.
The remaining 3 frames are not sent because I no longer end up in FMSTR_ProcessCanTx().
This seems to me to be very strange behavior and also I am using CAN analyzer to see frames passing through but I only see the message sent by FREEMASTER(72C040) but I don't see any uC side response. This I think is due to the fact that uC side are set in the various registers only the first 3 frames as a response on the 6 frames needed.
I didn't change the freemaster code I'm using FMSTR_Poll() and FMSTR_Init() and then I connected FMSTR_Isr() to CAN0.
Thanks

[iulian_stan]

Hi @michelet1,

It may be related to CAN configuration. Could you share you project ?

Although I don't have a K148 board, I could to test it on my K144 by adjusting peripherals' configuration (without changing your main source files, and FreeMASTER configuration).

[michelet1]

This is the error that appears on the Communication Debug Log when I press the Start Communication button. There are also 3 command codes that I think Freemaster sends as soon as the communication starts. Maybe Freemaster expects a precise response from the uC when it sends these messages?

Thanks