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.

Heavy UART traffic causes crash

Hello

I have an interesting problem regarding the UART peripherals on a C6748 dsp.

Firstly I configure a loop back test such that

UART2-RX is looped to UART1_TX

and

UART1-RX is looped to UART2_TX

Now I stream data into both UART1-RX and UART2-RX at full baud rate. This is a key point, data has to stream into and out of both ports at full speed or the failure many not happen. This is inconclusive, as the fault condition may just take hours rather than minutes to occur.

After approximately 8-15 minutes the UART traffic stops and it is clear that the DSP has frozen.

Next we monitor the DSP using the an emulator (XDS560)

We get an error message

'Device core is hung. The debugger .... etc.

The UARTS are configured to 115k2 operation with no flow control.

It doesn't matter if the core process polls the UARTs, we use an ISR or even configure a complete DMA transaction to transfer the data from one UART to the other we see the same result. Please also notice that the fault occurs with or without the emulator connected so I don't believe this is a JTAG/debugging issue

Okay now we configure a second test

UART0-RX is looped to UART1_TX

and

UART0-RX is looped to UART2_TX

(notice UART0 now not UART2).

Using this configuration we are unable to replicate the failure ..... (at the moment anyway). This second test used an almost identical program, the only change is an adjustment at the lowest possible architectural level of code which adjust the memory mapped pointer to reconfigure which uart is used.

This fault occurs on our hardware platform, running a DSP-BIOS operating system. We have designed a test case that cuts out most of our code and functionality so this seems like a specific problem with a DSP peripheral.

From our hardware point of view UART0,UART1 and UART2 are all configured the same way (ie all more or less direct connections to external level converters.

We are still testing this with different baud rates etc

Can you help us with these questions:

1) Is there any difference between UART2 and UART0 (other than the obvious that the register offsets are different, and the pinout is different)

2) Can you help me explain how this could crash the DSP.

3) Can you think of anything we could do to help isolate this problem, or at least halt the DSP rather than hang it so we can use the emulator to debug the problem.

Thanks,

Paul

  • Hi,

    Thanks for your post.

    You are correct, other than the memory mapped register offsets and the appropriate UART's Tx and Rx pinouts, there is no difference on the different interfaces (UART0, UART1, UART2).

    Are you using TI provided BIOS example code or your own custom code and again, are you debugging the code with TI provided board or your own custom board?

    To my opinion, please ensure whether the appropriate UART's Tx & Rx lines are mapped appropriately to their UART's Tx. & Rx. event no's and interrupts correspondingly and basically, it all depends on how you configured the UART Tx. and Rx. interrupts are mapped to their respective event nos. If this is appropriate, it will enter into appropriate UART's Rx. ISR's. There could be a possibility for a DSP to hang or freeze only if the appropriate UART Rx. interrupts are not entering into the respective ISR's in to the code and may be, you could evaluate this by keeping respective breakpoints at appropriate places in the code.

    Also, ensure the UART console settings like baud rate, stop bits, flow control etc are configured properly to synchronize the configuration with the application code as well the terminal.

    In hardware point of view, if the appropriate UART's Rx. and Tx. physical lines are mapped to their respective pinouts, there shouldn't be any issues.

    May be, I would recommend you to download the TI's C6BIOS SDK package to check for C6748 starterware UART loopback example configuration and with this, you could ensure the UART Rx. and Tx. configuration on the same.

    After installation, you could find the same example code from the below specified path:

    ~\Texas Instruments\pdk_C6748_2_0_0_0\C6748_StarterWare_1_20_03_03\examples\evmC6748\uart\uartEcho.c

    Thanks & regards,

    Sivaraj K

    ----------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    ----------------------------------------------------------------------------------------------------------

  • Hello Sivaraj,

    Thankyou for your reply.

    Regarding the example program, I don't believe we will see a problem if it the UART is configured into loopback mode.

    To demonstrate this issue asynchronous traffic needs to be sent in both directions. 

    Further investigation indicates that we actually need to send NULL characters to cause the failure .... can you explain this?

    Are you able to test the example code on one of your development kits, after making a change to send ASYNC bidirectional traffic?

    Thanks,

    Paul

  • Hi Sivaraj,

    One more thing, would you please explain this statement:

    To my opinion, please ensure whether the appropriate UART's Tx & Rx lines are mapped appropriately to their UART's Tx. & Rx. event no's and interrupts correspondingly and basically, it all depends on how you configured the UART Tx. and Rx. interrupts are mapped to their respective event nos. If this is appropriate, it will enter into appropriate UART's Rx. ISR's. There could be a possibility for a DSP to hang or freeze only if the appropriate UART Rx. interrupts are not entering into the respective ISR's in to the code and may be, you could evaluate this by keeping respective breakpoints at appropriate places in the code.

    How can an incorrectly configured UART interrupt cause a DSP to hang or freeze? I understand that the executing program could crash, but that would create an exception and the JTAG would be able to diagnose this fault. We see a complete crash where the jtag can no longer access the core or peripherals. Only a watchdog, or a system reset cause us to recover

    Thanks,

    Paul

  • Hello,

    Can you offer anymore insight into our problem?

    Thanks

  • Hi Paul,

    We apologise for the delay.

    Actually, I have tested BIOS SDK c6748 starterware UART with EDMA example code and I do not see any issues with the same and usually the example code are tested "as-is" without any changes.

    To my opinion, you could use an alternate emulator (XDS510 or XDS100 USB JTAG) to check whether the same issue happens with this too. Also, there is a "Test Connection" button on the target configuration *.ccxml file to ensure whether the JTAG emulator works fine with the h/w and able to connect to the target. This would narrow down whether there is any hardware issue with the emulator or not.

    As per your statements above, your UARTs loopback configuration seems to be ok, but even we could say the reason for the device to crash only with the core peripheral register dump. For this to happen, you need to access the code to acquire the core peripheral regiser dump. It would be recommened to use any other emulator, if you have to see whether the same crash happens with the same too.

    Are you using TI EVM or LCDK board? or any other custom board?

    Are you using TI provided DSP-BIOS PSP code as reference or your own custom code?

    From my end, i have tested with c6748 board and not able to see any issues with the "as-is" example code.

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question

    -------------------------------------------------------------------------------------------------------

  • Hello,

    Thank you for your reply.

    Can you test BIOS SDK c6748 with asynchronous bidirectional uart traffic?

    As I stated the loop back test will not demonstrate the problem.

    This fault occurs with and without an emulator connected. The failure is a complete DSP core crash. We cannot use the emulator to diagnose the problem because the DSP disconnects from it.

    We are using a custom piece of hardware, but I don't believe this is related to that. We have produced thousands of this product so I'm confident that PCB level hardware is working properly.

    My Question:

    1) Would you please explain exactly what are the differences between UAR0, UART1 and UART2.

    2) Would you please explain exactly how a DSP core crash is possible from a UART

    3) Would you please explain how we can debug this problem if the emulator looses a connection?

    Thanks,

    Paul

  • Hi Paul,

    Thanks for your update.

    As I understand that, you are facing ASCII character issue only with UART2 and there are few recommendations suggested as with reference to c6748 TRM below:

    http://www.ti.com/lit/ug/spruh79a/spruh79a.pdf

    To address your question 31, Differences between UART0 & UART1,2 are as below:

    1. With respect to System clock domain, UART0 uses PLL0_SYSCLK2 where as, UART1 & UART2 uses ASYNC3 PLL1 (PLL1_SYSCLK2) clock domain (please refer Table 6-2, Table 7-1 & Figure 6-1 for the overall clocking diagram in the TRM)

    2. Secondly, please ensure UART2 interrupt (UART2_INT) is mapped to Event #69 and likewise, UART1_INT for event #46 and UART0_INT for event #38.

    3. Again with the power domain, UART1 & UAR2 comes under PSC1 module and UART0 comes under PSC0. Kindly refer Table 8-1 and Table 8-2 for more info.

    4. With respect to pinmux control registers, UART2 & UART1 functions can be selected over PINMUX 0 & 4 control registers where as UART0 functions can be controlled over PINMUX0 control register. Please refer Table 10-24 for UART0 & Table 10-21, 10-25 for UART1 & UART2 respectively.

    5. In addition to above steps, please check section 10.5.10 from TRM for "Suspend source register (SUSPSRC)" in which, please check bit fields 20,19,18 for UART2, UART1 & UART0 emulation suspend source and kindly ensure whether it maintains a default value of 1 for a SUSPSRC bit corresponding to the peripheral, indicates that the DSP emulator controls the peripheral's emulation suspend signal. Like wise, check it for UART peripheral the same way.

    To address your question #2,

    In my opinion, DSP core do have possiblity to crash from a UART unless there is a mess up in the configuration of the corresponding UART's (0, 1 & 2) PINMUX, PSC & PLL_SYSCLK clock domain registers in the code.

    To address your question #3,

    It is very straight forward, we cannot debug the issue unless the emulator connects to the target to access the code.

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question

    -------------------------------------------------------------------------------------------------------