S32K344 bus fault if flexcan1-5 are used

[cmoser-crl]

Describe the bug

This is an issue with hal_nxp. The can driver for the S32K344 always tries to read the IMASK3 and IFLAG3 register of the flexcan peripheral if CAN_IMASK3_BUF95TO64M_MASK is defined. Only flexcan0 supports 96 message buffers and has these registers for the S32K344.

Expected behavior

The MCU shouldn't halt if a can bus other than flexcan0 is used.

Logs and console output

[00:00:00.051,000] <err> os: ***** BUS FAULT *****
[00:00:00.051,000] <err> os:   Precise data bus error
[00:00:00.051,000] <err> os:   BFAR Address: 0x4030806c
[00:00:00.051,000] <err> os: r0/a1:  0x00000000  r1/a2:  0x00040008  r2/a3:  0x00000000
[00:00:00.051,000] <err> os: r3/a4:  0x00006fff r12/ip:  0x0000c758 r14/lr:  0x0000109d
[00:00:00.051,000] <err> os:  xpsr:  0x41000081
[00:00:00.051,000] <err> os: s[ 0]:  0x0004040a  s[ 1]:  0x00000000  s[ 2]:  0x2000079c  s[ 3]:  0x0040ba53
[00:00:00.051,000] <err> os: s[ 4]:  0x007c8300  s[ 5]:  0x00000024  s[ 6]:  0x200010b0  s[ 7]:  0x00000000
[00:00:00.051,000] <err> os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000008  s[11]:  0x00000000
[00:00:00.051,000] <err> os: s[12]:  0x00000000  s[13]:  0x004052cf  s[14]:  0x00000000  s[15]:  0xffffffed
[00:00:00.051,000] <err> os: fpscr:  0xaaaaaaaa
[00:00:00.051,000] <err> os: Faulting instruction address (r15/pc): 0x0040a1a8
[00:00:00.051,000] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:00.051,000] <err> os: Fault during interrupt handling

[00:00:00.051,000] <err> os: Current thread: 0x20400f70 (main)
[00:00:00.068,000] <err> os: Halting system

Environment

• OS: Linux
• Toolchain: Zyphyr sdk 0.16.6
• Zephyr version: v3.7.0

Additional context

A similar issue is already handled for IMASK2/IFLAG2 here which only enables the reading of those register if CONFIG_CAN_MAX_MB > 32.

[manuargue]

Hi @cmoser-crl . I agree that the guards of IMASK/IFLAGS 3/4 in fsl_flexcan shouldn't be based on the presence of the macros CAN_IMASK3_BUF95TO64M_MASK and CAN_IMASK4_BUF127TO96M_MASK respectively, because the assumption that all FlexCAN instances support the same number of buffers is not always correct -as in the case of S32K344.

[congnguyenhuu]

Hi, the handling IMASK2/3/4 and IFLAGS2/3/4 in fsl_flexcan should have a proper checker to determine the number of message buffers for each instance, use FSL_FEATURE_FLEXCAN_HAS_MESSAGE_BUFFER_MAX_NUMBERn(base) to ensure correct buffer handling across different instances.
Example an original code:

#if (defined(FSL_FEATURE_FLEXCAN_HAS_EXTENDED_FLAG_REGISTER)) && (FSL_FEATURE_FLEXCAN_HAS_EXTENDED_FLAG_REGISTER > 0)
        tempmask |= ((uint64_t)base->IMASK2) << 32;
        tempflag |= ((uint64_t)base->IFLAG2) << 32;
#endif
        fgRet = (0U != (tempmask & tempflag));
#if defined(CAN_IMASK3_BUF95TO64M_MASK)
        if (0U != (base->IMASK3 & base->IFLAG3))
        {
            fgRet = true;
        }
#endif
#if defined(CAN_IMASK4_BUF127TO96M_MASK)
        if (0U != (base->IMASK4 & base->IFLAG4))
        {
            fgRet = true;
        }
#endif

Suggestion code changes:

#if (defined(FSL_FEATURE_FLEXCAN_HAS_EXTENDED_FLAG_REGISTER)) && (FSL_FEATURE_FLEXCAN_HAS_EXTENDED_FLAG_REGISTER > 0)
    if (FSL_FEATURE_FLEXCAN_HAS_MESSAGE_BUFFER_MAX_NUMBERn(base) > 32) {
        tempmask |= ((uint64_t)base->IMASK2) << 32;
        tempflag |= ((uint64_t)base->IFLAG2) << 32;
    }
#endif
        fgRet = (0U != (tempmask & tempflag));
#if defined(CAN_IMASK3_BUF95TO64M_MASK)
    if (FSL_FEATURE_FLEXCAN_HAS_MESSAGE_BUFFER_MAX_NUMBERn(base) > 64) {
        if (0U != (base->IMASK3 & base->IFLAG3))
        {
            fgRet = true;
        }
    }
#endif
#if defined(CAN_IMASK4_BUF127TO96M_MASK)
    if (FSL_FEATURE_FLEXCAN_HAS_MESSAGE_BUFFER_MAX_NUMBERn(base) > 96) {
        if (0U != (base->IMASK4 & base->IFLAG4))
        {
            fgRet = true;
        }
    }
#endif

[heinwessels]

We also ran into this issue. The suggested fix seems to fix it.

[manuargue]

The change has been incorporated into the MCUX SDK and should be available in next update of the HAL