• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 1713 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3359: CAN loopback example issues

Bilal Malik
Prodigy 270 points
Part Number: AM3359

Dear Team,

One of my customers has the following problem with the ICE v2 evaluation board (Sitara - AM3359)

Could you please help us with that.

=============================================================

Currently I am trying to run the CAN loopback example included with the SYS/BIOS Industrial SDK 2.1.0.1. Unfortunately I have experienced some issues with this sample project, so I hope you could give me some guidance to understand and overcome these problems. Our development kit consists of a ICE v2 evaluation board with an AM3359 processor. And the issues I have found are described below.

 

  1. I had to comment out some function calls that identify the board and the processor on which the firmware is running since they hang in an endless loop. I just got sure that these function calls were not setting members of configuration data structures (otherwise I set them by hand to the values of our board and processor). This is not a problem at all, but I think it is worth mentioning it – I hope I did not break anything.

 

  1. The sample program asks for one to ten data frames to send in loopback mode. After introducing the data, nothing seems to happen. Only if you pause the program and hit “play” again, some characters are displayed on the terminal. After several pause/play cycles, the output buffer is completely flushed. Should it not display the characters smoothly and without user actions?

 

  1. According to the technical reference manual of the processor (TI literature number SPRUH73P), fig. 23-6, the CAN module should send the frame to the TX pin, also in loopback mode. We are not able to see anything on the pin, on both sides of the CAN transceiver. The jumpers for the pins found next to the transceiver are connected as explained on the hardware schematics of the board.

 

By the way, I realized that the pin mux table of the board did not include the control registers to configure the pins as CAN TX/RX, so I wrote the configuration by hand:

 

*can0_tx_pinmux = PAD_MUX_SELECT_CAN | PAD_PULLUP_DISABLE | PAD_SLEW_CONTROL_FAST; // this produces 0x0009

               

                Where can0_tx_pinmux points to 0x44E1 0000 (base address of the control module) + 0x091C (offset for the MII1_TXD3 pin, which is multiplexed to DCAN0_TX). Nevertheless, the Memory Viewer of Code Composer Studio indicates that the proper address of that register has an offset of 0x0928. None of these addresses produce activity on the CAN TX pin. Except for the changes noted here, I have not modified the CAN driver from the example of the SDK.

 

Could you please confirm which the right offset of the pin mux is? Am I forgetting to configure any other register in order to make the pin mux work?

=============================================================

Thank you in advance for your help,

Regards,

Bilal MALIK

  • 0
    TI__Guru**** 393215 points
    Sorry, Industrial SDK is no longer supported by TI. Please read the notice on to of this forum: e2e.ti.com/.../580869
  • 0
    Prodigy 80 points

    Hi all,

    I am the mentioned customer facing these issues. After some research, I realized I was configuring the wrong output pin for Tx. Now I can see the signal on the oscilloscope.

    Nevertheless, I am still trying to address the second issue (UART buffers flushing and CAN message sent only after pausing the debugger).AFAIK, the first paragraph (function calls I had to comment out) should not affect, since these calls seem only to set some parameters in data structures used by the program but not mapped to peripheral registers. Anyway, any help / clue for further research will be appreciated.

    Thank you very much in advance!

    Best regards,

    Alejandro

  • 0 in reply to Alejandro Navarro77
    TI__Guru**** 393215 points
    Again, I'm sorry, but Industrial SDK is no longer supported by TI. Please read the notice on top of this forum: e2e.ti.com/.../580869
  • 0 in reply to Biser Gatchev-XID
    Prodigy 80 points

    Hi Biser,

    We are still using the deprecated SDK due to dependencies with third party libraries in a parallel project. Anyway the code found in pdk_am335x_1_0_7 for the CAN examples is exactly the same, so I assume it will show the same effect of flushing buffers only when pausing it (I will not check by myself: the projects were shipped with absolute paths for include-s and libraries, and it takes a while to change them all).

    Is there any way to make things run "at real pace" instead of having to pause the program to get the CAN frames sent and the UART buffers flushed?

    Thank you very much in advance.

  • 0 in reply to Alejandro Navarro77
    TI__Mastermind 30365 points
    Alejandro,
    Have you looked into whether the relevant interrupts are getting triggered for the CAN frames?

    Lali
  • 0 in reply to Lalindra Jayatilleke
    Prodigy 80 points

    Hi Lali,

    I have checked that INT[0], INTPND_X[0] and INTPND_12[0] bits are set, this meaning that an interrupt is pending due to the first message object. The ES register has only the TxOK status bit set, so everything looks fine.

    The loopback application can send a number of frames between 1 and 10. I have realized that frames 1 to N-1 are sent when one would expect, but the last frame is sent only after pausing the debugger. If there is only one frame, it plays the role of the "last" frame.

    On the other hand, the message displayed on the terminal to print the received payload is shown only in small chunks, each one (say 12-15 bytes) appearing when I pause the debugger. I also checked some "freeze" configuration fields that modify the behavior of certain peripherals in debug/suspend mode, but they do not seem to be set up for halting CAN or UART transmissions. Everything runs normally before sending the last frame entered.

    Could you explain me why the last frame is kept until the debugger is paused, and why the system is slowed down after resuming execution? I think this would solve all my doubts.

    Thank you very much.
    Best regards,

    Alejandro

  • 0 in reply to Alejandro Navarro77
    Prodigy 80 points

    Hi again Lali,

    I have found out that the DMA is causing the slowness of the CAN Tx and the terminal output. If I switch to DCAN_MANUAL_MODE (instead of DCAN_DMA_MODE), the last frame is immediately sent, and the terminal keeps on working at "full speed", both without having to pause the debugger. Of course, I had to do some minor modifications (mainly copy data from source buffer to DCAN TX message object, and from RX message object to destination buffer).

    For just a couple of 32-bit words (what our actual application will handle), I will not use DMA. However, it would be interesting to know the root cause of the problem, in case someone else faces the same issue, and to fix the DMA driver for your SDK.

    If you find the answer, could you please post it here? Thank you very much.

    Best regards,

    Alejandro

  • 0 in reply to Alejandro Navarro77
    TI__Mastermind 30365 points
    Alejandro,

    Thanks for posting an update here and indicating what worked for you. I will need to check internally to see why the DMA might be causing the issues you are seeing and shall update this thread once I get more details. Thanks,

    Lali