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.
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.
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 Day Process Name PID Operation Path Result Detail 51:06.1 arm-none-eabi-gcc.exe 6896 IRP_MJ_CREATE C:\Windows\ccCTEISj.s NAME 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"
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.
Could you guys provide details of your system and operating system. We would like to reproduce this .
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.
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:\.
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.
1 of 1 people found this helpful
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.
Add the following line in 43xxx_Wi-Fi\tools\makefiles\wiced_toolchain_common.mk AFTER ifeq ($(HOST_OS),Win32):
(Obviously, change YOUR_TMP_DIRECTORY)
Now, gcc never tries to write to c:\WINDOWS