LUFA Build Issue

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

I'm hoping one of your will recognize the error of my ways and provide a nudge in the right direction.

I am trying to build one of the example HID LUFA USB projects and load it into a USBKEY board.

I am using Studio 6.1. I installed the LUFA extension. I selected the "LOWLEVEL KEYBOARD1" example and made this into a "solution" or "project" (not sure of the Atmel-specific jargon here).

I "Clean Solution" under the BUILD Tab in Studio 6.1, I "Build Solution", I Rebuild Soultion, and all runs fine with no errors and I get the "Succeed" message at the end of each operation. In the DEBUG folder new HEX & EEP files are created.

I use my JAGICE-MKII programmer to load the hex file into the USBKEY board. That works fine. HOWEVER, when I try to load the EEP file I get an error indicating there is not enough data in the EEP file, and the operation is curtailed. The EEP file is 1K in length. I'm not even sure of this EEP file needs to be loaded for this example.

But the BIG PROBLEM is that when I plug the USBKEY board into my PC USB port, nothing seems to be happening. The green LED on the USBKEY board is lit, but I don't see any activity on the board's other LEDs (should there be?).

The PC activity LED seems to do a little something when the USBKEY is first connected to the USB port, but I'm not so sure that it happens everytime I connect or disconnect from the USB.

My assumption is that the example is configured for the USBKEY board because of something I read in the LUFA documentaion or on Dean's website. But when I look in the boardtypes.h file I see this:
#define BOARD_ BOARD_NONE

Which seems to indicate the project is "delivered" in an unconfigured state. I changed the "BOARD_NONE" to "BOARD_USBKEY", rebuilt, recleaed, re-everythinged, but No Dice!

Any help would be greatly appreciated. I'm trying to incoporate USB HID functionality into a larger project. I had good luck with the ATXMEGA-A3BU demo project, but I wanted to give the LUFA approach a fair shot too, since it seems the LUFA documentation is more prolific and it has a good reputation among my Fellow Freaks.

Forgot to mention, that the USBKEY board is brand new, and it did work perfectly with the pre-programmed demo it came with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I'm not even sure of this EEP file needs to be loaded for this example.

Post it here as an attachment but I'm pretty sure LUFA projects don't generally use EEPROM. The chances are its an Intel hex file with no actual data records.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson,

Here's what's in the file when I open it with WordPad:

:00000001FF

Which I'd venture is some sort of a "null" Hex File.

I guess my question regarding the EEP file is really two parts:

A. Does this Keyboard HID example require specific values to be present in the AT90USB1287's EEPROM? (I'd expect this would be explicitly stated somewhere in the source files, but I don't see any such statement in what I would consider the "obvious" places. E.g. the header comments of main.c / keyboard.c )

B. If so, why is the build not producing a legitmate EEP file? If not, why is the build producing this file? (It does indeed get recreated each time I run the build process.)

Thanks for your help. Do you have experience with the USBKEY + LUFA platform?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The build usually creates a .eep I think but there's only something valid in it and a point in trying to use it if the project actually used "EEMEM" (grep for it).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The default for all the generated projects is that no board is set (BOARD=NONE, change via the ASF Wizard as shown in the LUFA Getting Started page that showed up when you installed the extension) with a 16MHz system clock.

As the USBKEY has an 8MHz crystal you need to change F_USB from 16000000 to 8000000 in the project toolchain options (Project Options->Toolchain->AVR/GNU C Compiler->Symbols).

Try Help->LUFA Help->Getting Started for a visual guide on how to get set up.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Dean, I was able to get it to work, but still not exactly sure how I got there.

For future readers here are a few of the stumbling blocks I encountered.

A. Did not realize the examples are not configured as to board type (i.e. USBKEY, etc). Something I read on the FourWallCubicle web site led me to believe these examples defaulted to the USBKEY board. In fact, that's why I purchased the USBKEY reference design kit.

B. Did not realize the LEDs on the USBKEY PCB light in a particular color sequence to indicate progress points. (In my first mis-built projects, no LEDs lit, but I had no idea if they were supposed to.)

C. Did not realize clock speed options had to be specifically entered. I would have thought this would be auto-configured according to platform. I.e. USBKEY comes standard with the 8 MHz crystal.

D. Had trouble finding the F_USB symbol. I used the Search in Files facility, but a "# define" did not show up in the result list as I was expecting from past experience.

My next question refers to this DOxygen utility which is mentioned throughout the LUFA commentary. What role does this utility play in the projects? I have already downloaded the precompiled documentation. Will installing DOxygen on my PC provide me any further benefit as I move forward with my own project which will incorporate the LUFA routines? E.g. Will DOxygen ADD any comments to the source files I already have in the LUFA example projects?

Thanks again for your speedy help.

My next step is to understand the structure and execution of the HID Keyboard example as a prelude to integrating it into my overall project. Or, to determine whether I have to integrate MY project into the LUFA example!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Doxygen creates the documentation pages (you have already looked at) from the Doxygen-tagged texts in the source files. Unless you augment the documentation (by adding/changing stuff in the Doxygen-tagged text blocks in the sources) you will have no benefits from installing Doxygen.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

My next question refers to this DOxygen utility which is mentioned throughout the LUFA commentary. What role does this utility play in the projects? I have already downloaded the precompiled documentation. Will installing DOxygen on my PC provide me any further benefit as I move forward with my own project which will incorporate the LUFA routines? E.g. Will DOxygen ADD any comments to the source files I already have in the LUFA example projects?

Doxygen is a two edged sword. The advantage is that the excellent documentation you see on fourwalledcubicle is always up to date and reflects the current issue. For Dean it also means that when he edits the code (mainly .h files) the documentation and the code it documents are in the same place so it's just natural to edit one to reflect the other. However the disadvantage is that for the casual reader of the .h files it can make them more difficult to use with all the additional "noise".

You could install Doxygen and it'd let you build your own local copy of the documentation but you won't magically get access to any more than you see online so I don't see much point.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

However the disadvantage is that for the casual reader of the .h files it can make them more difficult to use with all the additional "noise".

A decent editor should be able to "fold" the Doxygen blocks.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

A decent editor

AS6.1? ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Notepad++ :wink:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

A. Did not realize the examples are not configured as to board type (i.e. USBKEY, etc). Something I read on the FourWallCubicle web site led me to believe these examples defaulted to the USBKEY board. In fact, that's why I purchased the USBKEY reference design kit.

The standalone LUFA package is configured in this way, but the demos generated from Atmel Studio are not - they are BOARD=NONE with 16MHz system clock. This are the most compatible defaults as BOARD=NONE disabled all the board specific hardware drivers (gimping the usefulness of the demos but allowing them to compile and enumerate out of the box) while most boards use the faster 16MHz crystal.

Quote:
B. Did not realize the LEDs on the USBKEY PCB light in a particular color sequence to indicate progress points. (In my first mis-built projects, no LEDs lit, but I had no idea if they were supposed to.)

It's not documented in the demo documentation, but the code should have comments about the event handlers and LED code.

Quote:
C. Did not realize clock speed options had to be specifically entered. I would have thought this would be auto-configured according to platform. I.e. USBKEY comes standard with the 8 MHz crystal.

Unfortunately that isn't always possible; some boards can come with either speed and some people make their own variants of well known boards with different crystals. The Getting Started page that auto-opens when the extension installs explains how to change the value.

Quote:
D. Had trouble finding the F_USB symbol. I used the Search in Files facility, but a "# define" did not show up in the result list as I was expecting from past experience.

Again, I hope people would see/read the Getting Started page that explains all this. Since not everyone does it appears my approach isn't optimal and I need to re-think on how to make it easier and more intuitive to the user.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean,

Thanks for your responses. Actually, I did read the Getting Started page, but still somehow got tangled up in the menu intricacies of Studio 6.1. I have used AVR Studio in several of its previous versions, but mostly for device programming. So a lot of the project set-up/configuration stuff was new ground for me. Plus, my Windows XP development machine is very slow with Studio 6.1, causing me to think Studio hung in a few instances, whereas it was just my slow machine struggling.

Anyway, I got the HID Keyboard Device example working and studied the structure of your code a bit to understand how I might use it in my project.

Now, I am trying to use the Host Keyboard HID examples (low level & Class Driver versions)and I'm running into a problem.

By the way when I set-up these projects for my USBKEY platform, the process went a lot smoother.

In both projects (low level and Class Drivers) I get the same symptoms:

The USART terminal indicates the following messages repeatedly:

Device Attached.

Dev Enum Error
-- Error Code 3
-- Sub Error Code 2
-- In State 7

Device Unattached.

I've gone thru your code trying to identify what these numeric error codes are telling me, but it seems there are multiple enumerated error code sets. So, I'm not sure which apply to this example.

The best I can figure is that the program is asking the keyboard to perform a command it doesn't know, or that the keyboard is asking for too much buffer space. I've tried two known-good keyboards and get the same error messages. I also switched the USBKEY power source from a 9-volt battery to a strong bench supply. That didn't seem to change anything, same errors.

Any guidance you, or other Freaks, can provide will be greatly appreciated.