Other Parts Discussed in Thread: C2000WARE
While porting my client's application from a F28335 DSP to a F28379D DSP, I have been prototyping the port on a LaunchXL-F28379D demo / development board until engineering units for a updated proprietary target board become available. While debugging ported logic for the SCI port, I could not find a way to prevent continuous framing errors on SCI Rx. I consulted several related threads that recommended checking clock speed ( I am using the default LSPCLK of 50 MHz, which should have a baud rate discrepancy well under 1%). The one thing I have not yet tried is the procedure documented in one of your threads for resetting FE error bits in the SCIRXBUF register without doing a system reset. Nothing more than a SCI reset has been needed on the legacy application, and since nothing has changed except the target chip and its faster SYSCLK, it seems unlikely that that logic would be needed on the F28379D. The SCI logic is little changed from the F28335 version because SCI register contents and their use are identical on the F28379D.
As a control, I decided to try a couple of SCI example programs for the LaunchXL-F28379D. I tried the Resource Explorer project sci_ex3_echoback and the C2000ware project sci_echoback_cpu01. Both example programs fail to send their opening message sequences, and both fail to receive characters typed into a PuTTY session running at 9600 baud, 8-N-1
.
I have attached screen captures from each of the two example programs. It is interesting that they both fail SCI Rx in the same way as my ported client application. Apologies for the first low resolution image; I could not find a way to remove it.
Could there be a problem with the LaunchXL-F28379D on which I have prototyping the ported project, since the two unchanged, out of the box example programs are failing? Do you have any other suggestions for things I might try to fix this problem?
