Set Input and Output buffer size

Panu · Post by **Panu** » Thu 2016-09-08 8:38

We have observed cases in which the value returned is 0 even though a USB stick is connected and no other USB operations are going on.

That's easily explained: the USB hardware sends SOF (Start-of-Frame) packets automatically at 1 millisecond intervals. You'll run into one eventually.

But as I said, I'm working on the USB right now, on a proper attach/detach identification method, I'd rather not think about an ad hoc method at the moment, while there's still hope that my better method will work... If I run into a brick wall, I'll think about it then.

-Panu

PS. Ok, I said I don't want to advertise ad hoc methods at this time, but I do know one customer has used the GET_LINES method successfully by reading it again in case the first read results a zero...

Henrik · Post by **Henrik** » Fri 2016-09-16 13:47

Hello!

While Panu is still working on the proper solution, here's one more stop-gap patch.

I had to modify the USB Host driver a bit so that it locks hardware both when reading and writing. Now the check routine can look for the hardware only when the USB Host driver is not doing anything - which should end the issue of false positives.

To test the system, copy usbhost.dl3 and usbmon.dl3 to your SYS folder, then insert a USB stick and run the following commands:

Code: Select all

S:>setclock usb
S:>driver +usbhost u
S:>driver +usbmon

The UsbMon driver turns off LED2 (bottom right on VS1005g DevBoard) for a second and prints a stream of '!' characters as long as there is no USB device attached. You can see in the source code how monitoring has been implemented. In two hours of testing, I didn't get this program to fail once.

I hope this is useful!

Kind regards,
- Henrik

[EDIT 2016-09-19: UsbMon removed because a more robust version is available in the next message.]

Henrik · Post by **Henrik** » Mon 2016-09-19 12:01

Oh well,

during the weekend UsbMon gave a couple of false deattaches. Attached to this message is a new version which is currently under trial and should fix that issue. See the source code for what the driver is supposed to do (short: print a number between 1-7 for a situation which would have given a false positive with the old program, 'D' for a true deattach situation).

Kind regards,
- Henrik

isonthomas · Post by **isonthomas** » Tue 2016-09-20 13:31

Hi Henrik,

I tried to implement the usb detection procedure but I am facing some issues.

I have modified the Cyclic Function slightly as given below:

Code: Select all

void MyCyclicFunc(register struct CyclicNode *this)
{
	static int i = 0, usbDeattachCounter = 0;
	i++;
	/* Check USB status ONLY if USB operation is not underway. */
	if (!AttemptHwLocksBIP(HLB_NONE, HLIO_NONE, HLP_USB))
	{
		int usbAttached;
    
	    /* Forbid multitasking to prevent task switching during next command. */
	    Forbid();
	    
	    /* Evaluate GET_LINES three times: if SOF happens during
	       one of them, it won't happen on all three occasions. */
	    usbAttached = GET_LINES() | GET_LINES() | GET_LINES();
	   
	     /* Return to multitasking. */
	    Permit();
	   
	    ReleaseHwLocksBIP(HLB_NONE, HLIO_NONE, HLP_USB);
	    
	    if (!usbAttached)
	    {
			if (++usbDeattachCounter >= 8)
			{
				usbDeattachCounter--;
				/* USB looks deattached for at least 8 consecutive calls:
				it really _IS_ deattached */
				
			/** This is my variable to store the USB connection status */
			   if(usb_detect == 1)
					printf("Detached\n");
				usb_detect = 0;
			}
			//else
			//{
				/* USB looks deattached, so show that as debug output,
				but still don't consider USB deattached. */
				//printf("%d", usbDeattachCounter);
			//}
			i = 0;
	    } 
	    else
	    {
			/* USB seems attached, clera the deattach counter. */
			usbDeattachCounter = 0;
			/** This is my variable to store the USB connection status */
			if(usb_detect == 0)
				printf("Attached\n");
			usb_detect = 1;
		}
	}
}

I have removed the LED operations and prints. Also I added the updation of my usb connection status variable usb_detect in the function.

The cyclic operation is initialized in main by calling :

Code: Select all

	AddCyclic(&myCyclicNode, TICKS_PER_SEC/50, TICKS_PER_SEC/50);

The structure given in the Usb_Mon code is also added as :

Code: Select all

struct CyclicNode myCyclicNode = {
  {0},			/* node */
  MyCyclicFunc,		/* cyclicFunction */
  0,			/* interval */
  0,			/* nextActivation */
  0			/* userTag */
};

I am able to detect the USB attach and detach statuses but the application crashes randomly during my USB indexing operation where I search for the audio files in the USB stick. USB read and write operations will happen at a high rate during this operation.

Kindly let me know if there is mistake in the implementation or if I have to do some additional settings.

-Ison

isonthomas · Post by **isonthomas** » Wed 2016-09-21 6:31

Hi Henrik,

The USB detection method seems to work fine after some quick tests. We are continuing the regression test.

One observation we have is that the indexing procedure gets stuck some times. There is a high rate of usb read and write operations during this procedure.

Previously we have observed this issue in both SD card and USB. Here we were having SPI communication at a very high frequency and hence the SPI interrupt was getting called very frequently. We suspected that the other processes and task might not be getting enough time for their processing. We added a deliberate 10ms delay between a command and a response so that atleast that much time is ensured for other tasks between commands. The SD card seems to work fine after this modification but the indexing in USB gets stuck. We increased the delay to 20ms but still the result is same.

Is it possible that so many operations on the USB (reading, writing and checking for detection status etc) to cause an issue. Also is there any possibility where the driver could get stuck indefinitely?

-Ison

Henrik · Post by **Henrik** » Wed 2016-09-21 11:31

Hi Ison,

isonthomas wrote:The USB detection method seems to work fine after some quick tests. We are continuing the regression test.

Excellent. I have not been able to get a single false positive in my 49 hours of letting the software run. Actually, out of the debug print series "1234567D" I've not even got a '2' a single time - unless I deattached the cable, of course.

isonthomas wrote:Is it possible that so many operations on the USB (reading, writing and checking for detection status etc) to cause an issue. Also is there any possibility where the driver could get stuck indefinitely?

I don't know about this. However, Panu has just written a useful and extremely small driver that lets you display the current execution point and stack trace of all tasks running whenever you push the power button. Running it a few times might help to see where you get stuck.

Panu is out of office today, but I'll ask him to release the software tomorrow - unless he notices this message earlier.

Kind regards,
- Henrik

isonthomas · Post by **isonthomas** » Wed 2016-09-21 17:22

Hi Henrik,

Thanks for the inputs.

Kindly let me know if we can print the stack track when the application crash. I have added TRACE.dl3 to the SYS folder. I have observed some prints coming irregularly for some application crash.

-Ison

Panu · Post by **Panu** » Thu 2016-09-22 14:13

Dear Ison and other forum users,

Here is a driver that will hook to the Power Button (POWBTN) interrupt. When the driver is loaded and the power button is pressed, it will print out a task listing and stack traces. It is very useful for finding out what the state of the VSOS is when an application is crashed or stuck. To find out, you need this driver INTTRACE.DL3, and also TRACE.DL3, and TASKS.DL3, make sure all 3 files are in S:SYS/. Also you need to add the line INTTRACE to your CONFIG.TXT to load the driver.

Below you will find an example listing. To get it, I have started to play a file from an SD card and then hit the power button to get the trace.

Study the trace to find out for example, that:
- The Stop Interrupt has occurred while the DECODe task was active
- The Decoder task is executing AUODAC program's AudioWrite function, called by AUDIODEC's DecaultCSOutput(), while running the MP3 decoder, initiated by AUDIODEC's MyDecodeAudio function, invoked by PLAYFILE program's PlayerThread.
- There is a Cyclic task, currently in Wait state
- MAIN task is running PLAYFILE program's function main(), called by SHELL program's function main().
- There are three RTOS timers currently active.

All in all, it's a very comprehensive listing, and the indexes can often pinpoint the exact location in a function, where the code is running. The values in [brackets] are the word indexes of return addresses, e.g. where the execution will continue after the function call has returned. If you really need to pin-point the exact line of code in the function, search the .s files in Emulation-Debug folder of your solution to find the function and calculate the addresses from the beginning of the function. But in 98% of the cases, it's sufficient information for debugging to see which function the code is stuck in

-Panu

VSOS SHELL
S:>PLAYFILE d:Coldwater Canyon.mp3
Playing 'Coldwater Canyon.mp3'
[00:01]
Stop at 37160(0x9128): IROM
Task 0x093c, priority 10, in RUNNING, name "DECOD"
State: 4 (TS_WAIT)
Stack: Start 0x0254, size 0x17c, in use 0x7c, max used 0x166 (0x16 free)
Stack Trace: current PC 0x5423, Tasks::main[185]
Next: PC 0x1e06 @ stack 0x02e2, KERNEL
Next: PC 0x4876 @ stack 0x02dc, IntTrace::IntReguC[28]
Next: PC 0x4040 @ stack 0x02b5, AUODAC::AudioWrite[68]
Next: PC 0x08b2 @ stack 0x02ac, KERNEL
Next: PC 0x4fce @ stack 0x02a4, AUDIODEC::DefaultCSOutput[228]
Next: PC 0xe383 @ stack 0x028c, IROM
Next: PC 0xd7d8 @ stack 0x0277, IROM
Next: PC 0x52a8 @ stack 0x0270, DECMP3::CodMpgPlayFramePatch[10]
Next: PC 0x4d57 @ stack 0x0260, AUDIODEC::MyDecodeAudio[25]
Next: PC 0x49e2 @ stack 0x0258, PLAYFILE::PlayerThread[14]

Task 0x093c, priority 10, in waitQueue, name "DECOD"
State: 4 (TS_WAIT)
Stack: Start 0x0254, size 0x17c, in use 0x7c, max used 0x16d (0xf free)
Stack Trace: current PC 0x918f, IROM
Next: PC 0x4040 @ stack 0x02b5, AUODAC::AudioWrite[68]
Next: PC 0x08b2 @ stack 0x02ac, KERNEL
Next: PC 0x4fce @ stack 0x02a4, AUDIODEC::DefaultCSOutput[228]
Next: PC 0xe383 @ stack 0x028c, IROM
Next: PC 0xd7d8 @ stack 0x0277, IROM
Next: PC 0x52a8 @ stack 0x0270, DECMP3::CodMpgPlayFramePatch[10]
Next: PC 0x4d57 @ stack 0x0260, AUDIODEC::MyDecodeAudio[25]
Next: PC 0x49e2 @ stack 0x0258, PLAYFILE::PlayerThread[14]
Registers:
i0:0x02b6 i1:0x0012 i2:0x352d i3:0x0943
i4:0x02b5 i5:0x0000 i6:0x02c2 i7:0xfc08
a2:0x0000 a1:0x0004 a0:0x8000 b2:0x0000 b1:0x0000 b0:0x0000
c2:0x0000 c1:0x352d c0:0x0080 d2:0x0000 d1:0x0001 d0:0x0030
p1:0x0000 p0:0x0040 ls:0xe337 le:0xe388 lc:0x0006 mr0:0x0210 lr0:0x9184

Task 0x1c01, priority 10, in waitQueue, name "cyclic"
State: 4 (TS_WAIT)
Stack: Start 0x1c10, size 0x100, in use 0x29, max used 0x3a (0xc6 free)
Stack Trace: current PC 0x918f, IROM
Next: PC 0x2b79 @ stack 0x1c1e, KERNEL
Next: PC 0x90b5 @ stack 0x1c11, IROM::exit
Registers:
i0:0x1c1f i1:0x0012 i2:0x1b76 i3:0x1c08
i4:0x1c1e i5:0x0000 i6:0x1c2b i7:0xfc08
a2:0x0000 a1:0x0004 a0:0x8000 b2:0x0000 b1:0x0000 b0:0x0000
c2:0x0000 c1:0x0000 c0:0x0064 d2:0x0000 d1:0x0005 d0:0x0004
p1:0x0000 p0:0x0000 ls:0xebab le:0xffff lc:0x0000 mr0:0x0210 lr0:0x9184

Task 0x0021, priority 1, in waitQueue, name "MainTask"
State: 4 (TS_WAIT)
Stack: Start 0x0030, size 0x200, in use 0x81, max used 0x168 (0x98 free)
Stack Trace: current PC 0x918f, IROM
Next: PC 0x4a74 @ stack 0x0096, PLAYFILE::main[139]
Next: PC 0x1e06 @ stack 0x008c, KERNEL
Next: PC 0x4966 @ stack 0x0086, SHELL::main[47]
Next: PC 0x03b4 @ stack 0x007c, KERNEL
Next: PC 0x048e @ stack 0x003e, KERNEL
Next: PC 0x0087 @ stack 0x0032, KERNEL
Registers:
i0:0x0097 i1:0x0012 i2:0x0940 i3:0x0028
i4:0x0096 i5:0x0000 i6:0x00a3 i7:0xfc08
a2:0x0000 a1:0x0004 a0:0x8000 b2:0x0000 b1:0x0000 b0:0x0000
c2:0x0000 c1:0x00fa c0:0x0004 d2:0x0000 d1:0x0000 d0:0x003c
p1:0x0000 p0:0x0000 ls:0x03c0 le:0x03cb lc:0x0000 mr0:0x0210 lr0:0x9184

Timer queue 0x0097 for task 0x0021 ("MainTask")
Tick count: 0x009d

Timer queue 0x1c1f for task 0x1c01 ("cyclic")
Tick count: 0x0013

Timer queue 0x02b6 for task 0x093c ("DECOD")
Tick count: 0x0001

isonthomas · Post by **isonthomas** » Fri 2016-09-23 13:00

Hi Panu,

Thanks for the library.

May I know the duration for which the PWRBTN pin needs to be pulled low to generate the interrupt?

-Ison

Panu · Post by **Panu** » Sat 2016-09-24 5:46

May I know the duration for which the PWRBTN pin needs to be pulled low to generate the interrupt?

Not low, high. Not sure about the duration, should be very fast.

-Panu

VSDSP Forum

Set Input and Output buffer size

Re: Set Input and Output buffer size

Re: Set Input and Output buffer size

Re: Set Input and Output buffer size

Re: Set Input and Output buffer size

Re: Set Input and Output buffer size

Re: Set Input and Output buffer size

Re: Set Input and Output buffer size

Application crash debug tracing

Re: Set Input and Output buffer size

Re: Set Input and Output buffer size