Windows 10 compatibility

Installing and using VSIDE tools for VLSI Solution's devices that contain a VSDSP signal processor.
stefanpoz
User
Posts: 3
Joined: Wed 2016-07-13 17:13

Windows 10 compatibility

Post by stefanpoz » Thu 2016-07-14 7:19

Hi!
I'm getting some issues when building a VSIDE solution with overlays on Windows 10. The same solution is building correctly on Windows 7.
Here is the end portion of the build output, the lines are numbered for your convenience:

1) MakeOverlaidImage for VS1000/VS1053
2) Opening overlay control file "overlay_control"
3) The static image is "SDPlayer"
4) Read COFF File OvlLowLevelInit.coff
5) Read COFF File OvlInitMMC.coff
6) Read COFF File OvlCheckUpdate.coff
7) Read COFF File OvlLoadConfig.coff
8) Read COFF File OvlGPIOCtrl.coff
9) Read COFF File OvlUARTCtrl.coff
10) Read COFF File OvlMyMassStorage.coff
11) Read COFF File OvlUARTOut.coff
12) Output image size is 13602 bytes. [Enter]
13) Checking that image is consistent with all module object files.
14) Inconsistency in module "OvlLowLevelInit"'s start address (421 is not 420)
15) Writing header file overlays.h
16) Writing symbol file overlays.abs
17) Warning: At this linker pass, the image is inconsistent. Address info is now updated for next pass.
18) The final image cannot be written at this linker pass.
19) Warning: A rebuild of the solution is required.
20) mkabs: I have 1 entries to process.
21) mkabs: writing ovlsymbols.o
22) Finished.

Look at line 14... every time a new build is started, the inconsistency changes to another overlay, and no eeprom image is created.
What I mean is that each time a build ends, I restarted building by tapping F7 and line 14 changes as follow (10 builds):

14) Inconsistency in module "OvlLowLevelInit"'s start address (421 is not 420)
14) Inconsistency in module "OvlUARTCtrl"'s start address (739 is not 738)
14) Inconsistency in module "OvlUARTCtrl"'s start address (738 is not 739)
14) Inconsistency in module "OvlLowLevelInit"'s start address (420 is not 421)
14) Inconsistency in module "OvlLowLevelInit"'s start address (421 is not 420)
14) Inconsistency in module "OvlUARTCtrl"'s start address (739 is not 738)
14) Inconsistency: LowLevelInit in SDPlayer is 1673, when it is actually linked to 1675
14) Inconsistency in module "OvlLowLevelInit"'s start address (420 is not 421)
14) Inconsistency in module "OvlLowLevelInit"'s start address (420 is not 421)
14) Inconsistency in module "OvlLowLevelInit"'s start address (420 is not 421)

"Clean solution" or "Rebuild solution" do not solve.
VSIDE v2.38

Please help.

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

Re: Windows 10 compatibility

Post by Henrik » Thu 2016-07-14 12:21

Hello!

Panu, who is the creator of the overlay tool, is currently out of office. Unfortunately this means that it may take some time to answer your question.

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

User avatar
Panu
VLSI Staff
Posts: 2489
Joined: Tue 2010-06-22 13:43

Re: Windows 10 compatibility

Post by Panu » Thu 2016-07-14 16:01

Hi!

Could you check the time stamps of intermediate files such as overlays.h, overlays.abs. Maybe the files don't get written. Maybe there's a problem with folder permissions. Have you recently copied the project to another folder? I've seen it happen that sometimes files continue to be updated in the old folder even when you're compiling in the new folder, possible due to some weird file system virtualization or something. I've rarely been able to duplicate that problem and it has gone away if I've renamed the old folder so that Windows can't find the old files anymore. Weird all in all.

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

stefanpoz
User
Posts: 3
Joined: Wed 2016-07-13 17:13

Re: Windows 10 compatibility

Post by stefanpoz » Fri 2016-07-15 18:23

Hi Panu,
- all the timestamps of the intermediate files change every new build.
- Overlays.h and overlays.abs, if manually deleted, are always recreated in the solution directory at build.
- Solution folder is always the same, and versioned controlled with Tortoise Subversion, so I don't need copies of it....but prudence is never enough so I scanned all my disks... no copies found.

Other unfortunate :( attempts I made:
- Uninstalling VSIDE from "C:\Program Files (x86)\VSIDE" and installing it to "C:\VSIDE" give same result.
- Recreating entire solution and projects, copying only .c, .h and .s., same result.
- Moved solution to PC with W7.... build... success....Moved againg to PC with W10....Build....arghhh!

Best regards,
Stefano

User avatar
Panu
VLSI Staff
Posts: 2489
Joined: Tue 2010-06-22 13:43

Re: Windows 10 compatibility

Post by Panu » Sat 2016-07-16 8:41

Hi!

Right, obviously it's a different kind of failure mechanism than I've seen before. Ok. I'm not at the office, but I might be able to try to reproduce the issue from where I am. Could you make a zip of your project and send it to me. Also please provide a link to the exact version of VSIDE you have installed. I can then try to see if I can get the bug to surface.

One question. After you've wasted the better part of an afternoon tapping F7, does the tool finally produce an executable? Does it work?

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

stefanpoz
User
Posts: 3
Joined: Wed 2016-07-13 17:13

Re: Windows 10 compatibility

Post by stefanpoz » Mon 2016-07-18 8:19

Hi!

VSIDE download link:
http://www.vlsi.fi/fileadmin/software/V ... 2_v238.exe

Solution sent.

About your question, the tool has never produced an executable.

-Stefano

User avatar
pasi
VLSI Staff
Posts: 1443
Joined: Thu 2010-07-15 16:04

Re: Windows 10 compatibility

Post by pasi » Tue 2016-07-26 12:05

Is this a VS1000 overlay project?

It could be because the compiler sometimes creates a slightly different result each time due to factors unknown. Instead of the two-step process needed by the old makeoverlaidimage, try replacing it with coff2allboot, which can perform the necessary relocations in one pass.

In post-static1000.bat and post-overlay1000.bat replace makeoverlaidimage with coff2allboot, keep the parameters the same
In post-last1000.bat replace "makeoverlaidimage" with "coff2allboot -i vs1000spi"
i.e. the line should read coff2allboot -i vs1000spi eeprom.img overlay_control

(You might be okay by just doing this to post-last1000.bat )
Visit https://www.facebook.com/VLSISolution VLSI Solution on Facebook

User avatar
Panu
VLSI Staff
Posts: 2489
Joined: Tue 2010-06-22 13:43

Re: Windows 10 compatibility

Post by Panu » Thu 2016-07-28 15:55

Hi!

I finally was able to fire up my only Win10 PC and for one thing, I can see something interesting when I build.
C:\Program Files\VSIDE\bin\make.exe: *** Warning: File `ovlsymbols.o' has modification time in the future (2016-07-27 14:46:20 > 2016-07-27 14:46:18)
Do you see such messages? There may be something peculiar going on with the version of GNU Make which we use.

And yes, building fails on Win10 also for me, and is successful in Win7.

I don't really yet use Win10 for anything real, I only have it on a computing stick, so it's a bit difficult for me to debug this at the moment.

[Edit] Seems the computing stick with the Win10 just died while I was debugging. :x Not sure how/when I can proceed..

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

jedm@vpitech.com
Senior User
Posts: 48
Joined: Wed 2016-11-02 22:50

Re: Windows 10 compatibility

Post by jedm@vpitech.com » Fri 2017-07-07 18:46

Windows 10 and Makefiles.
I'm using the Makefile's created by VSIDE with some minor modifications but have noticed some problems with Windows 10 installation.

GNU make doesn't seem to like having VSIDE in the default c:/Program Files (x86)/VSIDE In particular, it objects to the parentheses and does not seem amenable to any sort of reasonable fix. Installing VSIDE in a directory without parentheses seems to solve this problem.

The GNU make supplied (3.92) doesn't like the --eval option which is what I use to pass in the board parameters as in:
make -f Makefile_afinit --eval "BOARD=PROTO1"
which with a simple modification to Makefile_init allows me to use the makefile for different boards. I'm currently using the 64 bit version from EquationSolution http://www.Equation.com, perhaps there are others available (cygwin for example is 4.2.1).

User avatar
Panu
VLSI Staff
Posts: 2489
Joined: Tue 2010-06-22 13:43

Re: Windows 10 compatibility

Post by Panu » Fri 2017-07-07 21:48

Hi!

Ok, seems you answered the question yourself. VSIDE by itself is happy to install to the default directory suggested by Windows and usually runs fine from there. We've worked rather hard to make everything work with that abysmal directory name, with the parenthses and all. And yes, the problem you describe happens when there is another copy of Make installed in the machine, in the path, and it runs instead of the Make that comes with VSIDE. And the problem also occurs, for some reason, more often with non-English versions of Windows.

Personally I find the "Program Files (x86)" horrible because I often need to work from the command line. And thus I customarily install VSIDE to C:\VSIDE and solutions to C:\SOLUTIONS anyway.

Great that you've found the solution for yourself and thanks for reporting it here!

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

Post Reply