IVOR 1 when writing to LINFlex DMATXE

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

IVOR 1 when writing to LINFlex DMATXE

1,552件の閲覧回数
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 返答(返信)

1,121件の閲覧回数
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,121件の閲覧回数
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,121件の閲覧回数
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,121件の閲覧回数
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 件の賞賛

1,121件の閲覧回数
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,121件の閲覧回数
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 件の賞賛

1,121件の閲覧回数
jamesmurray
Contributor V

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

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

0 件の賞賛