Memory management issues

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.
User avatar
Henrik
VLSI Staff
Posts: 1146
Joined: Tue 2010-06-22 14:10

Re: Memory management issues

Post by Henrik » Thu 2019-06-13 14:24

Hi!
madboy-software wrote:
Thu 2019-06-13 7:09
After typing this edit, I figured it out: I have to copy-paste from your post and it works with LF (enter or CTRL+M still returns to beginning of line). Apparently the tildes inputted by copy-pasting and typing are different.
A tilde should always be a tilde, and if that was not correct, it wouldnt even give the !cmdLine error message. I more suspect the CR-LF combination.

I prepared a new version of Rec that tries to combat against that possibility. Could you run it, and if you still get !cmdLine errors, could you provide those lines here? (I added some debug prints to that line)

Kind regards.
- Henrik
Attachments
Rec.zip
Test version of Rec, made 2019-06-13
(17.47 KiB) Downloaded 7 times
Good signatures never die. They just fade away.

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

Re: Memory management issues

Post by Henrik » Thu 2019-06-13 14:44

Hello!
madboy-software wrote:
Wed 2019-06-12 12:09
The low amount of free memory is constantly causing audio overflows on recording, usually around 6500 samples lost per second. Only when the device is recording from optical input (S/PDIF) and no audio is playing it doesn't lose samples.
What is your clock speed? If at e.g. the default 60 MHz, and if recording to SD card and not a USB memory, try raising that to 86 MHz by adding this to config.txt: RUN SETCLOCK -l93 86

Another thing to try is to increase the input audio buffer to 4096 samples by adding this to config.txt: RUN AUINPUT -s4096
Or, if yoy change your input dynamically, run AuInput with RunProgram() after starting the input driver.

If these don't help, let me know and I can have a closer look at it.

Kind regards,
- Henrik
Good signatures never die. They just fade away.

madboy-software
User
Posts: 11
Joined: Tue 2019-06-04 14:17

Re: Memory management issues

Post by madboy-software » Thu 2019-06-13 18:11

I will try some of these things tomorrow. However, the -d option was only for debugging and will not be used in the future. As I said, you don't have to worry about the Rec command VU meter, since it won't be used in the future. We have actually tried changing the output/input buffer sample amount and it didn't really help.

I will get back to you tomorrow.

madboy-software
User
Posts: 11
Joined: Tue 2019-06-04 14:17

Re: Memory management issues

Post by madboy-software » Fri 2019-06-14 13:13

Hello Henrik and Panu,

I ran your updated version of the "Rec" command and I got it to work with keyboard input.
Here is the output for different input combinations:

Pressing Alt Gr and the "^ ¨ ~" key (next to Å key) ONCE and typing 0209 <enter>, produces "~0209" in notepad and

Code: Select all

~209
!cmdUnknown
In the VSOS console. When I copy-paste my self-typed input from notepad and press enter, it gives me the VU value:

Code: Select all

~0209
~0209=-55
Pressing Alt Gr and the "^ ¨ ~" key (next to Å key) TWICE and typing 0209 <enter>, produces "~~0209" in notepad and

Code: Select all

~0209
!cmdLine 00 30 32 30 39
In the VSOS console. Copy-pasting from notepad doesn't give wanted output.

Pressing Alt Gr and the "^ ¨ ~" key (next to Å key) TWICE and pressing backspace once, typing 0209 <enter>, produces "~0209" in notepad and

Code: Select all

0209
~0209=-55
In the VSOS console. Copy-pasting from notepad also gives wanted output.

That's it for the Rec command. Now back to our main issue.

As Panu said, I formatted the flash memory and copied over some fresh libraries from "VSOS_357_RootAndLibrariesSourceCode.zip".

The previous clock speed in CONFIG.TXT was:

Code: Select all

SETCLOCK 100
and I changed it to what you told me:

Code: Select all

RUN SETCLOCK -l93 86
I'm not running out of memory on boot anymore, but still running out on recording start.

I changed the input buffer size from 512 to 4096, it was and is still set by this line in the code:

Code: Select all

ioctl(audio.ADCFp, IOCTL_AUDIO_SET_INPUT_BUFFER_SIZE, (void *) ADC_BUFSIZE);
This doesn't help the memory issue at all. The last lines of input when starting recording are:

Code: Select all

IMEM: only 1882w free!
IMEM: only 236w free!
E'Out of mem 0 (@0,992w,0).
'
With S/PDIF as the input the line "E'Out of mem 0 (@0,992w,0).'" gets printed, on AV input (AUIADC) the program doesn't even reach that point when crashing.

It seems that every time I manage to brick the dev board and restore it successfully, the amount of available memory keeps decreasing. This is only the second time I've bricked and restored it. Do you have any clue what is causing this?

I also tried the version left to my hands by the previous programmer. It omits the input changing feature and some others as well. It used to work quite nicely. Now, after the two bricking cases it no longer works. It runs out of memory right after stopping recording. I can confirm that is used to work with the exact same hardware configuration.

Regards
Teemu

User avatar
Panu
VLSI Staff. Currently on holiday.
Posts: 2697
Joined: Tue 2010-06-22 13:43

Re: Memory management issues

Post by Panu » Fri 2019-06-14 17:27

It seems that every time I manage to brick the dev board and restore it successfully, the amount of available memory keeps decreasing. This is only the second time I've bricked and restored it. Do you have any clue what is causing this?
The only cause would be that the firmware and/or kernel versions are not the same.

Or the order of execution has changed. Memory fragmentation can cause to a decrement of the available memory. Check with FRAGS program if fragmentation is occurring.

(Fragmentation occurs when you load libs a, b, c, then drop lib b; empty areas form where lib b was loaded. Then you load lib d and not all of the empty areas get filled completely -> several small empty memory areas that are too small to hold anything useful will waste memory. Solution is to drop everything and then reload all libs.)

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

madboy-software
User
Posts: 11
Joined: Tue 2019-06-04 14:17

Re: Memory management issues

Post by madboy-software » Mon 2019-06-17 7:29

Hello again.

I copied over a backup of a version that has been confirmed working with lots of memory available. Now, it's warning me that there is only about 460W free on IMEM. This shouldn't happen, right? The previous test of this software was with the same VSOS version, same memory (Internal SPI) and the exact same memory contents. It may sound like I'm going insane but I have no idea what's happening.

I also tried running the "FRAGS" program with a newer version of the software and this was the result:

Code: Select all

Libs: Run Auodac Uartin Sdsd sHellenv myProg auIadc auispD auOspda Frags
I 0000: ################ ################ ################ ################
I 1000: ################ ################ ################ ################
I 2000: ################ ################ ################ ################
I 3000: ############RAAA AAAAAAAAAUUUUUUU UUSSSSSSSSSSSSSS SSSSHHPPPPPPPPPP
I 4000: PPPPPPPPPPPPPPPP PPPPPPPPPPPPPPPP PPPPPPPPPPPPPPPP PPPPPPPPPPPPPPPP
I 5000: PPPPPPPPPPPPPPPP PPPPPPPPPPPPPPPP PPPPPPPPPPPPPPPP PPPPPIIIIIIIIIII
I 6000: IIIIIIIIDDDDDDDD DDOOOOOOOOOOFFFF FFFFFFF......... ................
I 7000: ................ ................ ................ ...............#

X 0000: ################ ################ ################ ################
X 1000: ################ ################ ################ ##########FF#AU#
X 2000: SS#HHHHPPPPPPPPP PPPPPPPPPPPPPP#I III#DOO......### #FFFF...........
X 3000: ................ ................ ................ ................
X 4000: ................ ................ ................ ................
X 5000: ................ ................ ................ ................
X 6000: ................ ................ ................ ................
X 7000: ................ ................ ................ ................

Y 0000: ################ ################ ################ AD..UUUUU...UUUU
Y 1000: UIIIIIII######## ################ ................ .####...........
Y 2000: ................ ................ ................ ................
Y 3000: ................ ................ ................ ................
Y 4000: ................ ................ ................ ................
Y 5000: ................ ................ ................ ................
Y 6000: ................ ................ ................ ................
Y 7000: ................ ................ ................ ................

Free: I:  5682 words (17%), X: 21552 words (65%), Y: 26768 words (81%)
Can you explain to me what this output means?

- Teemu

Hannu
Senior User
Posts: 72
Joined: Mon 2016-05-30 11:54

Re: Memory management issues

Post by Hannu » Mon 2019-06-17 8:34

Hi!

The output is for I, X and Y memory. # is kernel or something which frags doesn't know which library uses that part of memory.
The capital letter designates the library reserving the memory area and each letter is 64 words (If I counted right). The key for letters is the libs: line

Anyway you are seeing textual representation of memory usage.

madboy-software
User
Posts: 11
Joined: Tue 2019-06-04 14:17

Re: Memory management issues

Post by madboy-software » Mon 2019-06-17 8:44

Yes, I figured that out by myself. Does that output look good, is it fragmented? Should I do something to combat fragmentation?

Some more possible options we have been thinking about:
  • Is it possible to use the VLSI VS23S010 or VS23S040 for additional (I)RAM?
  • Would you folks at VLSI like to take a look at our source code and find out if memory can be saved or this project even completed with the planned features? We can happily email it to you.

User avatar
Panu
VLSI Staff. Currently on holiday.
Posts: 2697
Joined: Tue 2010-06-22 13:43

Re: Memory management issues

Post by Panu » Mon 2019-06-17 10:16

Hi!
Is it possible to use the VLSI VS23S010 or VS23S040 for additional (I)RAM?
Not as such, no. The way to free memory is to split the application into a wide tree structure with a small root program that holds all the persistent data and calls as many leaf programs as possible to do some small things each, one after another.
Would you folks at VLSI like to take a look at our source code and find out if memory can be saved
Sure, we can take a look. Just include instruction on how to run it in the VS1005 Developer Board with a meaningful test case. Please mail it to support@vlsi.fi.

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

madboy-software
User
Posts: 11
Joined: Tue 2019-06-04 14:17

Re: Memory management issues

Post by madboy-software » Mon 2019-06-17 11:23

Hey Panu, I have sent the code over to support@vlsi.fi.

Post Reply