Assert failures

[profilernz]

Hi. I'm trying to incorporate uspi into a Pi port of xv6. Any idea why I would be getting these: uspi_assert_fail: expr: s_pLibrary == 0: file: uspilibrary.c line: 34 uspi_assert_fail: expr: s_pThis == 0: file: devicenameservice.c line: 33 Thanks :)

[rsta2]

I think, there are only two possible reasons for these asserts: USPiInitialize() is called twice or the BSS memory segment is not filled with zero before USPiInitialize() is called.

[profilernz]

Indeed, it was BSS related. Compiling with -fno-zero-initialized-in-bss made them go away. Thanks again :)

[rsta2]

Yes, the USPi library relies on a clean (all-zero) BSS segment at start-up. Normally the BSS is cleared by the system initialisation code, so that this option is not needed.

[profilernz]

Thanks. My limited understanding is that all initialised variables go in .data, but zero-initialised ones are placed in .bss for compiler optimisation reasons? Anyway, we don't seem to have any BSS related requirements in our project, so the switch works well in our case.

[rsta2]

GCC by default puts variables that are initialized to zero into BSS. This can save space in the resulting code. The option -fno-zero-initialized-in-bss turns off this behaviour and puts them into .data. If this option works for you, I see no reason why it's not OK to use it.

[profilernz]

Thanks, that's more or less what I had gathered. I'm having another issue atm... While initialising uspi, it currently hangs on: while (pThis->m_bWaiting) {} inside DWHCIDeviceTransferStage. Interestingly, I noticed that if I shorten the delay done on MsDelay, then it doesn't hang and I get this: uspi_log: dwhci: No device connected to root port uspi_log: uspi: USPi library successfully initialized I suspect I may not have the interrupts working correctly? Or perhaps power? Just wondering if you would have any insights... Thank you very much again...

[rsta2]

Yes, if USPi is hanging in that loop, it is waiting for an interrupt, which never comes. This may be caused by a failed power on switch of the USB circuit too.

[profilernz]

Great, thanks.

[profilernz]

Interrupts are working now, we were calling it too early in the boot process and interrupts were not yet enabled then...

[rsta2]

OK, great. So this can be closed?

[profilernz]

Sure, thanks for all your help...