fx2lib-devel — Mailing list for fx2lib development

Re: [Fx2lib-devel] bulkloop example crashing FX2?

[Aric M. <as...@pu...>]

The problem comes down to the fact that the FX2 only has 8KByte RAM, and 
the FX2LP(which you have) has 16KByte RAM.  So I've got it working as 
long as I tweek the settings in the Makefile and keep things small.

A bit of a noob question: How can I make use of the external RAM to 
overcome this shortage?  I'm kind of at a loss as to the command line 
options to use with SDCC in order to describe my hardware.  My board 
currently has 0x0000-0x1FFF mapped to internal RAM and 0x2000-0xFFFF 
mapped to external RAM.
If I have:
CC = sdcc -mmcs51 --code-size 0x1800 --xram-loc 0x2000 \
     -Wl"-b DSCR_AREA = 0x1800" \
     -Wl"-b INT2JT = 0x1A00"

Then everything works fine, but that gives me little space for code.  
How do I change this to put my code/data into the external RAM and 
execute it from there?

Many thanks,
ASM

Re: [Fx2lib-devel] Using FXLOAD with udev on SUSE

[Eric W. <er...@wi...>]

Eric Winsor wrote:
> Dennis Muhlestein wrote:
>   
>>> SUBSYSTEM==”usb”, ATTRS{idVendor}==”04b4”, ATTRS{idProduct}==”0082", 
>>> MODE="0666"
>>>
>>> Which lends be to believe the RUN command is not the issue.
>>>   
>>>
>>>     
>>>       
>> What does the kernel documentation say about udev rules format?  Perhaps 
>> there is a way to get a more verbose error message on exactly what the 
>> problem with your file is.
>>
>> -Dennis
>>
>>   
>>     
> I got it!  Notice above in the rule that the quotes are different in 
> MODE= from the previous quotes.  I got the original idea to use a udev 
> rule to call fxload from a blog found by googling fxload.  I copied and 
> pasted the rule from firefox in Windows XP to my running VMware SUSE.  
> The first quotes copied from the web browser are not the ASCII quote on 
> the keyboard.  Hence the rule was failing.  My later edits in VI are 
> ASCII quotes.  In an xtem and VI I can not tell the difference between 
> the quotes.  Only by seeing them in Thunderbird mail did I notice the 
> difference.  I fixed the quotes and the rule works fine.  Now to remove 
> the static reference to /proc/bus/usb/002/033 and put back in variable 
> references to the current usb device and all should be great.  I'll post 
> the full solution when done.
>
> Eric
>   
OK, here is a working udev rule for invoking fxload when a device is 
plugged in.

Rule:
SUBSYSTEM=="usb", ATTR{idVendor}=="04b4", ATTR{idProduct}=="0082", 
ACTION=="add", RUN+="/sbin/fxload -t fx2 -D $TEMPNODE -I 
/usr/share/RCU_02.hex"

The rule resides in the file /etc/udev/rules.d/10-evw.rules on by SUSE 
11 system.  The rule may have any name, but the rules.d directory is 
searched in sort order.  Hence I started the name with 10 to cause the 
rule to be invoked before the later default rules.

Initially I looked at /sys/bus/usb/devices then plugged my USB device in 
and looked again to see where my device connected.  My device was 
connected as 2-1 in the devices directory, so I issued udevinfo -a -p 
/sys/bus/usb/devices/2-1 to get the udev attributes that I could write 
my udev rule from.
The first three attribute matches in the rule come from the top of the 
udevinfo output.  Our device has just been added to the system, hence 
the ACTION=="add" attribute check.  Then the rule instructs udev to run 
fxload if the four attribute matches are true.  The $TEMPNODE variable 
references the new usb device.  This is cool because by using $TEMPNODE 
I do not need to have usbfs mounted as I do if I directly reference 
/proc/bus/usb/<bus number>/<device number>.  I was also having trouble 
dynamically determining the bus number and device number to reference in 
/proc/bus/usb.  These numbers will change depending on which usb port 
you plug into and how many time you plug and unplug the device. Device 
number increment every time a plug event occurs.

The device when plugged in will enumerate as VID, PID, then fxload will 
detach the device, program the device, and reattach / renumerate as new 
VID, new PID.  Hence the logical next rule in my udev rule file will be 
a rule matching the new VID, new PID and associate it to the device 
file(s) my host driver will interface through.

While developing the rule I used:
# udevadm control reload_rules
To reload the udev rule set between modifications to the rule file.
and
# udevadm test /sys/bus/usb/2-1 | head
To test the rule for errors.

Eric

[Fx2lib-devel] "lights" fix for CY3681

[Aric M. <as...@pu...>]

These are the addresses for the lights on the CY3681 board:

volatile xdata at 0x8000 BYTE D2ON;
volatile xdata at 0x8100 BYTE D2OFF;
volatile xdata at 0x9000 BYTE D3ON;
volatile xdata at 0x9100 BYTE D3OFF;
volatile xdata at 0xA000 BYTE D4ON;
volatile xdata at 0xA100 BYTE D4OFF;
volatile xdata at 0xB000 BYTE D5ON;
volatile xdata at 0xB100 BYTE D5OFF;

Re: [Fx2lib-devel] bulkloop example crashing FX2?

[Dennis M. <de...@ub...>]

Aric Marheine wrote:
> Dennis Muhlestein wrote:
>   
>> I just tested it out again on my CY3684/CY3674 board.  Is there a 
>> different chip on the Cy3681 board?
>>
>> If you have the serial console set up, you can see what is going on by 
>> following the printf statements.
>>
>> The example certainly won't work with EA=0 though because you have to 
>> have interrupts enabled to
>> handle the vendor commands.
>>
>> -Dennis
>>   
>>     
> Hi Dennis,
>
> The FX2 on this board is a CY7C68013-128AC, not sure what chip you have 
> on your boards.  I do indeed have SIO set up.  As mentioned earlier, as 
> soon as the interrupts are enabled, nothing more appears to happen.  I 
> can printf() all the way up to that point then nothing more.  I've tried 
> adding simple printfs() to each of the ISRs that are in the example to 
> see if one was being called continuously or something but none of them 
> do seem to be.
>   
I have the CYC68013A-128AXC.  You might want to check the Cypress site 
and see if there are any subtle differences.  There could for instance 
be a slight register name or location mismatch between different chip 
versions.  I know there are some differences between the FX and FX2 
chips but I don't know which model numbers fall under which category.

> My compiler setup seems ok as I can compile and test programs like 
> "lights" and my own app which does some port I/O.  Could it be that some 
> interrupt vector is being called which doesn't have an ISR in the 
> example?  I don't understand why it would work for you(and others, I 
> guess) but not me.  I think I'll go over all the interrupts and be sure 
> that no others are being enabled which shouldn't be.
>   
That will indeed cause problems if you have an interrupt firing but 
don't clear it (it'll go in a loop and pretty much nothing else will 
execute.)
printf is a bad thing to put in the interrupt routines though.  I prefer 
to test each one with a light instead.

If you narrow it down to something that causes your program to break, 
you could send a test case that I can check on my board.  It would be 
nice to
have the library be smart enough to work across more than my variant of 
the Cypress chip if that is the problem.

-Dennis

Re: [Fx2lib-devel] bulkloop example crashing FX2?

[Dennis M. <de...@ub...>]

Aric Marheine wrote:
> One odd thing I just noticed was that the behavior of the LEDs seems to 
> be inverted on my board.  dXon()/dXoff() do the opposite, yet they do 
> function just fine.
>   

Well, the board number you provided is indeed different than mine so 
that doesn't surprise me.  Interesting that the memory addresses Cypress 
used for the lights are still the same, even if they tied them to the 
different lights in a different order.

Does the i2c example work?

-Dennis

Re: [Fx2lib-devel] bulkloop example crashing FX2?

[Aric M. <as...@pu...>]

One odd thing I just noticed was that the behavior of the LEDs seems to 
be inverted on my board.  dXon()/dXoff() do the opposite, yet they do 
function just fine.

Aric Marheine wrote:
> Dennis Muhlestein wrote:
>   
>> I just tested it out again on my CY3684/CY3674 board.  Is there a 
>> different chip on the Cy3681 board?
>>
>> If you have the serial console set up, you can see what is going on by 
>> following the printf statements.
>>
>> The example certainly won't work with EA=0 though because you have to 
>> have interrupts enabled to
>> handle the vendor commands.
>>
>> -Dennis
>>   
>>     
> Hi Dennis,
>
> The FX2 on this board is a CY7C68013-128AC, not sure what chip you have 
> on your boards.  I do indeed have SIO set up.  As mentioned earlier, as 
> soon as the interrupts are enabled, nothing more appears to happen.  I 
> can printf() all the way up to that point then nothing more.  I've tried 
> adding simple printfs() to each of the ISRs that are in the example to 
> see if one was being called continuously or something but none of them 
> do seem to be.
>
> My compiler setup seems ok as I can compile and test programs like 
> "lights" and my own app which does some port I/O.  Could it be that some 
> interrupt vector is being called which doesn't have an ISR in the 
> example?  I don't understand why it would work for you(and others, I 
> guess) but not me.  I think I'll go over all the interrupts and be sure 
> that no others are being enabled which shouldn't be.
>
> Anyway, I appreciate your help and any further suggestions you may have!
>
> Regards,
> ASM
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
>
>
>   

Re: [Fx2lib-devel] Using FXLOAD with udev on SUSE

[Eric W. <er...@wi...>]

Dennis Muhlestein wrote:
>> SUBSYSTEM==”usb”, ATTRS{idVendor}==”04b4”, ATTRS{idProduct}==”0082", 
>> MODE="0666"
>>
>> Which lends be to believe the RUN command is not the issue.
>>   
>>
>>     
> What does the kernel documentation say about udev rules format?  Perhaps 
> there is a way to get a more verbose error message on exactly what the 
> problem with your file is.
>
> -Dennis
>
>   
I got it!  Notice above in the rule that the quotes are different in 
MODE= from the previous quotes.  I got the original idea to use a udev 
rule to call fxload from a blog found by googling fxload.  I copied and 
pasted the rule from firefox in Windows XP to my running VMware SUSE.  
The first quotes copied from the web browser are not the ASCII quote on 
the keyboard.  Hence the rule was failing.  My later edits in VI are 
ASCII quotes.  In an xtem and VI I can not tell the difference between 
the quotes.  Only by seeing them in Thunderbird mail did I notice the 
difference.  I fixed the quotes and the rule works fine.  Now to remove 
the static reference to /proc/bus/usb/002/033 and put back in variable 
references to the current usb device and all should be great.  I'll post 
the full solution when done.

Eric

> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
>   

Re: [Fx2lib-devel] bulkloop example crashing FX2?

[Aric M. <as...@pu...>]

Dennis Muhlestein wrote:
> I just tested it out again on my CY3684/CY3674 board.  Is there a 
> different chip on the Cy3681 board?
>
> If you have the serial console set up, you can see what is going on by 
> following the printf statements.
>
> The example certainly won't work with EA=0 though because you have to 
> have interrupts enabled to
> handle the vendor commands.
>
> -Dennis
>   
Hi Dennis,

The FX2 on this board is a CY7C68013-128AC, not sure what chip you have 
on your boards.  I do indeed have SIO set up.  As mentioned earlier, as 
soon as the interrupts are enabled, nothing more appears to happen.  I 
can printf() all the way up to that point then nothing more.  I've tried 
adding simple printfs() to each of the ISRs that are in the example to 
see if one was being called continuously or something but none of them 
do seem to be.

My compiler setup seems ok as I can compile and test programs like 
"lights" and my own app which does some port I/O.  Could it be that some 
interrupt vector is being called which doesn't have an ISR in the 
example?  I don't understand why it would work for you(and others, I 
guess) but not me.  I think I'll go over all the interrupts and be sure 
that no others are being enabled which shouldn't be.

Anyway, I appreciate your help and any further suggestions you may have!

Regards,
ASM

Re: [Fx2lib-devel] bulkloop example crashing FX2?

[Dennis M. <de...@ub...>]

Aric Marheine wrote:
> Hi everyone,
>
> I'm trying out the "bulkloop" example in fx2lib and it seems that the 
> FX2 is dying(in some manner) when EA is set to 1 to enable interrupts.  
> Has anyone tried this example recently?  I'm using a CY3681 demo board, 
> fwiw...  No additional hw attached(atm).  Device becomes unresponsive 
> once EA is set to 1.
>
> BTW, thanks a lot for making this lib! :)
>   

I just tested it out again on my CY3684/CY3674 board.  Is there a 
different chip on the Cy3681 board?

If you have the serial console set up, you can see what is going on by 
following the printf statements.

The example certainly won't work with EA=0 though because you have to 
have interrupts enabled to
handle the vendor commands.

-Dennis

Re: [Fx2lib-devel] Using FXLOAD with udev on SUSE

[Dennis M. <de...@ub...>]

>
> SUBSYSTEM==”usb”, ATTRS{idVendor}==”04b4”, ATTRS{idProduct}==”0082", 
> MODE="0666"
>
> Which lends be to believe the RUN command is not the issue.
>   
>
What does the kernel documentation say about udev rules format?  Perhaps 
there is a way to get a more verbose error message on exactly what the 
problem with your file is.

-Dennis

[Fx2lib-devel] bulkloop example crashing FX2?

[Aric M. <as...@pu...>]

Hi everyone,

I'm trying out the "bulkloop" example in fx2lib and it seems that the 
FX2 is dying(in some manner) when EA is set to 1 to enable interrupts.  
Has anyone tried this example recently?  I'm using a CY3681 demo board, 
fwiw...  No additional hw attached(atm).  Device becomes unresponsive 
once EA is set to 1.

BTW, thanks a lot for making this lib! :)

Regards,
ASM

Re: [Fx2lib-devel] Using FXLOAD with udev on SUSE

[Eric W. <er...@wi...>]

Dennis Muhlestein wrote:
> Eric Winsor wrote:
>   
>> Hi,
>>
>> I'm trying to write a udev rule but I get the following error when I 
>> test it:
>> linux-b1xe:~ # udevadm test /sys/bus/usb/2-1
>>
>> parse_file: reading '/etc/udev/rules.d/10-evw.rules' as rules file
>> add_to_rules: invalid rule '/etc/udev/rules.d/10-evw.rules:4'
>>
>> The fist three lines of 10-evw.rules are comments, the fourth line is my 
>> rule and is (in one line):
>>
>> RUN+="/sbin/fxload/ -t fx2 -D /proc/bus/usb/002/033 -I 
>> /usr/share/RCU_02.hex"
>> DRIVER==”usb”, RUN+="/sbin/fxload/ -t fx2 -D /proc/bus/usb/002/033 -I 
>> /usr/share/RCU_02.hex"
>>   
>>     
> I don't use the RUN command in my udev rule.  I just use ATTRS and MODE 
> to allow all users to use the device. 
> SUBSYSTEM=="usb", ATTRS{idVendor}=="<my vendor id>", MODE="0666"
> So Assuming your RUN command is not the problem, perhaps you need 
> SUBSYSTEM instead of DRIVER.
>
> As for the RUN command, is it /sbin/fxload/ with a trailing slash?
>
> I'm working in Fedora though, I don't know if the UDEV rules have 
> differences from platform to platform.
>
> -Dennis
>   
I hadn't noticed the trailing slash, thanks, that would have been a 
problem later, but not the source of my problem currently.  Here is my 
rule at the moment:

SUBSYSTEM==”usb”, ATTRS{idVendor}==”04b4”, ATTRS{idProduct}==”0082", 
RUN+="/sbin/fxload -t fx2 -D /proc/bus/usb/002/004 -I /usr/share/RCU_02.hex"

Changing to SUBSYSTEM did not have an effect.  I also tried the ATTRS as 
ATTR to match the udevinfo query.  I'm trying to get fxload to load my 
firmware to my development board.  Hence I want udev to catch the VID 
and PID then run fxload.  I have read a few complaints through google 
searches that the SUSE udev act different, but no one explains how it is 
different.  The SUSE documentation points to the kernel.org udev 
documentation, so things should not be different.

For grins I also tried:

SUBSYSTEM==”usb”, ATTRS{idVendor}==”04b4”, ATTRS{idProduct}==”0082", 
MODE="0666"

Which lends be to believe the RUN command is not the issue.

Eric
>> Querying the device to get my attributes gives me:
>>
>> linux-b1xe:~ # udevinfo -a -p /sys/bus/usb/devices/2-1
>>
>> Udevinfo starts with the device specified by the devpath and then
>> walks up the chain of parent devices. It prints for every device
>> found, all possible attributes in the udev rules key format.
>> A rule to match, can be composed by the attributes of the device
>> and the attributes from one single parent device.
>>
>> looking at device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2/2-1':
>> KERNEL=="2-1"
>> SUBSYSTEM=="usb"
>> DRIVER=="usb"
>> ATTR{dev}=="189:129"
>> ATTR{configuration}==""
>> ATTR{bNumInterfaces}==" 1"
>> ATTR{bConfigurationValue}=="1"
>> ATTR{bmAttributes}=="80"
>> ATTR{bMaxPower}=="100mA"
>> ATTR{urbnum}=="6"
>> ATTR{idVendor}=="04b4"
>> ATTR{idProduct}=="0082"
>> ATTR{bcdDevice}=="0000"
>> ATTR{bDeviceClass}=="ff"
>> ATTR{bDeviceSubClass}=="ff"
>> ATTR{bDeviceProtocol}=="ff"
>> ATTR{bNumConfigurations}=="1"
>> ATTR{bMaxPacketSize0}=="64"
>> ATTR{speed}=="480"
>> ATTR{busnum}=="2"
>> ATTR{devnum}=="2"
>> ATTR{version}==" 2.00"
>> ATTR{maxchild}=="0"
>> ATTR{quirks}=="0x0"
>> ATTR{authorized}=="1"
>>
>> looking at parent device 
>> '/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2':
>> KERNELS=="usb2"
>> SUBSYSTEMS=="usb"
>> DRIVERS=="usb"
>> ATTRS{dev}=="189:128"
>> ATTRS{configuration}==""
>> ATTRS{bNumInterfaces}==" 1"
>> ATTRS{bConfigurationValue}=="1"
>> ATTRS{bmAttributes}=="e0"
>> ATTRS{bMaxPower}==" 0mA"
>> ATTRS{urbnum}=="49"
>> ATTRS{idVendor}=="1d6b"
>> ATTRS{idProduct}=="0002"
>> ATTRS{bcdDevice}=="0206"
>> ATTRS{bDeviceClass}=="09"
>> ATTRS{bDeviceSubClass}=="00"
>> ATTRS{bDeviceProtocol}=="01"
>> ATTRS{bNumConfigurations}=="1"
>> ATTRS{bMaxPacketSize0}=="64"
>> ATTRS{speed}=="480"
>> ATTRS{busnum}=="2"
>> ATTRS{devnum}=="1"
>> ATTRS{version}==" 2.00"
>> ATTRS{maxchild}=="6"
>> ATTRS{quirks}=="0x0"
>> ATTRS{authorized}=="1"
>> ATTRS{manufacturer}=="Linux 2.6.25.18-0.2-pae ehci_hcd"
>> ATTRS{product}=="EHCI Host Controller"
>> ATTRS{serial}=="0000:02:02.0"
>> ATTRS{authorized_default}=="1"
>>
>> looking at parent device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0':
>> KERNELS=="0000:02:02.0"
>> SUBSYSTEMS=="pci"
>> DRIVERS=="ehci_hcd"
>> ATTRS{vendor}=="0x15ad"
>> ATTRS{device}=="0x0770"
>> ATTRS{subsystem_vendor}=="0x15ad"
>> ATTRS{subsystem_device}=="0x0770"
>> ATTRS{class}=="0x0c0320"
>> ATTRS{irq}=="16"
>> ATTRS{local_cpus}=="ffffffff,ffffffff,ffffffff,ffffffff"
>> ATTRS{modalias}=="pci:v000015ADd00000770sv000015ADsd00000770bc0Csc03i20"
>> ATTRS{enable}=="1"
>> ATTRS{broken_parity_status}=="0"
>> ATTRS{msi_bus}==""
>>
>> looking at parent device '/devices/pci0000:00/0000:00:11.0':
>> KERNELS=="0000:00:11.0"
>> SUBSYSTEMS=="pci"
>> DRIVERS==""
>> ATTRS{vendor}=="0x15ad"
>> ATTRS{device}=="0x0790"
>> ATTRS{subsystem_vendor}=="0x0000"
>> ATTRS{subsystem_device}=="0x0000"
>> ATTRS{class}=="0x060401"
>> ATTRS{irq}=="0"
>> ATTRS{local_cpus}=="ffffffff,ffffffff,ffffffff,ffffffff"
>> ATTRS{modalias}=="pci:v000015ADd00000790sv00000000sd00000000bc06sc04i01"
>> ATTRS{enable}=="1"
>> ATTRS{broken_parity_status}=="0"
>> ATTRS{msi_bus}=="1"
>>
>> looking at parent device '/devices/pci0000:00':
>> KERNELS=="pci0000:00"
>> SUBSYSTEMS==""
>> DRIVERS==""
>>
>>
>> Can anyone see what I'm doing wrong in my rule or missing that I may 
>> need to do elsewhere?
>>
>> Thanks,
>>
>> Eric Winsor
>>
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Fx2lib-devel mailing list
>> Fx2...@li...
>> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
>>   
>>     
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
>   

Re: [Fx2lib-devel] Using FXLOAD with udev on SUSE

[Dennis M. <de...@ub...>]

Eric Winsor wrote:
> Hi,
>
> I'm trying to write a udev rule but I get the following error when I 
> test it:
> linux-b1xe:~ # udevadm test /sys/bus/usb/2-1
>
> parse_file: reading '/etc/udev/rules.d/10-evw.rules' as rules file
> add_to_rules: invalid rule '/etc/udev/rules.d/10-evw.rules:4'
>
> The fist three lines of 10-evw.rules are comments, the fourth line is my 
> rule and is (in one line):
>
> RUN+="/sbin/fxload/ -t fx2 -D /proc/bus/usb/002/033 -I 
> /usr/share/RCU_02.hex"
> DRIVER==”usb”, RUN+="/sbin/fxload/ -t fx2 -D /proc/bus/usb/002/033 -I 
> /usr/share/RCU_02.hex"
>   
I don't use the RUN command in my udev rule.  I just use ATTRS and MODE 
to allow all users to use the device. 
SUBSYSTEM=="usb", ATTRS{idVendor}=="<my vendor id>", MODE="0666"
So Assuming your RUN command is not the problem, perhaps you need 
SUBSYSTEM instead of DRIVER.

As for the RUN command, is it /sbin/fxload/ with a trailing slash?

I'm working in Fedora though, I don't know if the UDEV rules have 
differences from platform to platform.

-Dennis

> Querying the device to get my attributes gives me:
>
> linux-b1xe:~ # udevinfo -a -p /sys/bus/usb/devices/2-1
>
> Udevinfo starts with the device specified by the devpath and then
> walks up the chain of parent devices. It prints for every device
> found, all possible attributes in the udev rules key format.
> A rule to match, can be composed by the attributes of the device
> and the attributes from one single parent device.
>
> looking at device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2/2-1':
> KERNEL=="2-1"
> SUBSYSTEM=="usb"
> DRIVER=="usb"
> ATTR{dev}=="189:129"
> ATTR{configuration}==""
> ATTR{bNumInterfaces}==" 1"
> ATTR{bConfigurationValue}=="1"
> ATTR{bmAttributes}=="80"
> ATTR{bMaxPower}=="100mA"
> ATTR{urbnum}=="6"
> ATTR{idVendor}=="04b4"
> ATTR{idProduct}=="0082"
> ATTR{bcdDevice}=="0000"
> ATTR{bDeviceClass}=="ff"
> ATTR{bDeviceSubClass}=="ff"
> ATTR{bDeviceProtocol}=="ff"
> ATTR{bNumConfigurations}=="1"
> ATTR{bMaxPacketSize0}=="64"
> ATTR{speed}=="480"
> ATTR{busnum}=="2"
> ATTR{devnum}=="2"
> ATTR{version}==" 2.00"
> ATTR{maxchild}=="0"
> ATTR{quirks}=="0x0"
> ATTR{authorized}=="1"
>
> looking at parent device 
> '/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2':
> KERNELS=="usb2"
> SUBSYSTEMS=="usb"
> DRIVERS=="usb"
> ATTRS{dev}=="189:128"
> ATTRS{configuration}==""
> ATTRS{bNumInterfaces}==" 1"
> ATTRS{bConfigurationValue}=="1"
> ATTRS{bmAttributes}=="e0"
> ATTRS{bMaxPower}==" 0mA"
> ATTRS{urbnum}=="49"
> ATTRS{idVendor}=="1d6b"
> ATTRS{idProduct}=="0002"
> ATTRS{bcdDevice}=="0206"
> ATTRS{bDeviceClass}=="09"
> ATTRS{bDeviceSubClass}=="00"
> ATTRS{bDeviceProtocol}=="01"
> ATTRS{bNumConfigurations}=="1"
> ATTRS{bMaxPacketSize0}=="64"
> ATTRS{speed}=="480"
> ATTRS{busnum}=="2"
> ATTRS{devnum}=="1"
> ATTRS{version}==" 2.00"
> ATTRS{maxchild}=="6"
> ATTRS{quirks}=="0x0"
> ATTRS{authorized}=="1"
> ATTRS{manufacturer}=="Linux 2.6.25.18-0.2-pae ehci_hcd"
> ATTRS{product}=="EHCI Host Controller"
> ATTRS{serial}=="0000:02:02.0"
> ATTRS{authorized_default}=="1"
>
> looking at parent device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0':
> KERNELS=="0000:02:02.0"
> SUBSYSTEMS=="pci"
> DRIVERS=="ehci_hcd"
> ATTRS{vendor}=="0x15ad"
> ATTRS{device}=="0x0770"
> ATTRS{subsystem_vendor}=="0x15ad"
> ATTRS{subsystem_device}=="0x0770"
> ATTRS{class}=="0x0c0320"
> ATTRS{irq}=="16"
> ATTRS{local_cpus}=="ffffffff,ffffffff,ffffffff,ffffffff"
> ATTRS{modalias}=="pci:v000015ADd00000770sv000015ADsd00000770bc0Csc03i20"
> ATTRS{enable}=="1"
> ATTRS{broken_parity_status}=="0"
> ATTRS{msi_bus}==""
>
> looking at parent device '/devices/pci0000:00/0000:00:11.0':
> KERNELS=="0000:00:11.0"
> SUBSYSTEMS=="pci"
> DRIVERS==""
> ATTRS{vendor}=="0x15ad"
> ATTRS{device}=="0x0790"
> ATTRS{subsystem_vendor}=="0x0000"
> ATTRS{subsystem_device}=="0x0000"
> ATTRS{class}=="0x060401"
> ATTRS{irq}=="0"
> ATTRS{local_cpus}=="ffffffff,ffffffff,ffffffff,ffffffff"
> ATTRS{modalias}=="pci:v000015ADd00000790sv00000000sd00000000bc06sc04i01"
> ATTRS{enable}=="1"
> ATTRS{broken_parity_status}=="0"
> ATTRS{msi_bus}=="1"
>
> looking at parent device '/devices/pci0000:00':
> KERNELS=="pci0000:00"
> SUBSYSTEMS==""
> DRIVERS==""
>
>
> Can anyone see what I'm doing wrong in my rule or missing that I may 
> need to do elsewhere?
>
> Thanks,
>
> Eric Winsor
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
>   

[Fx2lib-devel] Using FXLOAD with udev on SUSE

[Eric W. <er...@wi...>]

Hi,

I'm trying to write a udev rule but I get the following error when I 
test it:
linux-b1xe:~ # udevadm test /sys/bus/usb/2-1

parse_file: reading '/etc/udev/rules.d/10-evw.rules' as rules file
add_to_rules: invalid rule '/etc/udev/rules.d/10-evw.rules:4'

The fist three lines of 10-evw.rules are comments, the fourth line is my 
rule and is (in one line):

RUN+="/sbin/fxload/ -t fx2 -D /proc/bus/usb/002/033 -I 
/usr/share/RCU_02.hex"
DRIVER==”usb”, RUN+="/sbin/fxload/ -t fx2 -D /proc/bus/usb/002/033 -I 
/usr/share/RCU_02.hex"

Querying the device to get my attributes gives me:

linux-b1xe:~ # udevinfo -a -p /sys/bus/usb/devices/2-1

Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2/2-1':
KERNEL=="2-1"
SUBSYSTEM=="usb"
DRIVER=="usb"
ATTR{dev}=="189:129"
ATTR{configuration}==""
ATTR{bNumInterfaces}==" 1"
ATTR{bConfigurationValue}=="1"
ATTR{bmAttributes}=="80"
ATTR{bMaxPower}=="100mA"
ATTR{urbnum}=="6"
ATTR{idVendor}=="04b4"
ATTR{idProduct}=="0082"
ATTR{bcdDevice}=="0000"
ATTR{bDeviceClass}=="ff"
ATTR{bDeviceSubClass}=="ff"
ATTR{bDeviceProtocol}=="ff"
ATTR{bNumConfigurations}=="1"
ATTR{bMaxPacketSize0}=="64"
ATTR{speed}=="480"
ATTR{busnum}=="2"
ATTR{devnum}=="2"
ATTR{version}==" 2.00"
ATTR{maxchild}=="0"
ATTR{quirks}=="0x0"
ATTR{authorized}=="1"

looking at parent device 
'/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2':
KERNELS=="usb2"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{dev}=="189:128"
ATTRS{configuration}==""
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bmAttributes}=="e0"
ATTRS{bMaxPower}==" 0mA"
ATTRS{urbnum}=="49"
ATTRS{idVendor}=="1d6b"
ATTRS{idProduct}=="0002"
ATTRS{bcdDevice}=="0206"
ATTRS{bDeviceClass}=="09"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="01"
ATTRS{bNumConfigurations}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{speed}=="480"
ATTRS{busnum}=="2"
ATTRS{devnum}=="1"
ATTRS{version}==" 2.00"
ATTRS{maxchild}=="6"
ATTRS{quirks}=="0x0"
ATTRS{authorized}=="1"
ATTRS{manufacturer}=="Linux 2.6.25.18-0.2-pae ehci_hcd"
ATTRS{product}=="EHCI Host Controller"
ATTRS{serial}=="0000:02:02.0"
ATTRS{authorized_default}=="1"

looking at parent device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0':
KERNELS=="0000:02:02.0"
SUBSYSTEMS=="pci"
DRIVERS=="ehci_hcd"
ATTRS{vendor}=="0x15ad"
ATTRS{device}=="0x0770"
ATTRS{subsystem_vendor}=="0x15ad"
ATTRS{subsystem_device}=="0x0770"
ATTRS{class}=="0x0c0320"
ATTRS{irq}=="16"
ATTRS{local_cpus}=="ffffffff,ffffffff,ffffffff,ffffffff"
ATTRS{modalias}=="pci:v000015ADd00000770sv000015ADsd00000770bc0Csc03i20"
ATTRS{enable}=="1"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""

looking at parent device '/devices/pci0000:00/0000:00:11.0':
KERNELS=="0000:00:11.0"
SUBSYSTEMS=="pci"
DRIVERS==""
ATTRS{vendor}=="0x15ad"
ATTRS{device}=="0x0790"
ATTRS{subsystem_vendor}=="0x0000"
ATTRS{subsystem_device}=="0x0000"
ATTRS{class}=="0x060401"
ATTRS{irq}=="0"
ATTRS{local_cpus}=="ffffffff,ffffffff,ffffffff,ffffffff"
ATTRS{modalias}=="pci:v000015ADd00000790sv00000000sd00000000bc06sc04i01"
ATTRS{enable}=="1"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}=="1"

looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""


Can anyone see what I'm doing wrong in my rule or missing that I may 
need to do elsewhere?

Thanks,

Eric Winsor

Re: [Fx2lib-devel] FYI copy of sourceforge news item.

[Gerry R. <ge...@ro...>]

wooohooo, this looks like even _more_ fun to come.

I've been tied up badly with 'real work' for the last few days, have not 
been able to take any time and play with this stuff.  I'm hoping to get 
back to it in a day or two.



Dennis Muhlestein wrote:
> I've uploaded documentation and a source download for fx2lib.  Below is 
> the copy of the sourceforge announcement.
>
> The fx2lib sources are stable enough to build complete firmware 
> implementations for the cypress fx/fx2 variants of the 8051 chipset.  
>
> The current release includes library functions for:
> * delay functions
> * endpoint functions
> * register definitions
> * type definitions
> * macros for common tasks
> * GPIF functions
> * i2c functions
> * serial IO
> * USB jump tables
> * vendor commands and setup data.
>
> Library documentation is located at: http://fx2lib.sourceforge.net/docs/
>
> Sources can be downloaded from the project download page: 
> https://sourceforge.net/project/showfiles.php?group_id=247216
>
> Development on fx2lib occurs in a git repository at: 
> http://github.com/mulicheng/fx2lib/
>
>
> -Dennis
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
>   

[Fx2lib-devel] FYI copy of sourceforge news item.

[Dennis M. <de...@ub...>]

I've uploaded documentation and a source download for fx2lib.  Below is 
the copy of the sourceforge announcement.

The fx2lib sources are stable enough to build complete firmware 
implementations for the cypress fx/fx2 variants of the 8051 chipset.  

The current release includes library functions for:
* delay functions
* endpoint functions
* register definitions
* type definitions
* macros for common tasks
* GPIF functions
* i2c functions
* serial IO
* USB jump tables
* vendor commands and setup data.

Library documentation is located at: http://fx2lib.sourceforge.net/docs/

Sources can be downloaded from the project download page: 
https://sourceforge.net/project/showfiles.php?group_id=247216

Development on fx2lib occurs in a git repository at: 
http://github.com/mulicheng/fx2lib/


-Dennis

Re: [Fx2lib-devel] First Success with fx2lib :)

[Dennis M. <de...@ub...>]

Gerry Rozema wrote:
> Ok, got the first real success with this stuff.
>
> Slightly modified reset.c and I've successfully reprogrammed the vid/pid 
> in one of my c0 load cameras.
>
>   
>> I'm not sure why you got c3 at any time.
>>   
>>     
> I'm starting to question this device, had the c2 eprom reading correctly 
> once.  Now it consistently reads c3 after plugging in.
>
> I was confident it's an  fx2 because the samples from cycfx2prog work on 
> it.  Im starting to wonder if it's a different variation on the fx chipsets.
>
> Will poke at some registers tomorrow when I get a chance, verify chipids 
> etc.
>
>   
You probably have the older fx chip there.  fx2lib could still work with 
it but you'd have to double check most of the logic in the functions to 
make sure register values addresses etc aren't different.

-Dennis

[Fx2lib-devel] First Success with fx2lib :)

[Gerry R. <ge...@ro...>]

Ok, got the first real success with this stuff.

Slightly modified reset.c and I've successfully reprogrammed the vid/pid 
in one of my c0 load cameras.

> I'm not sure why you got c3 at any time.
>   
I'm starting to question this device, had the c2 eprom reading correctly 
once.  Now it consistently reads c3 after plugging in.

I was confident it's an  fx2 because the samples from cycfx2prog work on 
it.  Im starting to wonder if it's a different variation on the fx chipsets.

Will poke at some registers tomorrow when I get a chance, verify chipids 
etc.

[Fx2lib-devel] GPIF conversion script

[Dennis M. <de...@ub...>]

I just pushed a script that converts the gpif designer output to a state 
usable by sdcc and the fx2lib library functions.

fx2lib/utils/gpif2dat

usage:
 gpif2dat <gpif designer exported c> <save file name>

example:
  gpif2dat gpif.c gpif_dat.c

Create a rel file from the data file:
 sdcc -c gpif_dat.c
Then, in your firmware, you can make reference to the variables:
 extern const char WaveData[];
 etc.
And use the gpif functions from fx2lib
gpif_init(WaveData,InitData);

And then compile your firmware
 sdcc firmware.c gpif_dat.rel


I haven't yet added a gpif example to fx2lib yet because I haven't 
thought of a good example to add.  The ez-usb development board doesn't 
have a device connected to the gpif and everyone elses boards have 
extremely custom gpif waveforms.

Hope this makes things more convenient though.  I use these commands 
within a makefile so that I don't have to do anything manually after I 
export the gpif code from the designer.

Just a side note:  the gpif designer works very well under Wine on Linux.

-Dennis

Re: [Fx2lib-devel] eeprom reset program

[Gerry R. <ge...@ro...>]

> I'm not sure why you got c3 at any time.
>   
I was hacking and slashing to get things going, I suspect some timing 
issues.  Was using a combination of old and new stuff.

Just starting now on re-doing it all, but this time linking to the lib 
instead of hacking a few cut and pastes.

Kind of having fun here this morning, turns out just about everything in 
our astronomy gear is an fx2 + some sort of ccd/cmos sensor.  The 3 
based on mtm9001 + fx2 came with brain dead drivers that only allow 
access to 8 bits of the a/d data, but the sensor will do 10.  I know on 
at least 2 of them, all 10 bits are indeed hooked up, so, I'm expecting 
I can get full 10 bit data out of them.  That makes a huge difference 
when we are doing long exposures on very dim things.

Then much to my surprise, another one I have is an fx2 + sony ccd with 
16 bit a/d.  This one has always been a beast, because it has no drivers 
that are a 'standard' of any type, and only works with the software that 
came with it.  That wouldn't be to bad, cept, the software that came 
with it doesn't run very well, a prime example of .net driven bloatware 
thats so full of eye candy, they forgot to focus in on the basic function.

I can see that over the next few weeks, I'm going to spend a fair amount 
of time with datasheets, and poking these things till they work the way 
_I_ want them to work....

Re: [Fx2lib-devel] eeprom reset program

[Dennis M. <de...@ub...>]

Gerry Rozema wrote:
> Ok, this did the trick.  I fixed my git installation first, so I could 
> check out the whole lib, instead of copy/paste from the viewer online.  
> Built it all, seemed to build ok, then I wrote up a quick little thingy 
> to read the eprom instead of write it.  Two of my devices it read back 
> fine, and I found exactly what I expected, a C0 format, and to my 
> surprise, only 8 bytes there.  The third one surprised me, it's got a C2 
> format and appears to have some firmware embedded into a larger eprom.  
> All of these are in sealed packages which will entail breaking the 
> plastic to open up and look at the parts on board.  I am _hoping_ I wont 
> have to resort to that, because one of them will definitely not go back 
> together if I do that.
>   
c2 is valid too.  It is the code for embedded firmware like you said:

c0 = just boot up with a default vendor_id/product_id and default usb 
descriptors for the chip but the firmware doesn't do anything.
c2= load the firmware from the eeprom.

> Just another 'point of interest', the third one did give me a bit of 
> trouble initially, kept reading C3 back from the first byte in the 
> eeprom, and that's not valid.  Then for giggles, I commented out the one 
> line that sets up cpu clock, unplugged and replugged the device so that 
> it comes up 'stock out of the box', and voila, now when I put it into 
> reset, load my own little bit (using cycfx2prog for now), take it out of 
> reset, let it run the program that dumps eprom contents into ram, reset 
> again, then dump dram, there it was, a properly formatted C2 header.  It 
> wont take me very long to poke at all the registers and find out what 
> setup the on board firmware is putting in place.
>   
I'm not sure why you got c3 at any time.
> I think I'm away to the races at this point.  Next step, gonna write 
> something up that dumps the entire eprom out of all of them, then store 
> that away for safe keeping, and _then_ start reprogramming eproms.
>
>   
This is exactly what I first did.  I have a program that can dump eeprom 
contents from an endpoint.  It dynamically reads the eeprom as it's 
dumping to know who much to read.  In the TRM for the ez-usb, you can 
see the iic from of the c2 data and you just need to read the length 
field and then read that many bytes in a loop until you read the entire 
iic file.  There end block stop condition is in there too.

-Dennis

Re: [Fx2lib-devel] eeprom reset program

[Gerry R. <ge...@ro...>]

Ok, this did the trick.  I fixed my git installation first, so I could 
check out the whole lib, instead of copy/paste from the viewer online.  
Built it all, seemed to build ok, then I wrote up a quick little thingy 
to read the eprom instead of write it.  Two of my devices it read back 
fine, and I found exactly what I expected, a C0 format, and to my 
surprise, only 8 bytes there.  The third one surprised me, it's got a C2 
format and appears to have some firmware embedded into a larger eprom.  
All of these are in sealed packages which will entail breaking the 
plastic to open up and look at the parts on board.  I am _hoping_ I wont 
have to resort to that, because one of them will definitely not go back 
together if I do that.

Just another 'point of interest', the third one did give me a bit of 
trouble initially, kept reading C3 back from the first byte in the 
eeprom, and that's not valid.  Then for giggles, I commented out the one 
line that sets up cpu clock, unplugged and replugged the device so that 
it comes up 'stock out of the box', and voila, now when I put it into 
reset, load my own little bit (using cycfx2prog for now), take it out of 
reset, let it run the program that dumps eprom contents into ram, reset 
again, then dump dram, there it was, a properly formatted C2 header.  It 
wont take me very long to poke at all the registers and find out what 
setup the on board firmware is putting in place.

I think I'm away to the races at this point.  Next step, gonna write 
something up that dumps the entire eprom out of all of them, then store 
that away for safe keeping, and _then_ start reprogramming eproms.



Dennis Muhlestein wrote:
> I added a reset program to the examples in the fx2lib repository.  This 
> is the program I used to reset the fx2 back to it's default state if I 
> happened to bork the eeprom data.  The eeprom/read/write routines are in 
> the i2c header file by the way.
>
> -Dennis
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
>   

Re: [Fx2lib-devel] eeprom reset program

[Gerry R. <ge...@ro...>]

Great stuff.  I wont be able to look at it for a while, the 'boss' is 
informing me that it's coming up on dinner time, and it's 'her night to 
cook', which probably means I'm headed off to the little greek 
restaurant down the road :)

I'll definitely take a look either later tonite, or sometime tomorrow.

Your bit of stuff has really saved me a bunch of 'early learning' curve 
time, i'll see what I can do to add my bits to it, when I've got 
something worth adding.



Dennis Muhlestein wrote:
> I added a reset program to the examples in the fx2lib repository.  This 
> is the program I used to reset the fx2 back to it's default state if I 
> happened to bork the eeprom data.  The eeprom/read/write routines are in 
> the i2c header file by the way.
>
>
>   

[Fx2lib-devel] eeprom reset program

[Dennis M. <de...@ub...>]

I added a reset program to the examples in the fx2lib repository.  This 
is the program I used to reset the fx2 back to it's default state if I 
happened to bork the eeprom data.  The eeprom/read/write routines are in 
the i2c header file by the way.

-Dennis

Re: [Fx2lib-devel] new, just found this list

[Gerry R. <ge...@ro...>]

> 8 bit prom address=0x50
> 16 bit prom address = 0x51
>
> There is a register that will tell you which type of prom it detected at 
> boot too.
>
> use the eeprom_read function.  you can send the bytes straight to a 
> print function if you  have a serial port (probably not). 
> I usually pipe the data across an endpoint for devices with no serial 
> console.
>
>   

wooohooo, you just saved me a ton of effort.,  Thank you very much.

I'll keep you posted on how it goes, right now the real world of work is 
getting in my way, and I've got to set this down and actually go do 
something that pays the bills for the next few hours.

This is the issue sometimes when you dive off the deep end, and jump 
right in, none of the stuff I've read so far told me what the address of 
the proms were, so, I was flying blind.  I have found docs on the 
address of my sensor.

ohhhhh, this is gonna be a fun project, I can tell already.