Powerswitch Problem

[Supario]

Hi,

Im trying to get the powerswitch demo working on an ATmega162. The circuit is almost identical to the one on the site except that its running at 5V instead of 3.3 V with a 2.2k, 4.7k resistor divider pulling up D-. The code compiled, uploaded etc and the lsusb command in linux showed the device with the correct product and vendor id numbers. However when I ran powerSwitch it gave the following error

Could not find USB device "PowerSwitch" with vid=0x16c0 pid=0x5dc

After a little poking around in the code I found out that the computer is receiving the correct vendor name (www.obdev.at) , but after that the product name doesnt get received. What should I do?

Thanks,
Supario

[christian]

Two questions:
(1) Do you limit the D+ and D- voltage with zener diodes? Some host controllers don't work with levels considerably above 3.3 V. [Even if you don't use those zeners, your host seems to tolerate the 5 V.]

(2) Do you run the command line utility as root? Linux has Unix permissions for various USB related special files. Ordinary users might not be able to read string descriptors.

[Supario]

Problem fixed. It wasnt anything to do with the hardware it was a compilation problem. The usbRxBuffer wasnt getting aligned properly in memory and was going to 0x800102 . I tried changing the section as suggested in the usbdrv.h header file, but that by itself didnt work either. The problem is that the ATmega162 unlike the smaller AVRs has an extended I/O space that extends up till 0x8000FF in memory and the data section can only start at 0x800100. For now I am just running the mega162 in mega161 compatibility mode where the I/O space ends at 0x80005F.

However, there are still a few things that are not clear
1. I compiled the code in winAVR instead of avr-gcc in linux without setting the alignment or using ATmega161 compatibility mode and it worked fine, how is that possible?
2. Is there any way of getting around the extended I/O problem thus enabling the AVR USB to be used on the other big ATmega controllers without having to use backward compatibility ?

[christian]

1. I compiled the code in winAVR instead of avr-gcc in linux without setting the alignment or using ATmega161 compatibility mode and it worked fine, how is that possible?

This is probably a slightly different version of gcc. I have not found a rule how memory addresses are assigned to variables. Looks pretty chaotic, at least with newer gcc versions.

2. Is there any way of getting around the extended I/O problem thus enabling the AVR USB to be used on the other big ATmega controllers without having to use backward compatibility ?

Yes, there is a way. usbRxBuf is in memory section USB_BUFFER_SECTION which can be defined in usbconfig.h. By default, this is defined to ".bss". Most versions of gcc put variables with explicitly assigned ".bss" section at the beginning of this section and thus avoid crossing the 256 byte boundary.

If this does not work for you, choose your own section for USB_BUFFER_SECTION and assign this section an explicit address during linking. I don't know the linker command line syntax well enough, but you should be able to find examples with google.

[Supario]

If this does not work for you, choose your own section for USB_BUFFER_SECTION and assign this section an explicit address during linking.

I tried doing this with an address 0x800060 for the buffer, but it didnt work. As far as I can understand, it failed because the address 0x60 clashed with one of the extended I/O addresses that are mapped into the same SRAM memory space and which end at 0x8000FF.

[christian]

If this memory region is already taken, you must choose a different one. The only requirement is that the buffer (which is 22 bytes long) does not cross a 256 byte page boundary.

I remember that I have once found a document with a web search which describes how to reserve a memory region for your own section. This was probably not AVR-specific.