AM2634: Register addendum seems to link towards AM261x instead of AM263x

Part Number: AM2634

Tool/software:

Hi

I would need a proper register table for AM2634.

The link on this page: https://www.ti.com/product/AM2634#tech-docs

once clicked opens a document spruj42d.pdf which starts like this:

Do they share the same register list?

At least I can't find MCAN_ECR register which according to the SDK is:
#define MCAN_ECR                                           (0x40U)

The document does not lists it:

I would be interested about those registers specially MCAN_ECR register mask:

#define MCAN_ECR_REC_SHIFT (8U)
#define MCAN_ECR_REC_MASK (0x00007f00U)

once a RX error happens, it remaining locked in even after a warm restart and even MCAN_reset being called.

I would need a way to reset them and also would be nice to have a complete register list since MCAN filters are remaining there as well after a warm reset ...

Best regards,

Barna Csenteri

  • Hello Barna,

    This is just a typographical error with the title of the document, AM261 isn't a part number. The title should be AM263 and we will fix this issue with next release of the document.

    Regarding the MCAN issue - I will loop in the appropriate expert for it.

    Best Regards,

    Ralph Jacobi

  • Hey Barna,

    The MCAN ECR register actually has an offset of 0x0000 0240 and is defined in the Register Addendum at the same.

    I am not sure where the REC_SHIFT and REC_MASK definitions have come from. I will need to defer to our software expert for additional insight.

    Best Regards,

    Zackary Fleenor

  • I am not sure where the REC_SHIFT and REC_MASK

    Probably from the bitposition inside the 32 bit register (bit8:14 is the receive error counter).

    I was afraid from that RO - cannot write it to 0.

    As I wrote on the other thread I call MCAN_reset (which basically puts the unit into SW_INIT mode what I am not sure if it is a proper reset), the whole code is reuploaded too and the errors are still there.

    Best regards,

    Barna Csenteri

  • Hey Barna,

    • You are right about MCAN_reset(), it puts the module into INIT mode, which means all transfers are stopped and Tx goes into recessive mode. Hence, the register being frozen is expected. Refer TRM section 13.4.1.4.3.1.
    • By design we do not support IP reset. You have to write into all required registers their default value to simulate a reset.

    • What do you mean by warm reset here? Are you writing to this register WARM_RESET_REQ? 
    MCAN filters are remaining there as well after a warm reset

    Best regards,
    Aswathi

  • Hi

    By design we do not support IP reset. You have to write into all required registers their default value to simulate a reset

    The problem is that some of the registers are read only so I can't write them - the errors (MCAN_getErrCounters) for example can't. Is there a way to reset the errors runtime? My problem is that our application is in a noisy environment and errors do occur thus I would like to clean them. Is there a way?

    What do you mean by warm reset here? Are you writing to this register WARM_RESET_REQ? 

    I do reupload the code and restart a a debugging session, which I suppose is also a warm reset.

    I hit a case when the code gets frozen right at start after some kind of CAN error occurs and this problem is there even if I restart the debugging session as many times I want. 

    Best regards,
    Barna Csenteri

  • Okay, I understand the issue. I have brought it up with our design team. Will post here once we have an update.
    Thanks for your patience.

    Regards,

    Aswathi