UART_Receive Block compilation error

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

UART_Receive Block compilation error

1,078 Views
lujia
Contributor I

HI,
I encountered some problems when using [model-based Design Toolbox for MPC57xx Automotive Version 3.0.0/Communication Blocks/UART Blocks/ UART_Receive], as shown in the figure.


Set the Data size to 8; After receiving the data, extract the data Uart_DataRcv[2] for subsequent processing.
However, the error in compile time indicates that the received data index cannot be greater than 0, that is, it is not an array. Is there any BUG in this module?
It is hoped that modules supporting LIN protocol will be provided later.

Thank you very much!

pastedImage_2.png

Labels (1)
Tags (1)
0 Kudos
6 Replies

860 Views
constantinrazva
NXP Employee
NXP Employee

lujia@dfmc.com.cn‌ as for the LIN support, currently it is supported only on S32K1xx toolbox - I'm not sure it will be added for MPC57xx toolbox in the future - so the answer is most likely not, but it isn't 100% sure.

Kind regards,

Razvan.

0 Kudos

860 Views
constantinrazva
NXP Employee
NXP Employee

Hello lujia@dfmc.com.cn‌,

Could you share the model with us? It seems that the switch block is the one that is generating the errors - that is a standard Simulink block, so I'd like to see all the settings from your model to be sure where the problem lies.

Kind regards,

Razvan.

0 Kudos

860 Views
lujia
Contributor I

HI

Thank you for your reply. See the attachment for the model. Only when Uart_IdxX is all set to 0 can it be compiled and passed.

Looking forward to your reply. Thank you.

0 Kudos

860 Views
constantinrazva
NXP Employee
NXP Employee

Hello lujia@dfmc.com.cn‌,

So let's talk about the switch block:

pastedImage_1.png

In this example you can see we have 1 selector (top Constant block - value 2) and 2 input signals (values 4 and 5). If we take a look at the mask of the switch block, we can see the Data port order is set to 1-based contiguous. This means the selector will have values between 1 and the number of data ports (in our case, 2). This works in the following way:

Selector inputSwitch block output
14
25

If we would have have 0-based contiguous selected, the values would have been between 0 and 1 for the selector.

In your example, you only have 1 data port, and the order is set to 0-based contiguous. This means the selector can have values between 0 (starting position for 0-based indexing) and 0 (number of data ports - 1, that is 1-1=0). So this is why Simulink issues that error.

Let me know what you are trying to achieve with these switches and I can help.

Another thing I want to mention - I'm not sure where you took the UART configuration block, but you have to delete it and put it in the model again, because it is not linked with the one from within our library. I'm not sure what happened there.

Let me know if you're still facing issues with this.

Kind regards,

Razvan.

0 Kudos

860 Views
lujia
Contributor I

 Hi:

Thank you for reply!

I want to extract data through [multi-port Switch Block] after [Receive_Block] receives LIN data and implement the logic of LIN protocol.

 

As described in the help document, if [size] is set to 8, the output [data] should be an array of size 8.

 NXP01.png

In other words, the output [data] is Uart_DataRcv[8].

NXP02.png

After receiving Uart_DataRcv[8], [multi-port Switch Block] was used to extract the array to realize the logic of LIN protocol.

NXP03.png

The problem is that even if I set [size] to 8, the output from [Receive_Block] will not be an array of size 8, but a UINT8. This will result in a failure to extract through [multi-port Switch Block] and a compilation error. So I'm guessing there's a BUG in [Receive_Block].

0 Kudos

860 Views
constantinrazva
NXP Employee
NXP Employee

Hello lujia@dfmc.com.cn‌,

Sorry for the late reply, I must have missed this. I understand what you are saying now. Yes, this is an issue, but I will take it up with mathworks as it seems that Index vector (Simulink standard block) can not deal with DYNAMICALLY_SIZED data. Our UART receive block has the output set like this

ssSetOutputPortWidth(S, 0, DYNAMICALLY_SIZED); 
ssSetOutputPortDataType(S, 0, SS_UINT8);

As it is set to be an dynamic array of UINT8 type, I guess some sanity checks fail on mathworks' side. We need to have this block have a dynamically sized output, as we do not know a priori what size the user needs the receive buffer to be.

Will get back to you once we figure out with mathworks how we/they can fix this.

Kind regards,

Razvan.

0 Kudos