Latest VSOS Kernel (3.66) available here

Discussion about writing software for VS1005 and the VSOS Operating System. Also posts about VS1005-related hardware design and device drivers should be posted here.
Locked
User avatar
Henrik
VLSI Staff
Posts: 1294
Joined: Tue 2010-06-22 14:10

Re: Latest VSOS Kernel (3.30) available here.

Post by Henrik »

Hello forum users!

It is with great pleasure that I present you with the latest version 3.30 of the VSOS Kernel.

There are some changes potentially causing incompatibility, so please read at least the first two ones of the following notes carefully!!!

Changes:
  • VSOS + VSOS Shell + UARTIN.DL3 character string handling changed to make it possible to later better support Unicode charaters. You must update all of them before you get a working system with the shell and UART input/output working! We are sorry for this one, but it needed to be changed sooner or later.
  • System UIMessages escape character changed from Ctrl-A to Ctrl-B to avoid clashed with the VSOS Shell command line editor and full-screen file editor. Microcontroller programs the use UIMessages through the Ctrl-A mechanism need to be changed! We are sorry for this one, too.
  • Added post-crash Shell that activates after a null-pointer call.
  • Added better tracing capabilities.
  • Added new high-definition audio codecs: DSD (DSD64, DSD128, DSD256), ALAC (upto 24-bit 96 kHz), AIFF (upto 24-bit 352 kHz).
  • Enhanced existing audio drivers for high-definition: WAV (DXD support, 32-bit integer and floating point upto 352 kHz), FLAC (upto 24-bit 96 kHz).
  • Enhanced many of the user application, e.g. preg can now access registers by symbolic name and write to them.
  • VSOS Shell and VSOS Audio Subsystem documents updated.
I hope you have a good time with the new features!

Kind regards,
- Henrik
Attachments
VSOS_330_RootAndLibrariesSourceCode.zip
VSOS 3.30 Root files with source code and documentation
(5.74 MiB) Downloaded 644 times
vside_win32_v240.exe
VSIDE 2.40 including VSOS 3.30 kernel (note: Help/About says 2.39 but it's still with all 2.40 files.)
(13.54 MiB) Downloaded 740 times
Good signatures never die. They just fade away.
User avatar
Henrik
VLSI Staff
Posts: 1294
Joined: Tue 2010-06-22 14:10

Re: Latest VSOS Kernel (3.30) available here.

Post by Henrik »

Hello all!

Here is a slightly bug-fixed version of the VSOS Root and Libraries Source Code package for VSOS 3.30.

The new version corrects uartin behaviour (CTRL-B now really replaces CTRL-A for UIMessages) and there is a new, alternative version of config.txt called config_audio_decoders.txt which can be used when the best quality is required from the hi-res audio decoders.

The VS1005 VSOS Audio Subsystem document has also been slightly modified, the main change being specifying that audio decoder speed tests have been made with a 8 KiW audio buffer.

Kind regards,
- Henrik
Attachments
VSOS_330a_RootAndLibrariesSourceCode.zip
VSOS 3.30 Root files with source code and documentation, corrected version
(5.75 MiB) Downloaded 742 times
Good signatures never die. They just fade away.
User avatar
Panu
VSDSP Expert
Posts: 2829
Joined: Tue 2010-06-22 13:43

Re: Latest VSOS Kernel (3.30) available here.

Post by Panu »

Hi all!

Fixed unlink; deleting a non-closed file caused bad things to happen. The updated kernel (3.31) is here:
viewtopic.php?f=13&t=1963&p=9889#p9889

Or download here: VSOS_331-2016-08-30-15-34-VSOS_331_RC2.zip

-Panu
User avatar
Panu
VSDSP Expert
Posts: 2829
Joined: Tue 2010-06-22 13:43

Re: Latest VSOS Kernel (3.31) available here.

Post by Panu »

VSOS 3.32 here. Fixes a loader bug.

-Panu
User avatar
Panu
VSDSP Expert
Posts: 2829
Joined: Tue 2010-06-22 13:43

VSOS Kernel 3.33

Post by Panu »

Dear Members,

Here's a new VSOS kernel version 3.33. This kernel version fixes a bug in the loader and adds powerful debugging features to VSOS.

It's happened to all of us, that we're writing a program, then running it, and suddenly the program gets stuck, nothing happens, and you get stuck wondering what has happened and where the code is stuck at. Now there's a driver INTTRACE.DL3, which binds to the power button interrupt. Whenever you press the power button, you will get a Stop trace, which prints out call stacks, complete with program::function names, timer queues and interrupt lists. It often pinpoints exactly what is running and where the code is stuck (unless it's stuck in an interrupt....). You can use the driver by adding line INTTRACE to your CONFIG.TXT.

Here's an example of a Stop trace:

Code: Select all

VSOS SHELL
S:>playfile d:07 - Orinoco Flow.mp3
Playing '07 - Orinoco Flow.mp3'
[00:01]  // <----- POWER BUTTON PRESSED NOW ------->
Stop at 37160(0x9128): IROM::rtos2[128]
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 0x1e44 @ stack 0x02e2, KERNEL::RunLibraryFunction[33]
Next: PC 0x4876 @ stack 0x02dc, IntTrace::IntReguC[28]
Next: PC 0x4040 @ stack 0x02b5, AUODAC::AudioWrite[68]
Next: PC 0x08ca @ stack 0x02ac, KERNEL::vo_fwrite[30]
Next: PC 0x4fce @ stack 0x02a4, AUDIODEC::DefaultCSOutput[228]
Next: PC 0xe383 @ stack 0x028c, IROM::CodMpg[3491]
Next: PC 0xd7d8 @ stack 0x0277, IROM::CodMpg[504]
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 0x16e (0xe free)
Stack Trace: current PC 0x918f, IROM::rtos2[231]
Next: PC 0x4040 @ stack 0x02b5, AUODAC::AudioWrite[68]
Next: PC 0x08ca @ stack 0x02ac, KERNEL::vo_fwrite[30]
Next: PC 0x4fce @ stack 0x02a4, AUDIODEC::DefaultCSOutput[228]
Next: PC 0xe383 @ stack 0x028c, IROM::CodMpg[3491]
Next: PC 0xd7d8 @ stack 0x0277, IROM::CodMpg[504]
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:0x353d 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:0x353d c0:0x0080 d2:0x0000 d1:0x0001 d0:0x0020
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::rtos2[231]
Next: PC 0x2bab @ stack 0x1c1e, KERNEL::CyclicMainLoop[42]
Next: PC 0x90b5 @ stack 0x1c11, IROM::exit
Registers:
i0:0x1c1f i1:0x0012 i2:0x1b72 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:0x0063 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::rtos2[231]
Next: PC 0x4a74 @ stack 0x0096, PLAYFILE::main[139]
Next: PC 0x1e44 @ stack 0x008c, KERNEL::RunLibraryFunction[33]
Next: PC 0x4966 @ stack 0x0086, SHELL::main[47]
Next: PC 0x03c1 @ stack 0x007c, KERNEL::LoadDrivers[193]
Next: PC 0x049d @ stack 0x003e, KERNEL::main[157]
Next: PC 0x0087 @ stack 0x0032, KERNEL::startup[7]
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:0x00da d2:0x0000 d1:0x0000 d0:0x003c
p1:0x0000 p0:0x0000 ls:0x03cd le:0x03d8 lc:0x0000 mr0:0x0210 lr0:0x9184

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

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

Timer queue 0x02b6 for task 0x093c ("DECOD")
Tick count: 0x0001
For more information about Stop traces, see here and here.


There's another debugging feature that helps to detect calls to any library which has been already dropped from memory. Now any call to such library will result in a stop trace, identifying the problem.

Here's an example program that demonstrates this feature. It loads the program "LS", which is used to get directory listings of short file names, calls it, drops it and calls it again.

Code: Select all

ioresult main(char *parameters) {
	void *lib = LoadLibrary("LS");
	printf("Call1, this should be ok:\n");
	RunLoadedFunction(lib,ENTRY_MAIN,(int)"S:"); //calls a lib
	
	DropLibrary(lib);
	printf("Call2, this should fail:\n");	
	RunLoadedFunction(lib,ENTRY_MAIN,(int)"S:"); //CALLS A DROPPED LIB!!!
}
And here's the result:

Code: Select all

S:>droptest
Call1, this should be ok:
[SYS] VS1005-E.FS CONFIG.TXT HELLO.MP3 VSOS.INI CONFIG.BAK SHELL.AP3

Call2, this should fail:

Call to dropped lib!
ZeroPtrCall from 7477(0x1d35) KERNEL::CallToDroppedLibrary[17]
i0=2178(0x0882) UNASSIGNED=4632(0x1218)

Task 0x0021, priority 1, in RUNNING, name "MainTask"
  State: 3 (TS_READY)
  Stack: Start 0x0030, size 0x200, in use 0xa1, max used 0x168 (0x98 free)
  Stack Trace: current PC 0x3e85, Tasks::main[195]
    Next: PC 0x1e2c @ stack 0x009e, KERNEL::RunLibraryFunction[33]
    Next: PC 0x0b2f @ stack 0x0098, Zero Pointer Call Trap
    Next: PC 0x3c91 @ stack 0x0091, DROPTEST::main[30]
    Next: PC 0x1e2c @ stack 0x008c, KERNEL::RunLibraryFunction[33]
    Next: PC 0x3bfc @ stack 0x0086, shell::main[47]
    Next: PC 0x03bb @ stack 0x007c, KERNEL::LoadDrivers[193]
    Next: PC 0x048e @ stack 0x003e, KERNEL::main[142]
    Next: PC 0x0087 @ stack 0x0032, KERNEL::startup[7]

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::rtos2[231]
    Next: PC 0x2b94 @ stack 0x1c1e, KERNEL::CyclicMainLoop[42]
    Next: PC 0x90b5 @ stack 0x1c11, IROM::exit
  Registers:
    i0:0x1c1f i1:0x0012 i2:0x1b72 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

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

Interrupts:
  INT  0 INT_DAC     , pri 2, vector 0x3611= auodac::DacInterrupt
  INT  6 INT_MAC0    , pri 2, vector 0x384d= auiadc::AdcInterrupt
  INT 12 INT_UART_TX , pri 1, vector 0x3154= uartin::UartTransmitInterrupt
  INT 13 INT_UART_RX , pri 1, vector 0x3184= uartin::UartReceiveInterrupt
  INT 15 INT_TIMER1  , pri 2, vector 0x2970= KERNEL::ApplyGFixes[49]
  INT 16 INT_TIMER2  , pri 2, vector 0x2970= KERNEL::ApplyGFixes[49]

Starting POST-CRASH SHELL, be careful.

VSOS SHELL
S:>
S:>
From this Stop trace you can identify, that a call to a dropped library has occurred, and scanning the stack trace, you can see DROPTEST::main[30] immediately after the Zero Pointer Call Trap line. This gives you a clear indication that the program DROPTEST has done something bad in its function main().

This feature will help to detect if you have accidentally dropped a library which is still in use. Without this tracking feature, such calls are time bombs - they may appear to be working for a while, since the memory was not cleared, but crash afterwards at random locations, which is always very hard to trace. This tracking feature is implemented in the DropLibrary function by filling any code regions that are freed with JMPI operations to kernel function CallToDroppedLibrary, which prints out a message and then jumps to ZeroPtrCall, which gives the trace.

Ok, here's the important part:

For the trace to give best and most readable values, you need new versions of TRACE.DL3, INTTRACE.DL3, TASKS.DL3, VS1005G.SYM and KERNEL.SYM in your board's SYS directory. The KERNEL.SYM file is created whenever a new kernel is built; you must manually copy this file from your kernel source code folder to S:SYS/KERNEL.SYM to get correct traces. Otherwise the kernel function names either will not appear or will be incorrect. Symbols from assembly language code aren't properly displayed at the moment; that's why there may be some strange looking interrupt functions pointing to KERNEL::SomeIncorrectSymbol, don't be confused.

A new root image is also published, with new versions of the tracing tools and a few small updates here and there.

Happy hunting!
-Panu
Attachments
VSOS_333-2016-09-28-19-28-RC1.zip
VSOS 3.33 Kernel. VSIDE Solution with source code.
(225.62 KiB) Downloaded 557 times
VSOS_333_RootAndLibrariesSourceCode.zip
VSOS 3.33 Root and Libraries source code
(5.81 MiB) Downloaded 634 times
User avatar
Panu
VSDSP Expert
Posts: 2829
Joined: Tue 2010-06-22 13:43

Re: Latest VSOS Kernel (3.33) available here.

Post by Panu »

Here's again a new kernel, 3.35. This one automatically resets any interrupt vectors and interrupt enables that would be left pointing to a dropped library. I has been proven very helpful with interrupts.

VSOS Kernel 3.35: VSOS_335-2016-09-30-09-49-RC2.zip


-Panu
User avatar
Henrik
VLSI Staff
Posts: 1294
Joined: Tue 2010-06-22 14:10

Re: Dir bug fix

Post by Henrik »

Hello!

The new kernel 3.35 revealed a bug with Dir which failed if called with the "-a" option. This also broke PlayDir which uses Dir. Here's a corrected version, which will be included in the next release of the root image.

Copy Dir.dl3 to your system's SYS/ folder, or you can alternatively recompile the Solution.

Kind regards,
- Henrik
Attachments
Dir111.zip
Bug-fix version of Dir that doesn't write through a zero pointer when called with option -a
(27.29 KiB) Downloaded 485 times
Good signatures never die. They just fade away.
User avatar
Henrik
VLSI Staff
Posts: 1294
Joined: Tue 2010-06-22 14:10

Re: Latest VSOS Kernel (3.40) available here.

Post by Henrik »

Hello forum users!

Panu and I combined our forces and put together a brand-new VSOS release just in time for electronica in Germany next week. The new release contains pretty much everything we have done here at VLSI since the last one. The release is included in the new VSIDE v2.41 package.

New features of VSOS 3.40 are as follows:
  • Better stability when booting.
  • Hardware SPI now adapts speed according to system clock.
  • Debugging and tracing capabilities enhanced.
  • If using the VSOS 3.40 solution provided in the link below, both External and Internal SPI flash version are compiled automatically.
The new VSIDE 2.41 also offers some new features:
  • New, more powerful VS1005g External and Internal flash prommers.
  • Updated and new include files for VS1005g and VSOS.
  • Separate templates for VSOS 3.40 External or Internal SPI flash.
Also a new version of the VSOS Root and Libraries Source Code package is provided. Remember to update your SYS/ folder with the new versions!

We recommend yo update to this new release immediately, to get a hold on the new, powerful debugging features!

Kind regards,
- Henrik
Attachments
vside_win32_v241.exe
VSIDE 2.41 containing templates for VSOS 3.40 and required .h file updates.
(14.25 MiB) Downloaded 604 times
VSOS_340_RootAndLibrariesSourceCode.zip
VSOS 3.40 root folder and libraries with source code.
(5.85 MiB) Downloaded 753 times
VSOS_340.zip
VSOS 3.40 as a solution. Automatically generates VSOS for internal and external flash. Requires VSIDE 2.41.
(278.06 KiB) Downloaded 538 times
Good signatures never die. They just fade away.
User avatar
Henrik
VLSI Staff
Posts: 1294
Joined: Tue 2010-06-22 14:10

Re: Latest VSOS Kernel (3.40) available here.

Post by Henrik »

Hello!

We noticed that there's an incompatibility which prevents the S/PDIF output driver AUOSPDA.DL3 from running under VSOS 3.40. Here is an updated version of the driver, in both source code and binary form.

Kind regards,
- Henrik
Attachments
auospda.dl3
Copy this into your SYS/ folder
(5.19 KiB) Downloaded 470 times
AUXSPDIF.zip
Full VSIDE Solution for the driver
(24.75 KiB) Downloaded 499 times
Good signatures never die. They just fade away.
User avatar
Henrik
VLSI Staff
Posts: 1294
Joined: Tue 2010-06-22 14:10

Re: Latest VSOS Kernel (3.41) available here.

Post by Henrik »

Hello!

We found a regression which causes that applications cannot load the next application using the "setting-appFile" method. The symptom is that when you try to load the next application, the board resets. This has been corrected in the newest VSOS v3.41 here. This should only matter with people who use the (usually graphical) Init.ap3 application. For those of you who use the VSOS Shell environment, it should (usually) make no difference.

Kind regards,
- Henrik
Attachments
VSOS_341.zip
VSOS 3.41 for both External and Internal SPI Flash.
(280.13 KiB) Downloaded 564 times
Good signatures never die. They just fade away.
Locked