Build failed!

[George]

Hello.

VSIDE 2.48
solution vs1053-standalone-vside-133.zip http://www.vlsi.fi/en/support/software/ ... ions.html

Build Solution

Code: Select all

vsar: writing Emulation-Debug\libstandalone.a
copy Emulation-Debug\libstandalone.a libstandalone.a
process_begin: CreateProcess((null), copy Emulation-Debug\libstandalone.a libstandalone.a, ...) failed.
make (e=2): Íå óäàåòñÿ íàéòè óêàçàííûé ôàéë.
C:\VSIDE\bin\make.exe: *** [Emulation-Debug/libstandalone.a] Error 2
Build failed!

Rebuild Solution

Code: Select all

Note: vslink: trying library C:\VSIDE\libvs1053b/libc.a
Note: vslink: found symbol _atou from library c
Note: vslink: creating new section "atou" (31 words)
ERROR: vslink: link library standalone not found
C:\VSIDE\bin\make.exe: *** [Emulation-Debug/sciplayer.coff] Error 10

What does this mean and how to fix it?

[pasi]

It seems the copy command fails to copy the "standalone" library, then the linker during rebuild doesn't find the library.

Did you unzip the package before trying to compile it? If there are spaces in the directory path, it may also cause issues.

[George]

Unzip of course.
In addition, I transferred VSIDE and the project directory to the root directory of the C drive, and renamed the directory with the project to a short name. The same result.
Perhaps impotant.
I compiled a solution from VSIDE itself yesterday. After I reinstalled VSIDE in the root drive C, the compilation of errors no longer gave out and regularly issued the firmware to the EEPROM.

[George]

I hope I have solved the problem.
As far as I understand, the site has accumulated a lot of unnecessary information, including the SOLUTION I use. Most likely it was created a long time ago, but it does not work in new versions of VSIDE, but they forgot to remove it. The working app is now in the VSIDE silution examples and the one I need is called "VS1053 ThreeButtonPlayer". It does not give any compilation errors, and a study of the documentation showed that in both cases almost the same prototype boards are used, i.e. the schematics of the device for which both of these solutions are the same.

[pasi]

The VSIDE solution the package was created from builds correctly on VSIDE 2.46, and I don't see why it would not build on a newer release.

You could try "Clean Solution" first.

I can test with the latest VSIDE and with the version from the web.

[pasi]

I tested with freshly downloaded VSIDE 2.48 and vs1053-standalone-vside-133.zip and the solution was built without issues.

[George]

Dear Pasi,
I look at the example in VSIDE "VS1053 ThreeButtonPlayer" and see that I like it. I read the author's comments in hifiplayer.c and see that the author is Pasi Ojala. I think pasi is Pasi Ojala.
So I hope the author will want to answer my questions regarding his code.
So far, only one question now:
MP3 players, as a rule, have the function of storing the last played file. This is necessary so that when the power is turned on, the player does not start playing the SD from the him beginning again. More often than not, it looks like when the power is turned off, the power does not actually turn off, instead the chip is put into hibernation mode. This solution is inconvenient for me, so I would prefer that the number of the file being played was stored in non-volatile memory. It can be either a separate SRAM chip or an FLASH chip. It can even be an existing EEPROM and even the SD itself!
Have you considered this question and how difficult do you think reworking the code is in your opinion? Of course, I can solve this problem with hardware, but it would be a shame to overload the player with many chips when the problem can be easily solved with a small program change.
No, I'm not trying to get you to rewrite the code at all! I just need to know the opinion of the author of the code, does it make sense for me to redo it myself, or is it a deliberate gamble?

[pasi]

The standalone player originated in vs1011 and vs1003, which both have very little instruction RAM. The player thus needed to be very optimized, practically all of it hand-optimized assembly. Adding functionality often required removing some other functionality, or at least a large amount of further optimization.

vs1053 and vs1063 have quite a lot more instruction RAM. Now it's also possible for the customer to develop some code, although the above still somewhat applies.

One way to save the currently playing song was an option in some previous versions. Whenever a new song was started, its number was saved to the EEPROM. In fact, it was saved inside the boot image, in the word that was loaded into the SCI_AICTRL0 (current song) register. So, if the unit was turned off and on, the player would automatically start from the desired song. The same option was available to the volume setting if I recall correctly.

When the code was migrated to VSIDE, it became hard to guarantee that the location of the boot image which loaded SCI_AICTRL0 would be constant, so the SAVE_SONG option was removed. Also, writing to the same location each time is not such a brilliant idea anyway, because each EEPROM cell has a limited write cycle count. An additional hurdle would've been the use of SPI FLASH instead of SPI EEPROM.

An improved version that would work with SPI FLASH would be to reserve a page where a rotating new entry would be written each time, and be erased when becomes full. During startup the page contents would be read and the last valid entry located and used. There should be enough instruction RAM in vs1053 to implement this. (With EEPROM, you can start with the simpler routine.)

The one complication you might not care about is the result when the SD card is changed while the unit is turned off... (Some applications I have written for vs1000 stores the card ID to be able to determine when the card is changed. Some applications just do not need to care.)

[George]

pasi, many thanks for the very detailed information. I was sure that you and your colleagues could not help but devote their attention to this problem.
However, I am confused by the fact that the /WP of FLASH is connected to +E always, and I do not see any free GPIO on VS1053 for write mode for FLASH chip. And at the same time, there is a input signal MOSI in the microSD. Does this mean that I can write any data in microSD only?

[pasi]

/WP is write protect, active low. It thus does not prevent writing to the EEPROM. Writing just uses a different command than reading from the EEPROM.

Due to historical reasons, the boot SPI and SD are not separated by chip select signals, but by using different clock signals, so reading the code may be rather confusing.

DREQ is acting as a MOSI for both the SD and SPI EEPROM/FLASH.
GPIO0 is xCS for SPI (pull-up needed to enable SPI boot),
GPIO1 is SPI clock (and CS for SD),
GPIO2 is MISO (pull-up for SD use, some older chips need a pull-down during SPI boot, thus there's a resistor to GPIO0),
and GPIO3 is SPI clock for SD. (You can find these from the document standalone.pdf )

It seems the code for writing to SPI EEPROM is still there in the vs1053-standalone-vside-133/standalone.c , see defines SAVE_POSITION and SAVE_STUFF. Optimized version in asm-saveword.s . But I'm not guaranteeing that it still works (i.e. that the position is in offset 28 of the boot image).