I have been experimenting with using this framework to program a flash chip via an atmega32u4.

I am OK with sending single packets to program and communicate with the flash chip, but now I need to fill the whole chip up. What would be the best way to accomplish this? I have tried sending multiple report packets that contain the data, but it always fails.

Out of the box, tests 4 and 5 always fail, even with debug output turned off

Just a general USB question: are packets guaranteed to be received by the device in the order they are sent (from the host)?

thanks for the help

The packets will arrive in the order that they are sent. The USB protocol and LUFA take care of that for you.

It is odd that you have failing packets though. The test software for the framework tests 128 x 64 byte packets in both directions in a single 'command'. If your application is sending more than that it is possible that you are seeing a 'bug' which the framework testing doesn't detect.

The obvious thing to look for is any single byte variables which would overflow when you exceed 255 packets in a single command, but that doesn't explain why it works 4 out of 5 times.

I would suggest going back to the test software and tweaking it to send and receive more packets to see if you can make it fail in a reproducible manner?

Thanks for the response.

What I meant by Tests 4 and 5 fail is that the default tests included in the demo program have never worked for me, even with debugging off.
I was looking to springboard off "Test 4" (send 128 packets). I would basically be copying "Test 4" functionality for my application.

If I could get the demo application working properly that might help. I saw in this thread: viewtopic.php?f=18&t=1350



...but I dont know where in the code to do this. I also thought that by disabling debug messages, it would work regardless.

In my testing, I tried to send as little as 32 packets with a WriteMulitpleReports command, and that didn't work either.
I will reload the AVR with stock firmware from the project and experiment some more. Perhaps I jacked something up when adding my other code.

Thanks again. This is really cool stuff overall, thanks for writing this framework - just threw some € your way!

Thanks for the donation, very much appreciated

Is it possible for you to gather the debug output from the running host code and show me the messages around when it fails?

The reason for the test code is so I can regression test the library and make sure it works... If the original code is failing then that is odd... Also can you let me know what type of board you are testing against (is it a paid-for board or one of your own design)?

It is possible that the hardware itself produces the instability when under load - hence the question.

Also> to slow down the debug you simply increase the debug timer period in the C# host application. Nothing needs to be changed in the AVR code.

P.S. I should have read your original post a little slower re: the 4 out of 5 comment

I reverted to a fresh build of the stock firmware and am running into the same issue.



Sure thing, here it is:


Do subsequent packets after the first (ie bulk send mode) have to start with "0"? I thought I read that somewhere in the comments but could be making it up.


It is a board I designed myself. Schematics here: http://electrifiedfoolingmachine.co/pro ... ASHROM.pdf
USB signal pair is routed as a diff pair, short as possible to the uC.
Should I check out how the signals look on a scope? I am able to run Test 3 OK, so I have no problem receiving 128 packets from the device. Just sending to the device, it seems.

In the code, I didn't really understand the board configuration stuff in regards to the LEDs and buttons, so I just ignored it for now. Could that be a source of error?


haha no worries
Thanks

Hrm. Test 4 and 5 sometimes pass, but only after I run Test 1,2 or 3 before hand.

Test 4 debug from the device:

I don't see any issues with your schematic.

Presumably, after the failed test the host 'disconnects' the device and you have to plug it out and in? If anything goes wrong the host library should do this... although I don't see that in the debug?

You don't have to pad the data with zeros or anything, there are some strange windows API requirements, but the library takes care of that for you.

It is very hard to track this type of issue without having the board, but here are some suggestions. Firstly ensure that your capacitor values are correct (especially on the crystal and UCAP). Hook up a scope to the power rails near the chip, pop the scope into AC mode and have a look at the power rail noise to ensure that you have correctly decoupled the chip (run the bulk send test whilst watching this).

Hook up a multimeter the +5V line from the PC and measure your current draw (I have an adapted USB cable just for doing this since you need to cut the 5V line and feed it through the multimeter). Ideally you should not be exceeding 100mA on startup and then up to 500mA after enumeration. Also test your board by connecting to a powered USB hub and try again.

It really is feeling around in the dark If you have access to a teensy board (or something similar), it would be good to test the library and firmware against a known piece of hardware - at least that way we would know if it is hardware or software at fault.

Sorry, sometimes the full debug shows, sometimes not:


Need to restart the program to send commands again.

I looked at the power pins on the uC, seems pretty stable. I don't see any hard dips or fluctuations in the power. 16 MHz clock looks pretty good, altho i have to use a very short ground wire on my probe to get a respectable looking signal. but i believe the clock is good.

I'll measure the current draw when I find a spare USB cable to hack up.
I don't have any powered USB hubs, but I am plugged into my motherboard directly.

I changed this code to 10 seconds and doesn't help:


I understand this is shooting in the dark here, but I appreciate your insight.
I wonder what the deal is

The first debug you copied failed when writing to the device. The second is showing the failure on read... If the failure is inconsistent (which since the failure reasons are different and sometimes it works) it would point with some certainty to a hardware issue provided you are running 'stock' host code and firmware.

Can you make sure that your ATmega32u4 has power and ground on every power pin and to the USB pins? Make sure you test on the actual pin rather than the PCB trace in case a pin is not correctly soldered. I've had problems like that in the past with SMD chips, hence the suggestion.

Good suggestion - all the VCC pins have power. 4.8V. Voltage @ Ucap is 3.27V.
Double checked all solder joints under high power microscope...everything looks OK.
I'm drawing ~38 mA before enumeration.

Latest development:
If I run the tests sequentially 1 through 5 (with debug collection off), every test will pass successfully.
If I run the tests sequentially 1 through 5 (with debug collection on, but modified to 10 second timeout), every test will pass successfully.

If I just run just Test 4 to start (after increasing the delay in VS) it seems to work 99% of the time now...

Just for sake of clarity, I am posting the latest debug info

When it does fail, this is the host debug info:


And the device debug info:


So this says...the device got the wrong information in the initial packet and then terminated operation, which causes the ReadFile timeout to occur?

I'm going to try to snoop the USB bus to see some more info.