IVOR 1 when writing to LINFlex DMATXE

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

IVOR 1 when writing to LINFlex DMATXE

1,571 Views
ceciliac
Contributor III

Hi I am running MPC5746R and have the following code to configure UART on LINFlex_3

/* enter INIT mode */
LINFlexD_3.LINCR1.R = 0x0081; /* SLEEP=0, INIT=1 */

/* wait for the INIT mode */
while (0x1000 != (LINFlexD_3.LINSR.R & 0xF000)) {}

/* configure for UART mode */
LINFlexD_3.UARTCR.R = 0x0001; /* set the UART bit first to be able to write the other bits */

LINFlexD_3.UARTCR.R = 0x0033 | 1 << 8 | 1 << 9;
/* Transmit buffer size = 1 (TDFL = 0 */
/* Receive buffer size = 1 (RDFL = 0) */


LINFlexD_3.DMATXE.R = 0x00000001; //enable DMA
LINFlexD_3.DMARXE.R = 0x00000001; //enable DMA

//115200kb with 100 MHz
LINFlexD_3.LINFBRR.R = 4;
LINFlexD_3.LINIBRR.R = 54;

/* enter NORMAL mode */
LINFlexD_3.LINCR1.R = 0x0080; /* INIT=0 */

The problem is that I am not able to execute the command that sets the register DMATXE...it results in IVOR 1.

However the same code run fine when using LINFlex_0, is there any special setting to make it work on the other LINFlex modules??

Thanks,

Cecilia

7 Replies

1,140 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi Cecilia,

The LINFlexD_0 is the only module which has LIN Slave implemented and so Filter registers (IFCRx) are available. Those are missing on other LINFlexD_x modules as it is LIN Master only, thus address offset of GCR, UARTPTO, UARTCTO, DMATXE, DMARXE registers changes as below

pastedImage_1.png

If the header file is not modified accordingly, you can simply use IFCR3 to set DMATXE and IFCR4 to set DMARXE.

BR, Petr

1,140 Views
jamesmurray
Contributor V

Yes we could modify the header file, but a working one needs to be supplied ! It is easy to waste hours figuring out crashes like this that are avoidable.

Do you know if these issues are being worked on? I had some feedback to a ticket I raised that the eTPU/eMIOS ones have been ticketed and escalated to the S32DS team (so far so good), but I'm unsure when that will result in a fixed header file.

James

1,140 Views
ceciliac
Contributor III

OK, thanks! I am using the s32DS  environment and it seems the header file needs to be updated, this is the second defect we've had in it. Do you have an updated header file for MPC5746R?

Thanks,

Cecilia

1,140 Views
jamesmurray
Contributor V

What were the other defects you found in the header file?

I've found errors with TPU, eMIOS and LINFLEX (so far.)

James

0 Kudos

1,140 Views
ceciliac
Contributor III

Hi, the other defect was the number of message buffers for CAN_0 and CAN_1, they should have 96 buffers instead of 64 as stated in the supplied header file.  I'm very interested in knowing what the problem with the TPU and eMIOS is .... 

Thanks,

Cecilia

1,140 Views
jamesmurray
Contributor V

For eMIOS see here:

S32DS EmbSys registers mixup MPC5746R 

My post on eTPU seems missing, but, the header file put the TBR into reserved space, my fix was:

struct eTPU_TBR_tag {
/*   uint8_t eTPU_TBR_reserved0[32]; This is incorrect according to reference manual rev 6.1 addendum page 86 */

...

James

0 Kudos

1,140 Views
jamesmurray
Contributor V

I ran into this same bug too. No reply to my post:

https://community.nxp.com/thread/463193 

0 Kudos