Implementation error in ISE for a Virtex-5 board - licensing

I'm using a Xilinx Virtex-5 version XC5VLX110T in ISE project navigator 14.6 to test a simple code but it always give implementation design error:
ERROR:Security:12 - No 'xc5vlx110t' feature version 2013.06 was
available (-15),
ERROR:Map:258 - A problem was encountered attempting
to get the license for this architecture.
this is it's Design proprieties
The code is:
module compare(clk ,x,y
);
input x,clk;
output reg y;
always #(posedge clk)
begin
y= x+1'b1;
end
endmodule

It depends ...
First, have a look into the Xilinx license manager to see what's supported and what's not.
Some development boards are sold with a "node locked license". If so, your package should contain a serial for the registration process on Xilinx.com. Then you can download your personal, board specific license and register it in ISE.
Otherwise you'll need a normal/full license, which is quite expensive. For development purposes, you can change the device for ex. to XC5VLX50T-1FFG1136 (Virtex-5 LX50T from ML505 board) this one should supported by the webpack license. All implementation steps will work, but programming, because it's the false size and pinout.

Related

UIOP does not recognize local-nicknames keyword

I'm attempting to make a Lisp package with uiop/package:define-package. I'm using SBCL, and have confirmed that package-local nicknaming ought to be supported:
* *features*
(:QUICKLISP :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX
:NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :X86-64 :GENCGC :64-BIT :ANSI-CL
:COMMON-LISP :ELF :IEEE-FLOATING-POINT :LINUX :LITTLE-ENDIAN
:PACKAGE-LOCAL-NICKNAMES :SB-CORE-COMPRESSION :SB-LDB :SB-PACKAGE-LOCKS
:SB-THREAD :SB-UNICODE :SBCL :UNIX)
* (uiop:featurep :package-local-nicknames)
T
Nevertheless, when I try to define a package that has local nicknames, it doesn't work:
(uiop/package:define-package #:foo
(:use #:cl)
(:local-nicknames (#:b #:binparse)))
debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {1001878103}>:
unrecognized define-package keyword :LOCAL-NICKNAMES
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(UIOP/PACKAGE:PARSE-DEFINE-PACKAGE-FORM #:FOO ((:USE #:CL) (:LOCAL-NICKNAMES (#:B #:BINPARSE))))
source: (ERROR "unrecognized define-package keyword ~S" KW)
0] 0
(binparse being another package I've made, which worked fine, but which did not happen to use local nicknaming).
What I've found of the uiop/package source seems to indicate that this shouldn't happen? Going by that, it should either work, or have a specific error message indicating the non-supported-ness of local nicknames (if somehow uiop:featurep is inaccurate or changing), but it shouldn't give a generic unknown-keyword error. At this point I'm not sure what I could be getting wrong.
The version of asdf that's included in releases of sbcl is based on asdf version 3.3.1 (November 2017), except bundled into only two (larger) lisp files (one for asdf and one for uiop) rather than breaking them up by purpose as is done in official releases of asdf. asdf added #+sbcl support for package-local nicknames in 3.3.3.2 (August 2019), and switched to the more general #+package-local-nicknames in 3.3.4.1 (April 2020) (the latest release version is 3.3.4, though, so that wouldn't be in yet anyway). So it's "just" a delay in pulling from upstream. Following the instructions on upgrading ASDF did the trick – extract the latest release tarball into ~/common-lisp/asdf and run (load (compile-file #P"~/common-lisp/asdf/build/asdf.lisp")) once, and future shells will use the updated version.

Upper filter device driver for a mouse

I've just started diving into driver related stuffs as what I want to do (cf. here) seems undoable with a "regular" application. For now, I'm just trying to install a Kernel Mode Driver (KMDF) as an upper filter for the mouse I want to modify the behaviour. The source files are not empty as they are filled in according to the Visual Studio KMDF template. The only modification I did so far in those source files was adding those two lines of code in the CreateDevice routine :
WdfFdoInitSetFilter(DeviceInit);
WdfDeviceInitSetDeviceType(DeviceInit, FILE_DEVICE_MOUSE);
to specify that the driver is a mouse filter driver.
However, I'm having trouble to install it as I would like on my virtual machine. Here is the INF file (don't pay too much attention to the comments, I just added them to better understand what's going on as it's the first time I'm confronted to such a file):
;
; EGMC_filter.inf
;
[Version]
Signature="$WINDOWS NT$" ;Operating system for which the INF file is valid
Class=Mouse ; The class is mouse
ClassGuid={4d36e96f-e325-11ce-bfc1-08002be10318} ; Mouse class GUID
Provider=%ManufacturerName% ; is specified in the Strings section (bottom of this file)
CatalogFile=EGMC_filter.cat ; for signature
DriverVer= ; TODO: set DriverVer in stampinf property pages
; The DestinationDirs section specifies the target destination directory for all copy, delete and/or rename operations
; on files referenced by name elsewhere in the INF file
[DestinationDirs]
DefaultDestDir = 12 ; directory is \Drivers on WinNT platforms
EGMC_filter_Device_CoInstaller_CopyFiles = 11 ; Directory is \system32 on WinNt platforms
[SourceDisksNames]
1 = %DiskName%,,,""
[SourceDisksFiles]
EGMC_filter.sys = 1,,
WdfCoInstaller$KMDFCOINSTALLERVERSION$.dll=1 ; make sure the number matches with SourceDisksNames
;*****************************************
; Install Section
;*****************************************
[Manufacturer] ; This section is used to list all devices handled by the driver
%ManufacturerName%=Standard,NT$ARCH$ ;stands for architecture. Is modified depending on x64 or x86
[Standard.NT$ARCH$] ; This is a model section
%EGMC_filter.DeviceDesc%=EGMC_filter_Device, USB\VID_093A&PID_2510; Specifying the Hardware ID for which to install the driver. No revision nb specified
[EGMC_filter_Device.NT] ; This is a DDInstall section
CopyFiles=Drivers_Dir ; CopyFiles directive that specify a copyfiles section (Drivers_Dir)
AddReg=EGMC_filter.AddReg
[EGMC_filter.AddReg]
HKR,,"UpperFilters",0x0010008,"EGMC_filter" ; REG_MULTI_SZ value
[Drivers_Dir] ; This is a CopyFile section.
EGMC_filter.sys ; All the files in this section are copied to the specified directory in the DestinationDirs section.
;-------------- Service installation
[EGMC_filter_Device.NT.Services]
AddService = EGMC_filter,%SPSVCINST_ASSOCSERVICE%, EGMC_filter_Service_Inst ; create a service installation section
; -------------- EGMC_filter driver install sections
[EGMC_filter_Service_Inst]
DisplayName = %EGMC_filter.SVCDESC%
ServiceType = 1 ; SERVICE_KERNEL_DRIVER
StartType = 3 ; SERVICE_DEMAND_START
ErrorControl = 1 ; SERVICE_ERROR_NORMAL
ServiceBinary = %12%\EGMC_filter.sys ; create a value in the registry with the fully qualified path of the driver's file
;
;--- EGMC_filter_Device Coinstaller installation ------
;
[EGMC_filter_Device.NT.CoInstallers]
AddReg=EGMC_filter_Device_CoInstaller_AddReg ;Add a registry section
CopyFiles=EGMC_filter_Device_CoInstaller_CopyFiles
[EGMC_filter_Device_CoInstaller_AddReg]
HKR,,CoInstallers32,0x00010000, "WdfCoInstaller$KMDFCOINSTALLERVERSION$.dll,WdfCoInstaller"
[EGMC_filter_Device_CoInstaller_CopyFiles]
WdfCoInstaller$KMDFCOINSTALLERVERSION$.dll
[EGMC_filter_Device.NT.Wdf]
KmdfService = EGMC_filter, EGMC_filter_wdfsect
[EGMC_filter_wdfsect]
KmdfLibraryVersion = $KMDFVERSION$
[Strings]
SPSVCINST_ASSOCSERVICE= 0x00000002
ManufacturerName="EGMC" ; My manufacturer name
ClassName="Mouse" ; ClassName of the device
DiskName = "EGMC_filter Installation Disk" ; the disk name. DON'T KNOW WHERE IT COMES FROM !!!
EGMC_filter.DeviceDesc = "EGMC Filter Device"
EGMC_filter.SVCDESC = "EGMC_filter Service"
I'm trying to install my driver in a virtual machine running Windows 10. The VM is configured to support USB 2.0 and I've added a USB device filter in order for the VM to detect my particular mouse (otherwise, the VM couldn't distinguish the different mice connected).
First I tried deploying it via Visual Studio using the "Install/Reinstall and Verify" option in the project properties (configuration properties -> Driver Install -> Deployment). Note that remove previous driver versions before deployment is selected.
It didn't work and I got the following error messages :
[17:32:01:625]: ERROR: Task "Default Driver Package Installation Task" failed to complete successfully. Look at the logs in the driver test group explorer for more details on the failure.
[17:32:02:348]: Driver Post Install Actions
[17:32:02:348]: Removing any existing files from test execution folder.
[17:32:02:375]: Copying required files for "Driver Post Install Actions".
[17:32:02:934]: [Driver Post Install Actions] Command Line:
$KitRoot$\Testing\Runtimes\TAEF\te.exe "%SystemDrive%\DriverTest\Run\DriverTestTasks.dll" /select:"#Name='DriverTestTasks::_DriverPostInstall'" /rebootStateFile:%SystemDrive%\DriverTest\Run\DriverTestReboot.xml /enableWttLogging /wttDeviceString:$LogFile:file="%SystemDrive%\DriverTest\Run\Driver_Post_Install_Actions_00011.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*" /runas:Elevated
[17:32:05:387]: Result Summary: Total=1, Passed=1, Failed=0, Blocked=0, Warned=0, Skipped=0
[17:32:05:388]: Task "Driver Post Install Actions" completed successfully
Driver Deployment Task Failed: Default Driver Package Installation Task
It may sound stupid but I was unable to locate the logs in the driver test group explorer to get more info about the error.
Secondly, I tried using the "Hardware ID Driver" option instead of the "Install/Reinstall and Verify" one with the following Hardware ID "USB\VID_093A&PID_2510" (same as the one specified in the INF). It worked this time. However, I'm not sure to understand exactly why. So now that you got a better picture of what I'm doing, here are my questions :
1) I did understand that the SourceDisksNames section is used to specify the name of a disk (CD-rom, DVD) containing the .sys file of the driver. However, I don't understand how to install a driver from such a disk practically. Imagine I buy a specific hardware and it comes with a CD with the corresponding driver files. Once the CD is in the player, what should I do ? Should I run the INF file in order to install it ? From what I remember the only time I had to install a driver from a disk it was a .exe file.
2) What if I want to release my driver package via Internet ? What's the point of this section then ?
3) By default when I created the project, VS filled the disk name with "EGMC_filter Installation Disk". What does it correspond to ? Should I modify it ?
4) I don't understand how the deployment process works. I guess that VS first transfers the driver package (containing the .INF, .cat and .sys) to the VM and then launches the .INF file in the VM. Is that right ? If yes, what does the DiskName correspond to in the VM ? Does VS create some kind of ISO containing the package ? Where can I find where the package is stored in the VM ?
5) Does the deployment process differ when using the "Hardware ID Driver Update" and the "Install/Reinstall […]" options ?
6) Any idea why I can't install my driver using the "Install/Reinstall and Verify" option ? What's wrong with the INF file ? Has it something to do with the Disk name ?
7) Despite having read this page, I'm confused about why I can deploy my driver with the "Hardware ID" option considering that I didn't respect the form Root\xxx (I saw this page afterwards). However, it seems clear that for what I want to do, I must install my driver using the other option. Any idea why it still seems to work (at least partially) ?
8) After the "incorrect" installation is completed, a "EGMC Filter Device" entry is added to the Device Manager under Mice and other pointer devices even when the mouse of interest is unplugged. Why is this ? When I plug it, another entry appears.
9) When my driver is installed, the mouse doesn't work anymore (it doesn't even light up !). However, as the upper filter doesn't do anything for now, the mouse should work normally. The only explanation I've found so far is that the driver is installed as a function driver and not as a filter one. Could it be the case ? In the registry of the VM, I'm unable to find the UpperFilters keys with the "EGMC_filter" value in the section "Ordinateur\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4d36e96f-e325-11ce-bfc1-08002be10318}". The only one I found is : "UpperFilters : VboxMouse mouclass". It comforts me in my idea that the driver is installed as a function one… Could the VM interferes with my driver ?
10) The driver details of the mouse of interest (left) and the regular one (right) also confuse me as the mouhid is missing from the former.
11) Lastly, what's the point of specifying in the driver code that it's a filter driver ? What does it change concretely ?
I know it's a long post and that I'm asking quite specific questions but I hope you won't mind and hopefully some experts right there will be able to answer them.
I'm looking forward to your replies.
Guillaume.

How to set GUIDED_NOGPS mode with Arducopter on Dronekit?

How do I command Arducopter to enter guided_nogps mode? I am planning to operate in a gps denied environment, and although other posts indicate this is possible with guided-nogps, I cannot see how to set that mode. Using Dronekit (python) vehicle.mode = VehicleMode("Guided_NoGPS") returns an error indicating there is no such mode.
Mavlink also refuses to acknowledge the mode.
My setup is a Pixhawk running Arducopter with a Raspberry Pi companion. Firmware is v3.5 dev, and v3.4 on the DroneKit-SITL (I compiled my own v3.4 binary for this).
Everything else is working great (e.g. controlling via set_attitude_target thanks to this post How to set copters Attitude via DroneKit -- SET_ATTITUDE_TARGET not working ) - I just need to be able to go indoors!
Also - I did notice in this post prior to the release of Arducopter v3.4 Controlling movement without GPS that an optical flow sensor might be required. Did that requirement come to pass?
Thanks again!
All advice welcome.
Thanks Squilter for your help. I created a function to change the flightmode (20):
def set_mode(flightmode):
# create the MAV_CMD_DO_SET_MODE command
msg = vehicle.message_factory.command_long_encode(
0, 0, # target system, target component
mavutil.mavlink.MAV_CMD_DO_SET_MODE, #command
0, #confirmation
flightmode,
0, 0, 0, 0, 0, 0 )
# send command to vehicle
vehicle.send_mavlink(msg)
The message is correctly received but was not successful (result 3 returned). One thing I wasn't sure about was parameter 2, which the spec indicates is platform specific. I put 0 as I wasn't sure what to do with it for Arducopter.
Again, any suggestions welcome and many thanks!
Try setting the mode to 20. This is the internal representation of the mode. It looks like dronekit-python does not know this yet.
Optical flow is required for normal guided mode, not guided_nogps. However, guided_nogps does not allow sending velocity or position requests, only angles.
I know that this question is a little old but I have found the answer. Update your installs of MAVProxy and PyMAVLink.
pip install -U pymavlink mavproxy
DroneKit will automatically install older versions of them without the new modes available. You want PyMAVLink >= 2.2.4 and MAVProxy >= 1.6.1.

How to add a board file to the Linux Kernel and where to find it on "make menu config"?

I need to add some board-specific code to a Linux kernel which I am building.
(I know I should be using device-tree already, but the driver I'm inspired by doesn't and I'm already learning a dozen new things before breakfast. Adding device-tree will also add another set of changes to debug. Once I have my platform-driver/drivers working using a board file, I will convert them to device tree.)
I have a file called arch/arm/myboard/myboard.c.
Where do I find existing board files in make menuconfig? (Such as http://lxr.free-electrons.com/source/arch/arm/mach-imx/mach-mx31ads.c?v=4.4 ?)
How do I make my board appear here also.
Take a look at the Makefile in the same directory. For mach-mx31ads.c, it has,
# i.MX31 based machines
obj-$(CONFIG_MACH_MX31ADS) += mach-mx31ads.o
The Kconfig has a corresponding entry,
config MACH_MX31ADS
bool "Support MX31ADS platforms"
default y
select IMX_HAVE_PLATFORM_IMX_I2C
select IMX_HAVE_PLATFORM_IMX_SSI
select IMX_HAVE_PLATFORM_IMX_UART
select SOC_IMX31
help
Include support for MX31ADS platform. This includes specific
configurations for the board and its peripherals.
Adding these will give your board a Kconfig menu item and build the file. The only other missing piece is a machine type. You need to add this to arm/tools/mach-type which is processed by the kernel makefile, using the gen-mach-types script, to create a generated/mach-type.h. You use this in your board file to create a static machine description (put in a special section).
MACHINE_START(MX31ADS, "Freescale MX31ADS")
/* Maintainer: Freescale Semiconductor, Inc. */
.atag_offset = 0x100,
.map_io = mx31ads_map_io,
.init_early = imx31_init_early,
.init_irq = mx31ads_init_irq,
.init_time = mx31ads_timer_init,
.init_machine = mx31ads_init,
.restart = mxc_restart,
MACHINE_END
The machine_desc structure is found in arch.h. You don't need to add all the elements as they won't be called if not present. The kernel init looks a the machine ATAG and iterates through the sections to match the machine that the boot loader passes in. Locating the machine_desc is done in assembler very early in the linux boot.

How to recover from infinite reboot loops in NodeMCU?

My NodeMCU program has gone in to infinite reboot loop.
My code is functionally working but any action I try to do, e.g. file.remove("init.lua") or even just =node.heap(), it panics and reboots saying: PANIC: unprotected error in call to Lua API (not enough memory).
Because of this, I'm not able to change any code or delete init.lua to stop automatic code execution.
How do I recover?
I tried re-flashing another version of NodeMCU, but it started emitting garbage in serial port.
Then, I recalled that NodeMCU had two extra files: blank.bin and esp_init_data_default.bin.
I flashed them at 0x7E000 and 0x7C000 respectively.
They are also available as INTERNAL://BLANK and INTERNAL://DEFAULT in the NodeMCU flasher.
This booted the new NodeMCU firmware, all my files were gone and I'm out of infinite reboot loop.
Flash the following files:
0x00000.bin to 0x00000
0x10000.bin to 0x10000
And, the address for esp_init_data_default.bin depends on the size of your module's flash.
0x7c000 for 512 kB, modules like ESP-01, -03, -07 etc.
0xfc000 for 1 MB, modules like ESP8285, PSF-A85
0x1fc000 for 2 MB
0x3fc000 for 4 MB, modules like ESP-12E, NodeMCU devkit 1.0, WeMos D1 mini
Then, after flashing those binaries format its file system (run "file.format()" using ESPlorer) before flashing any other binaries.
Downloads Link
I've just finished working through a similar problem. In my case it was end-user error that caused a need to forcibly wipe init.lua, but I think both problems could be solved similarly. (For completeness, my problem was putting a far-too-short dsleep() call in init.lua, leaving the board resetting itself immediately upon starting init.lua.)
I tried flashing new NodeMCU firmware, writing blank.bin and esp_init_data_default.bin to 0x7E000 and 0x7C000, and also writing 0x00000.bin to 0x00000 and 0x10000.bin to 0x10000. None of these things helped in my case.
My hardware is an Adafruit Huzzah ESP8266 breakout (ESP-12), with 4MB of flash.
What worked for me was:
Download the NONOS SDK from Espressif (I used version 1.5.2 from http://bbs.espressif.com/viewtopic.php?f=46&t=1702).
Unzip it to get at boot_v1.2.bin, user1.1024.new.2.bin, blank.bin, and esp_init_data_default.bin (under bin/ and bin/at/).
Flash the following files to the specified memory locations:
boot_v1.2.bin to 0x00000
user1.1024.new.2.bin to 0x010000
esp_init_data_default.bin to 0xfc000
blank.bin to 0x7e000
Note about flashing:
I used esptool.py 1.2.1.
Because of the nature of my problem, I was only able to write changes to the flash when in programming mode (i.e. after booting with GPIO0 held down to GND).
I found that I needed to reset the board between each step (else invocations of esptool.py after the first would fail).
Erased the flash. esptool.py --port <your/port> erase_flash
Then I was able to write a new firmware. I used a stock nodeMCU 0.9.5 just to isolate variables, but I strongly suspect any firmware would work at this point.
The only think that worked for me was python flash tool esptool in ubuntu, windows flashtool never deleted init.lua and reboot loop.
Commands (ubuntu):
git clone https://github.com/themadinventor/esptool.git
cd esptool
python esptool.py -h
ls -l /dev/tty*
nodemcu_latest.bin can be downloaded from github or anywhere.
sudo python esptool.py -p /dev/ttyUSB0 --baud 460800 write_flash --flash_size=8m 0 nodemcu_latest.bin

Resources