MPC5748G - Flexcan individual mask initialisation

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

MPC5748G - Flexcan individual mask initialisation

902 Views
bassduty
Contributor II

Hello NXP,

I would like some help to understand something about flexcan individual mask.

I recently run into a bug where individual mask behavior was very strange.

For the background :

- The code I used did not initialised the individual mask before reception. I know that it is recommended by the RM but this code forgot to do it.
And actually the code and individual masks worked like a charm during several months without any initialisation.

But then very recently it suddenly stops to work (without any change on the can filter part of the code, but other function like gpio adc uart were added).
And then the individual mask seems to take the value of some frame ID that were already running on the CAN bus before I set the filter + mask.

So there is a CAN bus already alive, then I connect my MPC5748G on it (reception not active, all MB set as inactive at this point).
Then I set my filter @ 0x7E8 and mask @ 0xFFFFFFFF (in freeze mode) and finally activate reception interrupt.
At this point, I'm receiving other ID than the 0x7E8 one.

After understanding that individual mask was mocking me, I read again the RM and found :

"CAN_RXIMR registers can only be accessed by the CPU while the module is in Freeze
mode, otherwise, they are blocked by hardware. These registers are not affected by reset.
They are located in RAM and must be explicitly initialized prior to any reception."

I made some research and found another post of the nxp community forum that shows some initialisation :

CAN_0.RXIMR[8].R = 0xffffffff;   
CAN_0.RXIMR[9].R = 0xffffffff;   
CAN_0.RXIMR[10].R = 0xffffffff;   
CAN_0.RXIMR[11].R = 0xffffffff;   
CAN_0.RXIMR[12].R = 0xffffffff;   

So I adapted to my code, now RXIMR are initialised and the filter/mask seems to work again.

One major detail : this problem was IMPOSSIBLE to reproduce when the code runned with debugger,
it pop up only when running from flash without any debbugger like in the real field.

So the problem seems to be solved but here my real questions :

I understand that individual mask are located in RAM. But why should it be initialised before using it ?
Actually, since I write my target mask (which is also 0xFFFFFFFFF) inside, the value should be correct.
I thought all RAM was initialized with startup code.

I means, what is difference between
1) initialising the area and then put a desired value afterwards
2) or just putting desired value when communication is needed.


Other question :
How can it be that code without any initialisation worked well during months ?
And why it's not possible to reproduce the problem with the debugger ?

I really hope someone could explain me. Maybe it's stupid question but at least I would learn something.

Thanks in advance
Best regards.

Tags (3)
2 Replies

635 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi,

Message Buffers and Mask registers are located in embedded RAM within FlexCAN module.

pastedImage_1.png

This RAM has nothing with system RAM that is usually initialized within startup code.

FlexCAN's embedded RAM is not affected by reset, it contains random values, so must be written by user to have desired values. Thus

- Message buffers should be inactivated to do not participate in matching and arbitration processes. This is done simple by writing CODE field to 0x0 or 0x8

- Mask registers should be written in a way it fulfills desired masking strategy. Writing 0xFFFFFFFF means all ID bits are compared and there must be exact match between received ID and configured ID within MB.

BR, Petr

635 Views
bassduty
Contributor II

Hello Petr,

first of all thanks for taking time to answer.

So I understand that individual masks are separate RAM.

I also understand that there is random values when MCU starts up, like any RAM.

What I don't understand is why it should be initialised (by initialised I mean write on purpose a "reset" value) before writing the actual desired mask.

So it seems the correct sequences is :  

First : write an reset value (before void main(void) for example, like 0xFFFFFFFF but could also be 0x00000000 ??) before any CAN communication activation. (During Freeze mode ?)

Second : once CAN communication is about to start, write desired mask according to mask strategy.

I thought that just write once the desired mask just before communication would anyway overwrite the random values on the FlexCan RAM area and then be OK because the mask value is only used for communication after having wrote the desired mask value.

It seems, according to the bug I encountered, that it should be written twice (some initial/reset and then real desired mask) to "take into account" the correct value.


That is this necessity of initialise the RAM area before use it that surprise me.
It solves my bug and it's done explicitely into the SDK EAR FlexCan driver so it's clear that I made a mistake by forgotting to do it.
But still I would like to understand why simply writing once the value I want over the random values is not enough.

Maybe some lack of knowledges of how RAM works ?

Thanks a lot for helping me.

Best regards,

0 Kudos