cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

Anonymous
Not applicable

Once in a while (not sure what causes it) when I execute the build/download script for my project I get a fatal toolchain error:

This application has requested the Runtime to terminate it in an unusual way.

Please contact the application's support team for more information.

Cannot create temporary file in C:\Windows\: Permission denied

The bad thing is that once this happens, the toolchain is broken *forever*.  Even rebooting the machine does not fix the error.  The only solution I have found when this happens is to reinstall the SDK !!

There is plenty of disk space on the computer and I'm fairly certain its an internal corruption of some kind in the SDK, because reinstalling the SDK (and thus recreating the Make Target) fixes the problem without making any other changes.  As you can imagine this is very disruptive to a development.

WICED SDK 3.3.1


Roger

0 Likes
Reply
1 Solution
New Contributor II

Solved !

Your 43xxx_Wi-Fi\make.exe, makefiles or ARM GCC toolchain are broken because the TMP environment variable is unset when gcc is called, then it tries to create the intermediate temporary assembler file in c:\windows directory (it should not !).

Usually, this access is caught by UAC and redirected to the VirtualStore directory.

But, on some systems (like mine), this redirection doesn't work and gcc got a permission denied.

Quick fix:

Add the following line in 43xxx_Wi-Fi\tools\makefiles\wiced_toolchain_common.mk AFTER ifeq ($(HOST_OS),Win32):

export TMP=YOUR_TMP_DIRECTORY

(Obviously, change YOUR_TMP_DIRECTORY)

Now, gcc never tries to write to c:\WINDOWS

View solution in original post

9 Replies
Anonymous
Not applicable

A previous post said that I didn't have my TEMP / TMP variable set up correctly. But that variable is alive and well and there are files in that directory that were created around the time that the IDE quit working.

0 Likes
Reply
Moderator
Moderator

Adding the Wi-Fi support team.

seyhangangivik86

0 Likes
Reply
Employee

Roger, we have noticed this error, we believe this occurs when you by mistake have moved the folders in the project structure of the SDK.

As you have mentioned reinstalling SDK fixes it.

Also you would notice couple of batch files getting generated in the same location of make file.

Let us know if you still see this issue.

0 Likes
Reply
Anonymous
Not applicable

It happened again today. This time I ran ProcMon in the background and captured all of the activity leading up to the problem.  (BTW I have not moved any directories as suggested.  I am, however, installing the SDK in a directory of my own creation when I install, C:/Broadcom, rather than the suggested directory under my local user name).

I would like to include a CSV output from procmon which shows that at some point during compilation the ARM compiler tries to go create a file named C:\Windows\ccCTEISj.s which is denied.  Shortly after that it crashes.  That string "ccCTEISj" does not occur anywhere in any file in my SDK directory nor in my registry.  I would include the entire CSV file which is 27K but can't figure out how to load it into this reply.  Here is the one line from that file that is the smoking gun:

Time of DayProcess NamePIDOperationPath
Result
Detail
51:06.1  arm-none-eabi-gcc.exe6896IRP_MJ_CREATEC:\Windows\ccCTEISj.sNAME NOT FOUND"Desired Access: Read Attributes, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a"
0 Likes
Reply
Anonymous
Not applicable

Hello, I have the same problem.

In makefiles I have seen something strange, the paths for variables are :

$COMMON_TOOLS_PATH is [./tools/common/Win32/]

$OUTPUT_DIR is [build/name-of-build]

Does this have something to do with this error? Why doesn't the OUTPUT_DIR start with ./ ?

Also I have no problems when I run WICED IDE in administrator mode.

0 Likes
Reply
Employee

Could you guys provide details of your system and operating system. We would like to reproduce this .

0 Likes
Reply
New Contributor

Hi vikr

I've installed from scratch Wiced Studio 6.2 using an administrative account  on a folder accesible to all users on Windows 10.

Every thing works as expected on this account, but when I switch to an user account,  I also can execute the IDE but compilations fails showing the same problem as described by Rdavis with the arm-none-eabi-gcc.exe compiler.

It doesn't matter the value assigned to the environment variables tmp and temp, compiler always try to create a temporaly folder under C:\windows and I got something like this.

MAKEFILE MAKECMDGOALS=snip.scan-CYW943907AEVAL1F download run OTA2_SUPPORT is disabled

Building Bootloader waf.bootloader-NoOS-NoNS-CYW943907AEVAL1F-P103-SoC.43909

Building Tiny Bootloader waf.tiny_bootloader-NoOS-NoNS-CYW943907AEVAL1F-P103-SoC.43909

Cannot create temporary file in C:\WINDOWS\: Permission denied

Is there any workaround to run Wiced on a windows user account?

Issue is very easy to reproduce just switching users.

0 Likes
Reply
New Contributor II

Today, I have the same problem on a new computer running Windows 7 64 bits.

WICED Studio 6.4 has been installed on two others computers (running the same OS) without any problem but, on the third one, compilation fails with the same error (gcc tries to write the intermediate assembler file in c:\windows\).

In all cases, WICED has been installed in a dedicated directory on D:\.

EDIT:

On a working installation, gcc also tries to write to c:\windows\ but got a REPARSE error, then tries %LOCALAPPDATA%\VirtualStore\Windows and succeeds.

On a wrong installation, gcc got an ACCESS_DENIED error.

So, it is an UAC virtual redirection issue, I will check that.

0 Likes
Reply
New Contributor II

Solved !

Your 43xxx_Wi-Fi\make.exe, makefiles or ARM GCC toolchain are broken because the TMP environment variable is unset when gcc is called, then it tries to create the intermediate temporary assembler file in c:\windows directory (it should not !).

Usually, this access is caught by UAC and redirected to the VirtualStore directory.

But, on some systems (like mine), this redirection doesn't work and gcc got a permission denied.

Quick fix:

Add the following line in 43xxx_Wi-Fi\tools\makefiles\wiced_toolchain_common.mk AFTER ifeq ($(HOST_OS),Win32):

export TMP=YOUR_TMP_DIRECTORY

(Obviously, change YOUR_TMP_DIRECTORY)

Now, gcc never tries to write to c:\WINDOWS

View solution in original post