Why DCAN IFx is required while HECC/SCC doesn't have one like that?

Hi Pashan,

There is no direct accessing to mailbox unless you are in test mode or RDA mode which are not recommended for functional operation mode.  

In functional mode, accessing is done through IFx command/data registers.

HECC/SCC has totally different memory architecture and totally different IP compare to DCAN.

It is an IP proprietary topic so i would avoid going there, but we tried to put some descriptions in the DCAN section in TRM.

Please use guideline or Halcogen low level driver to transmit and receive data without worrying about the busy bit.

Hello Henry,

I am totally confused about the following statement :  " transmit and receive data without worrying about the busy bit."

I thought DCAN IFx Registers shall not be accessed till BUSY bit is ZERO. That is the prerequisite.

Now you are telling I don't have to check BUSY bit before accessing DCAN IFx Registers.

I have following problem :

We are using Third Party CAN Stack Software for System Communication Bus.
We are attaching our DATA Acquisition Software which also uses DCAN to pump out internal software variables over CAN Bus during System Development Activities and Debugging.
Ideally we are not supposed to change Third Party CAN Stack, else warranty will be null and void.
Both the software components are ultimately accessing DCAN IFx Register.

That's why I am trying to understand all the intricacies for DCAN and HECC/SCC perspective before I break something else.

Because HECC/SCC didn't have this DCAN IFx/Busy issue, so essentially we had configured our software to use different MAILBOXES than Third Party Software for HECC/SCC and both were happily running.

Looks like now we can't do that based on MAILBOX and hence there is a problem.
I thought DCAN is much better than HECC/SCC w.r.t. Serialization of all accesses in parallel to MAILBOXes. But it looks like opposite.

Hope I am clear about my problem.

So, are you telling me that BUSY bit need not be checked before accessing DCAN IFx Register?

Thank you.
Regards
Pashan

Hello Pashan,

What I meant is that the Halcogen CAN low level driver will take care of busy bit checking for you if you use it.  

Let me give you some descriptions on what BUSY bit is and how it is used.

The internal RAM in DCAN will have arbitration between CPU access and the Host Message Handler (HMH) access. 

HMH access RAM when the CAN protocol controller has accumulated enough control / ID bits / payload for message filtering or updating the payload to RAM.

Thus, there must be a way to synchronize the CPU and HMH access.

When IFx logic accessing the RAM, the BUSY bit is set to 1.

Once the IFx register access to RAM completes, the BUSY bit is set back to 0. 

BUSY bit set to 1 is used for hardware write protection of the current IFx register that is accessing RAM and indicates that there is no arbitration from HMH.

Therefore s/w needs to make sure to check the BUSY=0 "first before" writing to the IFx register, otherwise, the write from software to IFx is "lost".

so the question is Why we need IFx register?

The CPU peripheral access is only 32-bit but each mailbox occupies around ~148 bits (i believe) of RAM and Parity/ECC protected. 

So it is not serializing as you said, but it is the number of CPU bits that DCAN module can receive each cycle and the fact that the RAM is ECC/Parity protected thus require all IFx register values to be updated and then trigger RAM access.  Does it make sense?

The DCAN hardware has to do read-modified-write on the mailbox that you are writing due to ECC/parity just in case you accessing only a part of the mailbox.

Therefore, user needs to write to whatever IFx register field of the mailbox that user intends to update, then start (start by writing message ID to command register).

The start will set BUSY bit and protect content of IFx until the read-modified-write is completed (takes longer if there is an arbitration)

I hope this helps you. 

Now, you can use one mailbox to send DATA Acquisition and different mailbox to be used by the third party software.  

I don't see any issue with that.  

As i said, the only thing you need to do is to check the status of the busy bit of IFx register that you want to use before writing to it.

If you use Halcogen, the driver check the busy bit for you.  You don't need to check the busy bit yourself.

Even if you don't use the Halcogen driver, what is the problem for a simple check BUSY=0 before writing to IFx?  

i don't understand how this simple check can impact you in a way that you can not use this to send your Data acquisition.

Hello Henry,

When DCAN IF1 Register BUSY bit is SET, then does it mean DCAN IF2 Register BUSY bit is also SET simultaneously?

I am asking this because if during the check of BUSY Bit of DCAN IF1 Register,  I see that BUSY bit is SET, then is it safe always to assume that DCAN IF2 BUSY Bit is ZERO, which means DCAN IF2 Register is free for access.

In essence, I am trying to understand if BUSY Bits of DCAN IF1 and IF2 Registers are coming from the same Internal DCAN RAM Interface or from different signal.

Because I will have to decide the ELSE part of Logic in my code about the BUSY Bit Check as shown below [assuming BUSY bits of IF1 and IF2 are independent from each other within the Internal Signal of Memory Interface] :

    IF  (IS_BUSY_BIT_OF_DCAN_IF1 == FALSE)
    {
          Use DCAN IF1 Register for DCAN Mailbox Access
    }
    ELSE
    {
          Use DCAN IF2 Register for DCAN Mailbox Access
    }

Please let me know about the above question.
Thank you.
Regards
Pashan