Rockbox.org home
Downloads
Release release
Dev builds dev builds
Extras extras
themes themes
Documentation
Manual manual
Wiki wiki
Device Status device status
Support
Forums forums
Mailing lists mailing lists
IRC IRC
Development
Bugs bugs
Patches patches
Dev Guide dev guide
Search



Donate

Rockbox Technical Forums


Login with username, password and session length
Home Help Search Staff List Login Register
News:

Welcome to the Rockbox Technical Forums!

+  Rockbox Technical Forums
|-+  Rockbox Development
| |-+  Starting Development and Compiling
| | |-+  Dereferencing a pointer doesn't give what's actually at the pointer?!
« previous next »
  • Print
Pages: [1]

Author Topic: Dereferencing a pointer doesn't give what's actually at the pointer?!  (Read 1840 times)

Offline fanta2

  • Member
  • *
  • Posts: 5
Dereferencing a pointer doesn't give what's actually at the pointer?!
« on: December 30, 2008, 09:36:11 AM »
I've hit an annoying snag whilst making some modifications to the usb stack; which have me stumped. I asked in IRC, but noone seemed to know what was going on, so I decided to ask here. The complete function is below:

Code: [Select]
int ptp_sendobject(unsigned short command)
{
    if (!session.curobjinfo.open) return -1;
   
    usb_drv_recv(ep_out, buffer, sizeof(struct ptp_container_header));
    struct ptp_container_header *header;
    header = buffer;
   
//    if (header->wType != PTP_CONTAINER_TYPE_DATA) return -2;
    // Get the filesize
    uint32_t *temp = buffer;
    uint32_t temptwo = *temp;
    uint32_t filesizeremaining = temptwo - sizeof(struct ptp_container_header);
   
    // Start writing data to the file
    int packetsize = endpoint_descriptor.wMaxPacketSize;
    logf("hdrlent %d", header->iLength);
    logf("hdrlenp %d", *((uint32_t*)buffer));
    logf("tmptmpt %d", *temp);
    logf("tmptmp2 %d", temptwo);
    logf("hdrtype %d", header->wType);
    logf("filesze %d", filesizeremaining);
    logf("pktsize %d", packetsize);
    logf("%x %x %x %x", *(buffer+0), *(buffer+1), *(buffer+2), *(buffer+3));
    logf("%x %x %x %x", *(buffer+4), *(buffer+5), *(buffer+6), *(buffer+7));
    logf("%x %x %x %x", *(buffer+8), *(buffer+9), *(buffer+10), *(buffer+11));
    logf("%x %x %x %x", *(buffer+12), *(buffer+13), *(buffer+14), *(buffer+15));
    int i = 0;
    while (filesizeremaining > packetsize) {
        usb_drv_recv(ep_out, buffer, packetsize);
        write(session.curobjinfo.fd, buffer, packetsize);
        filesizeremaining -= packetsize;
        logf("got data %d", i++);
    }
   
    // Write up the remainder of the file and close up, resetting curobjinfo
    usb_drv_recv(ep_out, buffer, filesizeremaining);
    logf("got last data %d", i);
    write(session.curobjinfo.fd, buffer, filesizeremaining);
    close(session.curobjinfo.fd);
   
    session.curobjinfo.open = false;
   
    return 0;
}

The problem segment is the following:

Code: [Select]
    // Get the filesize
    uint32_t *temp = buffer;
    uint32_t temptwo = *temp;
    uint32_t filesizeremaining = temptwo - sizeof(struct ptp_container_header);
   
    // Start writing data to the file
    int packetsize = endpoint_descriptor.wMaxPacketSize;
    logf("hdrlent %d", header->iLength);
    logf("hdrlenp %d", *((uint32_t*)buffer));
    logf("tmptmpt %d", *temp);
    logf("tmptmp2 %d", temptwo);
    logf("hdrtype %d", header->wType);
    logf("filesze %d", filesizeremaining);
    logf("pktsize %d", packetsize);
    logf("%x %x %x %x", *(buffer+0), *(buffer+1), *(buffer+2), *(buffer+3));
    logf("%x %x %x %x", *(buffer+4), *(buffer+5), *(buffer+6), *(buffer+7));
    logf("%x %x %x %x", *(buffer+8), *(buffer+9), *(buffer+10), *(buffer+11));
    logf("%x %x %x %x", *(buffer+12), *(buffer+13), *(buffer+14), *(buffer+15));

According to logf, the data located at buffer is exactly what's sent over usb. I'm trying to get an unsigned int from the start of the packet, but no matter what I do and regardless of the actual value stored at buffer, if I dereference the pointer and store the result in a normal variable on the stack(?) it equals 12 (perhaps coincidentally, the previous value stored at buffer is 12). The weird thing is, if I dereference the pointer straight up as an argument to logf, it shows the correct value.

Any ideas? Thanks :)
Logged

Offline dreamlayers

  • Developer
  • Member
  • *
  • Posts: 425
  • Boris Gjenero
    • My Blog
Re: Dereferencing a pointer doesn't give what's actually at the pointer?!
« Reply #1 on: December 30, 2008, 10:03:06 AM »
How is the data getting into the buffer?  Is it written by the CPU or by USB hardware (DMA)?   Try looking at UNCACHED_ADDR(buffer).
Logged

Offline fanta2

  • Member
  • *
  • Posts: 5
Re: Dereferencing a pointer doesn't give what's actually at the pointer?!
« Reply #2 on: December 30, 2008, 12:15:25 PM »
Changing 'uint32_t temptwo = *temp' to 'uint32_t temptwo = *((uint32_t*)UNCACHED_ADDR(buffer));' didn't seem to do anything, unfortunately :(.

EDIT: Neither did changing uint32_t *temp = buffer to use 'UNCACHED_ADDR(buffer)' either. I imagine the usb driver is using DMA (I'm coding with a sansa e200R, so it'll be using usb_drv_arc.c for the driver I believe).
« Last Edit: December 30, 2008, 12:32:12 PM by fanta2 »
Logged

Offline gevaerts

  • Administrator
  • Member
  • *
  • Posts: 1053
Re: Dereferencing a pointer doesn't give what's actually at the pointer?!
« Reply #3 on: December 30, 2008, 01:05:43 PM »
The ARC controller does indeed use DMA, so you do need UNCACHED_ADDR everywhere (see usb_storage.c for an example, especially usb_storage_init_connection())

Also, you shouldn't care about the packetsize, the underlying driver handles that for you. Just call usb_drv_recv() once with whatever size buffer you can handle, not once per packet.

(Edit) One more thing, and probably your main problem : usb_drv_recv() isn't synchronous. You call it, and then you do nothing until your transfer_complete() function is called.
« Last Edit: December 30, 2008, 06:33:06 PM by gevaerts »
Logged

Offline fanta2

  • Member
  • *
  • Posts: 5
Re: Dereferencing a pointer doesn't give what's actually at the pointer?!
« Reply #4 on: January 01, 2009, 03:14:39 AM »
Gah, makes sense >.<. I wasn't entirely sure about whether packet size had an effect on what I could grab, and I guess usb_drv_send_nonblocking() had me confused about whether it blocks or not; thanks :).
Logged

  • Print
Pages: [1]
« previous next »
+  Rockbox Technical Forums
|-+  Rockbox Development
| |-+  Starting Development and Compiling
| | |-+  Dereferencing a pointer doesn't give what's actually at the pointer?!
 

  • SMF 2.0.17 | SMF © 2019, Simple Machines
  • Rockbox Privacy Policy
  • XHTML
  • RSS
  • WAP2

Page created in 0.204 seconds with 15 queries.