LUFA USB Connection Timeout

Question

Someone pro in LUFA framework and AVR microcontrollers?

I have a function that builds a table (stored on heap memory) with 256 elementes received on my Usb connection and the program takes to long to generates this table that my USB connection brokes (i hear the Windows sound when you unplug a device). I call this function after HID_Device_USBTask() and USB_USBTask() functions inside the while loop but as you can imagine, it didn´t work well.

This situation gets worse when i call the function to compute the 256 elements of data.

That's what i do: i receive a block of 8 bytes of data and append each block to my big ass table! My code works with a short tables like 16 bytes or so, but with a big one like 256 bytes it goes to hell!

It seems that the USB conection it ran a time-out or something.

There is my pseudo-code:

uint8_t *p_data_to_save = NULL;
uint8_t *p_data_to_host = NULL;

int main(void)
{
    p_data_from_host = (uint8_t*)calloc(8, sizeof(uint8_t));
    p_data_to_save = (uint8_t*)calloc(256, sizeof(uint8_t));

    SetupHardware();
    LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
    GlobalInterruptEnable();

    for (;;)
    {
        HID_Device_USBTask(&Generic_HID_Interface);
        USB_USBTask();

        if (new_bytes_recived == true )
        {
             // Append 8 bytes received to my 256 bytes table
            if(indx_data < 255)
            {
               for(int i=0; i<8; i++)
               {
                  p_data_to_save[indx_data] = p_data_from_host[i];
                  indx_data++;

               }
            }

            new_bytes_recived = false;
         }

         if(table_completed == true)
         {

             // Process the 256 bytes of data
             Process_table();
          }

          (...)  // other smal if-cases
    }
    free(p_data_from_host);
    p_data_to_host=NULL;
    free(p_data_to_save);
    p_data_to_save=NULL;
}

On CALLBACK_HID_Device_ProcessHIDReport():

 void CALLBACK_HID_Device_ProcessHIDReport(USB_ClassInfo_HID_Device_t* const HIDInterfaceInfo,
                                      const uint8_t ReportID,
                                      const uint8_t ReportType,
                                      const void* ReportData,
                                      const uint16_t ReportSize)
 {
  unsigned int i;
  uint8_t* Data       = (uint8_t*)ReportData;
  for (i=0;i<8;i++)
  {
     p_data_from_host[i]=Data[i];
  }

   new_bytes_recived = true;
}

Any solution to this?

Thank you all

PS: I'm using an Atmega16u2.

score 0 · Accepted Answer · answered Jul 23 '15 at 20:30

0

The ATmega16U2 only has 512 bytes of RAM. You didn't show the definition of your table but I think it's safe to assume that your table takes up the entire RAM. It's too bad your linker didn't give you a warning about this. You'll have to get a better microcontroller (like the ATmega32U4) or make your table smaller.

Keep in mind that most local and global variables get stored in RAM by default, so you can't simply use up all of the RAM for your table.

answered Jul 23 '15 at 20:30

David Grayson

84,103
24
152
189

Sorry for forgetting to mention. The table data is stored on heap memory. And working o little more on my code, i just reduced the big table to the 256 bytes and the same problem still goes on. I think that i can't reduce nothing more than that. – JNeto06 Jul 23 '15 at 21:05
PS: I already updated my question with size of the table and the storing type. Thanks for pointing that. – JNeto06 Jul 23 '15 at 21:12
OK, it sounds like 256 bytes is still too big. It's possible that LUFA needs more than 256 bytes to run. Really you should get your linker to produce a map file so you can see how much RAM is being taken up and why. You probably shouldn't use the heap; just define the table as a global variable. If you do use the heap, check to make sure that malloc doesn't return NULL. I wonder why you haven't posted the code for defining/allocating the table yet, since the size of the table seems to be a crucial piece of your problem. – David Grayson Jul 23 '15 at 21:21
I already updated my pseudo-code showing the allocation of the table. I have to use heap since i have a lot more code to implement and the memory usage will be critical. Building my solution (the complete project solution) i got until now: Program Memory Usage : 8488 bytes 51,8 % Full Data Memory Usage : 60 bytes 11,7 % Full – JNeto06 Jul 23 '15 at 22:16
If LUFA only uses 60 bytes and your table uses 256 bytes, I would think that would work, because you would have almost half of the memory left over. But do you have any other code that is using the heap other than this one table? Also, the only reason to use the heap is if you plan on freeing the table later to use the memory for something else; is that the case? – David Grayson Jul 24 '15 at 18:56
1

Hey David Grayson. Sorry for the late response. You were right. The problem seems to be the table allocation on the heap memory. Just like i said the memory management is a critical point on my project, so the only solution remainder was re-code the all project again. Now i got rid of my big ass table of 256 bytes and now i work only with mini tables of 8 bytes. I was not easy to re-code all again and the algorithm it's not the most efficient but it gets the job done :D Thank you very much for your support. – JNeto06 Jul 27 '15 at 22:31
Glad it worked out. Please mark this as an excepted answer. – David Grayson Jul 28 '15 at 01:20

LUFA USB Connection Timeout

1 Answers1