LUFA CDC problem with SendByte function

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

I'm using Atmega32U4, USB interface, LUFA CDC and Atmel Studio 7.0; Terminal.exe on the PC side. My goal is to receive one byte from pc (command = 51), recognize this command using switch operator, and  send two bytes (uint8_t byte1 = 19, uint8_t byte2 = 33) from MC to PC as an answer. Problem is:  CDC_Device_SendByte(..., inbyte) works fine (return 51 to pc), but other 2 calls of function CDC_Device_SendByte, placed inside of switch operator dont work correct. What i get on pc side is 07 00, sometimes 0f 00. Can anyone please help me with that?

if((inbyte = CDC_Device_ReceiveByte(...)) > 0){
...
switch(inbyte)
{
    ...
    case 51:
    CDC_Device_SendByte	(... , byte1);
    CDC_Device_SendByte	(... , byte2);
    break;
    ...
}

CDC_Device_SendByte	(... , inbyte);
}
...
This topic has a solution.
Last Edited: Thu. Aug 10, 2017 - 06:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Sorry your code does not compile, much detail is missing, the devil is often in the details......

You send blindly, the function has a return value, but you ignore it, perhaps it would shed light on the problem if you looked at what it returns.....

 

Just a few thoughts.

 

Jim

 

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

ki0bk wrote:
much detail is missing

+1

 

As always, it is best to reduce the problem to the smallest possible program that builds and runs and displays the problem. Post that complete program.

 

Is only sending involved in the problem? E.g. if you code a minimal program that just does three consecutive calls to CDC_Device_SendByte() will that also fail?

 

Or is the reception a part of the problem. Expand your program to do the reception of a byte before the three sends above.

 

NoobN32 wrote:
but other 2 calls of function CDC_Device_SendByte, placed inside of switch operator dont work correct. What i get on pc side is 07 00, sometimes 0f 00.

The problem might not at all have to do with the sending failing, but perhaps instead that the data in your two variables byte1 and byte2 gets corrupted before sending. Again ki0bk's remark applies: You have not shown us enough code. Complete code please, but  still minimal.

 

It is your job to isolate the problem. We certainly can not do it. And chances are you will get good leads on what the actual problem is when you start to reduce your code to the minimal. This approach is normal in any software development.

 


 

Here's one test you can do right away. Keep your code just as it is right now, but instead of

    CDC_Device_SendByte	(... , byte1);
    CDC_Device_SendByte	(... , byte2);

you do

    CDC_Device_SendByte	(... , 19);
    CDC_Device_SendByte	(... , 33);

i.e. send two bytes that are known and constant at the point of call to the sending function. If they come out correct at the other end (with repeated tests!) then it hints that your problem lies not in the sending but in the corruption of data before sending. If so then that is a completely different hunt than the one you're on right now.

 


 

All fault seeking starts with trying to isolate the problem as much as possible. You do this by i) thinking "outside the box", ii) formulating different hypotheses about what might be wrong and iii) set up small tests to either accept or reject the hypotheses.

 

You assume that it is the sending as such that is what fails. That is an un-grounded shot in the dark, and hard to accept/reject. Try to form other hypotheses that are easier to prove/disprove. You might end up with "everything else works" and then it becomes more plausible that it is the sending that fails, but my bet is on its something else. Corruption of data in RAM is a ubiquitous phenomenon when coding in C.

 

Are your variables byte1 and byte2 local to the function? Do you also have a string buffer that is local to the function? If so I'd start with looking at writes to that string, and making sure the buffer is large enough.

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"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]

Last Edited: Wed. Jul 19, 2017 - 09:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe you can find some usefull info in this post:

http://www.avrfreaks.net/forum/c...

 

Where I promote Sigrok / Pulseview Logic Analyser for debugging low-speed USB with USD 5 worth of hardware.

(With more expensive hardware you can also capture higher speed usb trafic).

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

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

LUFA is high speed USB. Use USB Analyzer to trace the transaction.
.
Johan is right. Your byte var may cause the problem.. Send magic number do the trick.
.
And as Jim said, check the return value if available.
.
MG

I don't know why I'm still doing this hobby

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tnx everybody for your help! Problem was on PC side (programm called Terminal.exe, I made stupid mistake. Commands I sent were incorrect, because Terminal sends hex numbers, not dec). JohanEkdahl, thank you very much for your time and detailed response. But I have another problem in my project (it is about external ADC), if you have time, please, look trough it          =>      http://www.avrfreaks.net/forum/a...