F28335 eCAN issue with transmitting: hang

Your code is fine. It should work, assuming that the rest of the CAN - initialization is correct as well. There is no need to activate interrupts for your test case.

You mentioned that the error occurs when you restart your M3 board. Question: What happens with this M3 board after it has been reset? Could it be that this board forces it's CAN transceiver device to generate a dominant level for a while? In such a situation the 28335 could go to a bus off state and you will never be able to leave your while-loop.  If you inspect the status of register CANGIF0 in your sceenshot, you will see that exactly the bits BOIF0, EPIF0 and WLIF0 are set. It is a very important hardware design rule to make sure that a passive processor never produces dominant levels at the CAN lines.

And: Just o make sure: Am I right that your CAN Analyzer can see sometimes valid frames transmitted by the 28335? This would prove that your initialization of the 28335 is correct and the error is caused by the interference of the M3.

Hi Frank,

Thank you for the information provided. You are right the CAN goes bus off. It is proved after I set ABO bit on. Problem solved.

    EALLOW;
    ECanaShadow.CANMC.all = ECanaRegs.CANMC.all;
    ECanaShadow.CANMC.bit.SCB = 1;    // eCAN mode (reqd to access 32 mailboxes)
    ECanaShadow.CANMC.bit.ABO = 1;    // Auto Bus on
    ECanaRegs.CANMC.all = ECanaShadow.CANMC.all;
    EDIS;

If there are only F28335 and CAN analyzer I could see frames. So the CAN analyzer did not cause the CAN bus off of F28335. The only disturbance have to come from the M3 board during its reset. I have attached the circuit drawing here. Maybe you could take a look of it. The TX should output high voltage which is recessive by default. I am not sure how the dominant bits are produced during reset.

Regards,

Leon

.

Great that you could solve the issue. Unfortunately I cannot read your schematics. Please re-sent it with a higher resolution.

Another point:  If the M3 schematics is correct, e.g. it does not issue dominant levels during reset, there could be another reason for the 28335 to go bus off: If it transmits and there is no other active node available to generate the ACK, then the F28335 will increment the TEC and at the end go into error passive and bus off. If this happens depends on the time that it takes for the M3 to re-initialize its CAN after reset.

Hi Frank,

Attached the schematic again. It seems that I should use 'insert file' instead of 'insert image'. As respond to your second projection of the bus off, the CAN analyzer I am using would generate ACK, so it is treated as a normal CAN node. That's why I agree with your first point that M3 board is somehow generating dominant bits during its reset. Anyway if possible please advice how shall I measure the circuit with scope.

Thank you.

Regards,

Leon

Leon,

the schematics looks fine to me, assuming that the power supply remains stable when you reset the M3. What I cannot see from the picture is the CAN_TX drive from the M3. I assume that in reset the M3 sets all I/O-lines to input, right? In this situation the level of CAN_TX must be forced to 1 by an external pullup to ensure recessive levels.  

With respect to the CAN analyzer: The normal opmode of all analyzers, which I know, is "spy"-mode. It means that they do not issue an ACK. Some of them can be initialized not to use "spy", but the user have to initialize them for this mode. I prefer "spy" mode because the analyzer sees the traffic identical to the real application / real life. The other way around you can end up in a system, which works fine with an analyzer connected, but not without it.

Hi Frank,

Thank you for the analysis!

As for the CAN_TX, the measurement voltage during reset is LOW, which eventually leads to the TXD of can transceiver PCA82C251T LOW, thus dominant bits are produced during reset. As from the M3 data sheet (LM3S9B92) "All GPIO pins are configured as GPIOs and tri-stated by default", I am not sure about the phrase 'tri-stated' here but what I got is LOW voltage for the GPIO PD1 for my CAN. I agree with you that to ensure recessive level external pullup is required. Right now the pin PD1 almost equals to 'PH1_CAN_TX_5V'.

For the CAN analyzer the 'spy' mode here on my tool is 'listen' mode. Doing the same thing, no ack is generated. During the debugging I use the analyzer to send frame too that's why I use the other mode. Thank you for the remind anyway. Talking about this I recalled another problem I faced to consult. I have 2 nodes, DSP and M3. Let's say M3 is ready first and when it is ready it will send frame. But DSP is not ready yet to take the frame. So the M3 goes to error passive since it is the only node online. To avoid it I purpose delay M3 for several seconds to wait for DSP ready. How do you think about this handling?

Regards,

Leon

Leon,

to boot a CAN system could be tricky, especially when th 1st active node is a transmitter. If this node does not find a 2nd node, which is already initialized to the designated CAN data rate, the first node will go into error passive and later bus off. So your idea to delay the M3 as the tranmisster for a while sounds good. When I setup a CAN system I alway make sure that a receiving node is always first active. Another option could be the auto bus on for the first transmitter, but then you have to differentiate between the power on sequence (auto bus on) and a persistant failure during operation (auto bus off).

Hi Frank,

Thank you for the advice. You cleared my doubts on several points. Great support from this forum.

Have a nice day!

Regards,

Leon