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.
madboy-software
User
Posts: 11
Joined: Tue 2019-06-04 14:17

Memory management issues

Post by madboy-software » Tue 2019-06-04 14:17

Hello!

We are using the VS1005 dev board. Our plan is to create a recorder/player that can choose between inputs (analog, optical and FM radio). The recordings should go on an SD card. We are controlling the VLSI chip with an Atmel microcontroller, the communication is working fine.

The problem in question is that we have updated the VSOS version from an older version to the current 3.57 and suddenly the chip is running out of memory and failing to write to the SD card. Could the VSOS update have somehow messed up the memory management? The CONFIG.TXT file has been kept the same. We have also tried downgrading the VSOS to an older one and the issue still persists.

All of our problems are coming from the same change in our company: the programmer of this project has changed halfway through and documentation of the project has been lacking.

We can supply the source code to VLSI by email if necessary.

- Teemu

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

Re: Memory management issues

Post by Panu » Tue 2019-06-04 20:04

Hi!

Hmm, It must be something in the SYS folder which has changed. Do you have any idea how close to running out of memory you were before, e.g. did you receive any "Warning: only xxx something free!" warnings?

Sure, we can take a look.

The LIBLIST and/or LIBLIST2 commands could give helpful information about what's loaded. As well as FRAGS.

-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 » Wed 2019-06-05 8:31

Thanks for the reply.

We changed from the external memory of the chip to the internal memory and that made it somehow not run completely out of memory. The "only ****w free!" warnings are still appearing, but we don't know if the previous programmer had the same issue. We are now working on getting the input changing done.

Could you provide me with some documentation for the functions related to input changing? Mainly for the following functions:
- LoadLibrary();
- LoadLibraryP();
- RunLoadedFunction();

How should I set the S/PDIF samplerate after using LoadLibrary(), since it only accepts one param?

If we face any more issues, I will reply to this thread.

EDIT:
Still getting "E'Out of mem 0 (@0,1646w,0)." after loading AUXSPD lib and trying to record.

EDIT 2:
It would also be really helpful if you could provide me with an example snippet of code for changing the input to FM radio and setting the frequency etc.

- Teemu

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

Re: Memory management issues

Post by madboy-software » Wed 2019-06-05 14:32

An update on this issue.

We have just realized that it is actually unnecessary to write any input changing code for the VLSI chip if we can just boot it in UART console mode and control it from the front panel using that. A couple of problems arise with this approach:

#1: Is it possible to change the recording volume during use of the "rec" command?
#2: The rec command vu meter is apparently not working, at least copy-pasting the command "~0209" does absolutely nothing.

This would be a much simpler approach if we can sort these issues out.

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

Re: Memory management issues

Post by madboy-software » Wed 2019-06-12 12:09

I am happy tell you that we have now advanced quite nicely on the project, partially thanks to your help. But the issue of running out of memory still persists.

Here is a list of currently loaded libraries, from the UART console:

Code: Select all

11 libs loaded:
11 libs loaded:
3300: RUN         38i +    0x +    0y
3326: AUOSPDA    644i +   92x +   32y
35aa: UARTIN     534i +   40x +  522y
37c0: SDSD      1154i +  174x +   36y
3c42: SHELLENV   134i +  262x +    0y
3cc8: MyProg    6000i + 1116x +    2y
5438: AUIADC    1202i +  266x +  474y
58ea: AUISPD     660i +   88x +    6y
5b7e: ENCMP3    5244i + 5684x +   52y
6ffa: BUF23     1646i +  208x +    0y
7668: LIBLIST    992i +  184x +    2y
Free memory after loading drivers:
 I:  1400 words ( 5600 bytes)
 X:  6176 words (12352 bytes)
 Y: 22632 words (45264 bytes)
None of these libraries can be unloaded without interfering with the main function of the project.

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.

Also, when setting MP3 quality to 1 no samples are lost.

We are buffering the SD card writes to a VS23S010 chip, that is working fine.

Is there any trick to saving memory?

EDIT:

The previously mentioned example of configuring the FM demodulator would be VERY helpful.

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

Re: Memory management issues

Post by Henrik » Wed 2019-06-12 15:11

Hello!
madboy-software wrote:
Wed 2019-06-05 14:32
We have just realized that it is actually unnecessary to write any input changing code for the VLSI chip if we can just boot it in UART console mode and control it from the front panel using that. A couple of problems arise with this approach:

#1: Is it possible to change the recording volume during use of the "rec" command?
The rec command always attaches directly to the stdaudioin without any signal processing inbetween. If a digital volume control is required, it is possible to create a small driver that would attach to stdaudioin and implement that feature. However, that would eat from memory that you are already running short of.
#2: The rec command vu meter is apparently not working, at least copy-pasting the command "~0209" does absolutely nothing.
This is odd. I just tested rec with an MP3 file, and I got:

Code: Select all

Silence:
~0209
~0209=-46

Music:
~0209
~0209=-10

Louder music:
~0209
~0209=-3
Did you remember to offer a line feed character after the command? Either 13 (CR) or 10 (LF) would do; I tested with LF.

Then to your next message, for which I'll have some answers either today or latest tomorrow morning.

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 7:09

Thank you for the answer.

Regarding the implementation by UART console, the loaded "MyProg" would not be required that way. I don't think memory would be an issue if we would go that route. We have still made good progress on developing our own software and I think we will use that. UART console seems like a botched and maybe a buggy way to do this.

EDIT:
Even though it is not related to my issue anymore, the ASCII characters 10 and 13 (inputted with CTRL+J and CTRL+M respectively) don't help. Line feed (CTRL+J) causes this error:

Code: Select all

~0209
!cmdLine
CR (CTRL+M) just causes the cursor to return to the beginning of the "~0209" line. Neither produce the wanted VU meter output.

I am using PuTTY to connect. VSOS version 3.57, external SPI flash memory. Rec command is from "VSOS_357_RootAndLibrariesSourceCode.zip" package.

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.

Regards
Teemu

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

Re: Memory management issues

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

Update:

I accidentally bricked the internal flash of the dev board by calling AuInput with a wrong -p pointer. I got it restored, but now I'm running out of memory on BOOT!!! What's going on? Was some sort memory map file corrupted?

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

Re: Memory management issues

Post by Panu » Thu 2019-06-13 11:37

Hi, probably some binary which is loaded at startup is corrupted.. Does the kernel boot into USB mode with GPIO0 button (S1) pressed? If so, then reformat the flash and copy all files. If not, then follow the complete unbricking procedure, complete with reflashing the kernel.

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

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

Re: Memory management issues

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

Hello!
madboy-software wrote:
Thu 2019-06-13 11:18
Update:

I accidentally bricked the internal flash of the dev board by calling AuInput with a wrong -p pointer. I got it restored, but now I'm running out of memory on BOOT!!! What's going on? Was some sort memory map file corrupted?
In addition to what Panu wrote, I suggest that for the future you would replace using the slightly dangerous pointer option -p to the safer device name option -d. E.g. if you want to control AUII2SM.DL3, to it with the -dauii2sm option of AuInput.

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

Post Reply