S32K142: FlexCAN without SOSC

[sripav-7]

Hello

I have a custom board with S32K142 and I did not put an external oscillator on it because it doesn't have space on it. According to this diagram in the reference manual, it is possible to run the FlexCAN module without SOSC:

However, when I disable SOSC and try to initialize CAN, it halts at the can initialization step:

I set the clock source in CAN module to PE clock and it shows that both the module and PE clocks are set to 48 MHz. The clock manager for some reason, shows this:

Is it possible to run CAN without an external clock? If so, How can I fix this?

Thank you,

Harsha

[alexandrunan]

Hello Alexandre,

Do you have enabled the module clock for the instance of the flexcan ?!

Try to read with the debugger the MCR register of the flexcan instance, after the clock initialization and if it crashes that is the problem.

[alexandrehochar]

Hi,

Thanks for your reply.

Yes, all clocks are set but the debugger cannot read the register.
Furthermore, no frequency are specified into the clock configuration panel in PE.
Indeed, it seems like a clock issue.

After investigation, i found the wrong setting, my system clock is set at 80 MHz.

With a 48MHz clock, registers are accessible.

I don't found a maximum system clock speed in any documentation. Someone have found something about that ?

Thank,

[alexandrunan]

I have used the sys_clock set to 80Mhz for PE engine too and the flexcan worked as supposed. The PLL it uses as clock source SOSC how did you generate the SYS clock of 80Mhz ?!

[alexandrehochar]

I tried with 8MHz and 80Mhz engine clock, it's same.

Link below my clock tree.

[alexandrehochar]

Hi,

I have the same issue. When the driver try to access of MCR register, the code crash.

I tried the fix above but without effet, the code crash when base->MCR is tested.

Someone have an idea why i can't access to CAN registers. The differences with the sample code is that i work with a 80MHz clock source. (But 8MHz Engine clock).

I also use the no-FD CAN.

Thank,

[sripav-7]

It's hard to know why. In my case, that fix is working perfectly. Are you using the can_pal component or the flexcan component?

[alexandrehochar]

Hi,

Yes, i use the can_pal.

But it seems like a clock issue.

[sripav-7]

Our issues aren't really the same, then. In my case, I used the 48 MHz clock for both system and PE and the SDK wouldn't work well with that until I used the workaround.

I'm unsure why it wouldn't work with the 80 MHz clock. Can you post a screenshot of the debug view when the code crashes?

[alexandrehochar]

Of course,

Call stack,

And registers,

Thanks a lot for your help.

[sripav-7]

I looked up the errata code and found this:

This document is intended for MPC574XX controller and I don't think that that register exists in S32K1XX. So I don't think ERRATA_E10595 should actually be defined. I would try deleting those lines of code and see if it works.

[sripav-7 · Accepted solution]

Apparently this is a known bug in the SDK. The solution was to switch the component to flexCAN and write this in the FLEXCAN_DRV_Init function:

if(((base->MCR & CAN_MCR_MDIS_MASK) >> CAN_MCR_MDIS_SHIFT) == 0U)

{

/* To enter Disable Mode requires FreezMode first */

FLEXCAN_EnterFreezeMode(base);

FLEXCAN_Disable(base);

}

#if FEATURE_CAN_HAS_PE_CLKSRC_SELECT

/* Select a source clock for the FlexCAN engine */

FLEXCAN_SelectClock(base, data->pe_clock);

#endif

The idea is it check first if the module is already in disabled mode as expected to be the peripheral after reset and if is not already disabled then to force the freeze mode and disable the CAN module.

This workaround, at this time, is not possible using the can_pal component.

[alexandrunan]

This workaround apply to can_pal too because it uses the FLEXCAN_DRV_Init function too to initialize the can peripheral.

[sripav-7]

I tried that and it didn't seem to work. NXP said "The can_pal is a component wrapper over the FlexCAN driver, so don’t have access directly to the Peripheral Registers."

I didn't try to troubleshoot it further because it was just easier to change my component.