OMAP-L138 UPP signals

Damian,

The series of events that you describe seems a little puzzling.  If the transfer is set for 16 lines of 128 bytes, then you should only see an EOW event at the end of the overall transfer (i.e. 2 KB).  This behavior should be the same regardless of whether or not START is enabled.  The only way you should see 16 interrupts per transfer is if you also enabled the EOL interrupt event.

In your case, since you configure the transmitter for 1 line and the receiver for 16, are you sure that the "extra" interrupts are not being generated by the transmit channel?

I have double checked and all 16 interrupts are EOW interrupt from channel I. It means that bit 3 is set (UPIER & 0x00000008 is true) and channel I is responsible for receiving data from receiver. It is configured exactly like I showed in my previous post. The problem is that is it working when START signals are enabled. Does somebody had the same situation or hasn't in this hardware configuration? 

Damian,

Unfortunately, I have not observed this behavior in my own tests.  I agree that it should function the same whether or not the START signal is enabled.  I'm not sure how to explain the behavior you're observing if that is really the only thing that changes in your source code.

Is it possible that this behaviour is because of that the peripheral circuit of one of these signals is damaged? I have checked the pinmux configuration it is OK as well. Do you know how the digital loop is realized? Does it just connects pins of channel A with channel B?

Damian,

I don't think that the issue you're seeing could be caused by a signal glitch or disruption. The EOW event is triggered by the internal DMA reaching the end of its overall "window," not by some combination of the external control signals.

In digital loopback mode, the uPP pins are connected internally (A to B, as you surmise).  The normal uPP pinmux settings must still be applied in this mode.

I tried to change configurations, change I and Q channels and all the time its the same. Is it possible that when the emulator stops at some point on the program and only ENABLE signal is active, the receiver doesn't stop and receives the data all the time? I have no other ideas. There is nothing connected to those pins and every signal related with UPP is set up in PINMUX registers. START signal is the magic signal in this case. 

Hello,

I am still trying to make UPP work properly. It started to work very bad.

I am trying to send in a digital loopback 128 bytes of data.

I am using ARM core and SYS/BIOS. Interrupts are off.

The values of bytes in the buffer are consecutively from 1 to 128.

After first transmission I am sometimes receiving a good data

but more often first 32 bytes are corrupted in the same way.

After first transmission have been sent all other are giving

me unfilled buffer - data is staying the same. It looks like

the DMA isn't filling the memory. After UPP configuration the 

testing loop looks like that:

while (true)
{
System_printf("\r\n========== Loop no %d begin ==========", counter);
System_printf("\r\nSending:\r\n");
for (unsigned int i = 0; i < 0x80; i++)
{
	System_printf(" %3d", xmit_buffer[i]);
	if (i % 0x20 == 0 && i > 0)
	System_printf("\r\n");
}
System_flush();
UPPRegisters->UPQD0.value = (unsigned int)rec_buffer;  <- rec buffer is a pointer for dynamic allocated memory with align
UPPRegisters->UPQD1.value = 0x00010080;   			
UPPRegisters->UPQD2.value = 0x00000080;   			

UPPRegisters->UPID0.value = (unsigned int)xmit_buffer;  <-xmit_buffer is a pointer for dynamic allocated memory with align

UPPRegisters->UPID1.value = 0x00010080;   			

UPPRegisters->UPID2.value = 0x00000080;   	

for (int i = 0; i < 100000; i++) {}  //additional delay

while(UPPRegisters->UPIS2.bits.PEND == 1){};

while(UPPRegisters->UPQS2.bits.PEND == 1){};

for (int i = 0; i < 100000; i++) {}  //additional delay

System_printf("\r\nTransfer complete");

System_printf("\r\nReceived:\r\n");

for (unsigned int i = 0; i < 0x80; i++)
{
	System_printf(" %3d", rec_buffer[i]);
	if (i % 0x20 == 0 && i > 0)
		System_printf("\r\n");
}

System_flush();



for (unsigned int i = 0; i < 0x80; i++)
	if (xmit_buffer[i] != rec_buffer[i])
	{
		System_printf( "Incorrect at position %d", i);
		break;
	}



for (unsigned int i = 0; i < 0x80; i++) // reseting in buf
	rec_buffer[i] = 0;

System_printf("\r\n========== Loop no %d end ============", counter++);

System_flush();
}

I am wondering is there something that I forgot about. Does somebody

has a sample of code with this type of transmission that works on his

board and I will check it using my BDK. I suspect that there is definitely

something wrong with the hardware.

Joe,

Thanks for your answer. I have resolved this problem yesterday after tough fight

and you are right that it was because of the cache. Previously I disabled it

but it seems that it didn't help. I added following code to the configuration file:

var Cache = xdc.useModule('ti.sysbios.hal.Cache');
Cache.CacheProxy = xdc.useModule('ti.sysbios.hal.CacheNull');

It looks like it didn't disabled the cache like I wanted. So at this point it must to be

validated each time you are writing or reading using DMA like you said.