Forums » Software Development »
UPP "start" signal ignored in receive mode?
Added by Stewart Cobb over 11 years ago
We have an FPGA application for the MityDSP-138F board which transmits "packets" to the DSP through the UPP port. The packet consists of 16 bytes of header and 6160 bytes of signal data. The FPGA asserts the UPP "start" signal on the first word of each packet. The hardware documentation (SPRUH77A, section 33.2.5.3, page 1526) implies that the start signal is used in receive mode to tell the DMA to start a new DMA line. I can't find where it says that explicitly, but the pin has no function otherwise.
Our software on the DSP calls the "DspUpp.c" source file (supplied by CriticalLink, I think) to configure the UPP DMA for one line of 6176 bytes per DMA window. We expect to receive blocks of 6176 bytes, with the first byte of each DMA block being the byte/word on which the UPP "start" was asserted.
Instead, we receive blocks of 6176 bytes, with a random start time relative to the UPP "start" signal. The system acts as if the "start" signal is being ignored.
We can't probe the actual start signal with a scope, because it's buried in the PCB under the BGA chips. However, we have duplicated the start signal on another FPGA pin and confirmed that it acts as expected. To the best of our knowledge, we have programmed the calls to "DspUpp.c" correctly to enable the UPP start signal. But the packets aren't aligned correctly into DMA blocks.
What are we missing? How can we fix it?
Cheers!
--Stu
Replies (5)
RE: UPP "start" signal ignored in receive mode? - Added by Scott Whitney over 11 years ago
Stu,
I'm not sure about the DSP driver for uPP, I am using a Linux driver to the Arm. Are you trying to stream data from the FPGA to the DSP? Are you just using 1 line and therefore 1 memory buffer to transfer data via the uPP driver? Does your driver update the uPP parameters on the fly ie. program a pending uPP transaction before the current one is finished? If you are using just 1 memory buffer while programing pending uPP transaction then the FPGA will be overwriting data at the beginning of your memory buffer on the OMAP. Mind you on receive you have no control of the uPP control signals from the OMAP. Good Luck, Scott
RE: UPP "start" signal ignored in receive mode? - Added by Michael Williamson over 11 years ago
Hi Stu,
Check section 33.2.5.3 of the TRM. For receive mode, the start line is optional, controlled by the STARTx bit in UPICR.
The configuration of the strt signals are setup by the tsDspUppConfig in DspUpp.h and DspUpp.cpp. Check the bChanAUseStart and bChanBUseStart flags. Perhaps they are not set correctly, or there is a bug (??) in the driver? We often do not use the start bit during UPP capture on a lot of our jobs.
-Mike
RE: UPP "start" signal ignored in receive mode? - Added by Stewart Cobb over 11 years ago
Scott,
Yes, we're trying to send one line (of 6176 bytes) per DMA memory buffer (also 6176 bytes). The "DspUpp.c" code seems to correctly handle setting up a "pending" DMA transaction behind the currently executing DMA transaction. We have been able to stream data for months without having data lost or overwritten (we have verified this with test patterns generated in the FPGA). We're currently streaming data correctly, but we're not seeing the DMA line boundaries set correctly by the START bit.
Mike,,
I'm pretty sure we set the control words correctly to enable the STARTA bit. Below is a debugging printout of every register in the UPP, after we've initialized it but before the DMA is started. (We're not currently using UPP channel B / XDATA.) Bit 3 (0x00000008) of UPICR is the STARTA bit. The description of this bit (Table 33-15, page 1544) says "Channel A honors START in receive mode" when the bit is 1. But that doesn't appear to be happening.
DSP: uPP initialization OK.
DSP: Register UPPID 44231100
DSP: Register UPPCR 00000009
DSP: Register UPDLB 00000000
DSP: Register UPCTL 22220000
DSP: Register UPICR 0A280C28
DSP: Register UPIVR FFFFFFFF
DSP: Register UPTCR 00000000
DSP: Register UPISR 00000000
DSP: Register UPIER 00000000
DSP: Register UPIES 0000000F
DSP: Register UPIEC 0000000F
DSP: Register UPEOI 00000000
DSP: Register UPID0 00000000
DSP: Register UPID1 00000000
DSP: Register UPID2 00000000
DSP: Register UPIS0 00000000
DSP: Register UPIS1 00010000
DSP: Register UPIS2 00000080
DSP: Register UPQD0 00000000
DSP: Register UPQD1 00000000
DSP: Register UPQD2 00000000
DSP: Register UPQS0 00000000
DSP: Register UPQS1 00010000
DSP: Register UPQS2 00000080
DSP: Register PINMUX0 88888888
DSP: Register PINMUX1 88888881
DSP: Register PINMUX2 88888888
DSP: Register PINMUX3 88888888
DSP: Register PINMUX4 22002288
DSP: Register PINMUX5 11118118
DSP: Register PINMUX6 00110001
DSP: Register PINMUX7 18111111
DSP: Register PINMUX8 11111111
DSP: Register PINMUX9 11111111
DSP: Register PINMUX10 88222222
DSP: Register PINMUX11 11111188
DSP: Register PINMUX12 11111111
DSP: Register PINMUX13 44448808
DSP: Register PINMUX14 44444400
DSP: Register PINMUX15 44444444
DSP: Register PINMUX16 44444444
DSP: Register PINMUX17 44444444
DSP: Register PINMUX18 00444444
DSP: Register PINMUX19 00000000
DSP: UPP frame size 6176 = (16 + 6160)
Cheers!
--Stu
RE: UPP "start" signal ignored in receive mode? - Added by Michael Williamson over 11 years ago
Hi Stu,
Have you tried to use chipscope to confirm the alignment of the start strobe with the data as sent by the FPGA and check the UPP bus interface WAIT pins, etc? (if you don't have a license, I think you can get a 30 day trial one...). Are you honoring the WAIT strobe? I'm wondering if WAIT might be getting asserted by the UPP interface in order to queue the DMA engine up or something....
-Mike
RE: UPP "start" signal ignored in receive mode? - Added by Stewart Cobb about 11 years ago
FYI, for anyone reading this in the future:
The root of the problem was that the FPGA was sending longer or shorter packets than the UPP hardware was configured for. The START signal does actually work once everything is configured correctly.
