Heavy UART traffic causes crash

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

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