Bizarre function call issue

[avrhack]

OK here's another strange one - I seem to be attracting them at the moment!

Doing a very simple call to usbPrepareTransmit - the exact lines are:

Code: Select all

int ToHost(void *data, unsigned int len)
{
    usbPrepareTransmit(&USBD1, 1, data, len);

I get a sigsegv when debugging which suggested a stack corruption so I doubled the main stack to 0x800 even though I've declared only 8 bytes of data!

Got to the stage where I was single stepping individual ARM instructions in the debugger rather than source lines and gdb comes up with this as the calling pattern:

Code: Select all

usbPrepareTransmit (usbp=0x8005e45 <chMtxLock+20>, ep=32 ' ', buf=0x0, n=536875184) at ../Common/ChiBIOS/os/hal/src/usb.c:427

Now this is clearly not right - looks like corruption of the calling parameters, fair enough. But how on earth is that happening with such a simple call fragment? Been trying to track this down for hours and can't for the life of me see what the issue is but it has to be something simple. I've checked the calling parameter types - pointer, int, pointer, int and they seem fine, so what is is? Hopefully someone will take a quick look, have a good laugh at my expense and point out the one-liner fix. Please?

[Giovanni]

Then probably the problem is not there.

Try this: http://chibios.org/dokuwiki/doku.php?id ... ebug_guide

Giovanni

[avrhack]

Then probably the problem is not there.

Try this: http://chibios.org/dokuwiki/doku.php?id ... ebug_guide

Giovanni

Thanks. Already had all of the debugging and -O0 set. That's the strange thing - unlike a lot of the random corruption issues that the debugging tips link above gives, this issue always happens on the same instruction as part of the stack parameter push. I guess what I haven't checked is where the stack pointer is pointing! Hmmm - good - something else for me to check as I had completely run out of ideas......

[avrhack]

Problem solved.

The lesson learned is that you mustn't try and do a usbPrepareTransmit until the usb->state is USB_ACTIVE, otherwise your main usb event handler won't have called usbInitEndpointI and as a result the endpoint pointers will be garbage with the result that you can cause all manner of a mess.

Giovani - I'm surprised there isn't a check for this in ChibiOS. Something you want to add to the usb driver code?

[Giovanni]

Glad you solved, I will look into adding a check there.

Giovanni

[flabbergast]

BTW, I had something similar come up lately (90% power-ups resulted in a HardFault of the firmware - but not all!). The firmware *did* wait until USB_ACTIVE, but I had a call right after that, which was sometimes fast enough to try to write to an endpoint which (apparently) wasn't completely ready yet - which resulted in usbStartTransmit getting a garbage pointer resulting in an unaligned read or write => HardFault.

After figuring this out, I just added a little wait even *after* the firmware is done waiting for USB_ACTIVE, and had no problems (with this since.

[avrhack]

BTW, I had something similar come up lately (90% power-ups resulted in a HardFault of the firmware - but not all!). The firmware *did* wait until USB_ACTIVE, but I had a call right after that, which was sometimes fast enough to try to write to an endpoint which (apparently) wasn't completely ready yet - which resulted in usbStartTransmit getting a garbage pointer resulting in an unaligned read or write => HardFault.

After figuring this out, I just added a little wait even *after* the firmware is done waiting for USB_ACTIVE, and had no problems (with this since.

Good tip thanks!

Giovani I think this shows that adding an osalassert around this area would be very beneficial - I always develop with all debugging features on and it looks like such a simple addition would have saved a load of debugging time not just for me but others as well.

Cheers.