To send messages in order local Tx buffer priority was used on former versions of FlexCAN modules, LPRIOEN=1. Priority variable, which kept PRIO bits for next transfer was incremented before each transfer and reset to zero in case all Tx buffers were empty prior to transfer.
This seems failing with flexible data rate enabled, FDEN=1. I'm not yet sure, perhaps it's just SW error,issue is being investigated. [Update: FIXED] 1. It is told in S32K RM that LPRIOEN bit is for legacy applications. Does it mean it works only in standard, non FD mode? [Update: This indeed works in FD mode too]
2. If LPRIOEN is legacy, then what other mechanisms should be used to provide in order messages transfer? LBUF=1, which is send least numbered buffer first seems kind of good for this. But in case the top buffer is already scheduled I need to wait for it to be send, else filling buffer with smaller number I'm risking to send out of order. Isn't it?
3. LBUF=1 using ESR2.LPTM to find lowest priority Tx Mailbox. This perhaps is the best I could do, but it is not clear how LPTM is calculated. It is told "If CTRL1[LBUF] is asserted then the mailbox
indicated is the highest number active Tx mailbox.". This is not quite true. After initialization I see LPTM pointing to least number active Tx mailbox, not to highest number Tx mailbox.
4. LBUF=1. What will LPTM point in case 6 mailboxes N=0..5 are configured as Tx mailboxes and Tx buffer fullness map is accordingly 0-0-1-1-0-0? Since lowest N mailbox is transferred first, for transfer in order I should fill mailbox N=4. Is LPTM supposed to point to N=0 or N=4?
Thank you for your interest in NXP Semiconductor products and the opportunity to serve you. My name is Omar and I will gladly answer your questions.
2. The mechanism of arbitration depend on the LPRIOEN and LBUFThe arbitration process select the winner among the active Tx mailboxes at the end of
the scan according to the settings of both CTRL1[LBUF] and MCR[LPRIOEN].
3. If CTRL1[LBUF] is asserted, the first (lowest number) active Tx mailbox found is the
arbitration winner. MCR[LPRIOEN] has no effect when CTRL1[LBUF] is asserted.
4. In this case the MB with the lowest number wins the arbitration(N=0), LPTM points to N=4 since it has the lowest priority.
Let me know if this is helpful, if you have more questions do not hesitate to ask me.
thanks for comments.
So regarding sending messages in order, "legacy" LPRIOEN=1 is the best option. In CANFD mode and support for 64 byte data payload enabled, S32K144 has only 7 MB's. Since real life application requires several Rx acceptance filters, one per Rx MB, so I'm left with only 2-3 Tx MB's. There are 3 local priority bits, which allows transmission of up to 2^3=8 ordered messages. I mean filling free Tx buffer with data as soon as one Tx MB is sent. With "send lowest numbered MB first" I'm limited by number of Tx MB's.