Objective Development Forums

Hi: This is the declaration of usbIsReset, in usbdrv.c (This is a version from 2008, so perhaps this variable no longer exists):

I think the comment is wrong. usbIsReset = 0 when out of reset. Am I right? Another question is this: what is it used for? Only to set usbDeviceId and usbNewDeviceId to zero? And by the way: these two variables are actually the address field of the package, are they not?

I couldn't find that variable in several of the 2008 versions. From the comment, it looks more like it's just trying to emphasize that static objects in C are initialized to 0 if no initializer is present. In other versions there's a local static for calling a user-defined reset handler only once, and the variable is used to keep track of whether it's been called, so maybe this is for that purpose.

blargg wrote:I couldn't find that variable in several of the 2008 versions. From the comment, it looks more like it's just trying to emphasize that static objects in C are initialized to 0 if no initializer is present. In other versions there's a local static for calling a user-defined reset handler only once, and the variable is used to keep track of whether it's been called, so maybe this is for that purpose.

Thanks blargg. Let's change usbIsReset by another variable: usbDeviceId, which may be present in newer versions. This variable is so declared in usbdrv.c:
And my question is now another one: this variable needs to be zero when control first enters the external interrupt service routine, but it is set to zero nowhere in either usbdrv.c or usbdrvasm.S. It is no other thing than the device address, which must be zero when starting enumeration. How can the declaration above make the variable initial value zero? In C, all uninitialized global variables are zero when the program is loaded (from disk). But here, after turning on power, the RAM is in an aleatory state!

The sources I am using are not among the versions listed in this site. I am, however, giving you a link, http://www.filedropper.com/takefuji-213, coded in 2004 by Christian Starkjohann, except the app, da.c, which by its very simplicity is easy to analyze, in case you care to skim it.

The why:

For a program running from the ROM of a microcontroller there likely is no loader, and the task of zeroing BSS would fall to the program's runtime startup routine (crt0 in the old days). According to the avr-libc manual, you have the option of placing uninitialized variables in the .bss section (which should be all zero) or the .noinit section, which is a .bss subset that does not get zeroed on startup.

This quotation is from linuxquestions.org. I did not use that option. Do . It outputs usbdrv.o and usbdrv.s. The latter is an assembler source, the C source file translated into assembler. Looking into it, you'll see
The global variable under discussion is declared in usbdrv.c:
This variable is used, but not declared, in usbdrvasm.S. But gcc (or avr-gcc, it's the same) considers all undeclared variables in an assembler source as externals. So, in usbdrv.s, it looks like this:
Now, if common variables are taken as globals by gcc, we have that usbDeviceId debuts as zero in the executable! The code to clear the .bss section CANNOT be seen in the assembler sources generated by gcc. It lies in some library and put ahead of the programmer's code by the linker. What do you know?

The AVR-LIBC erases the the bss section before entering main. You can actually see it when disassembling:

This is just an arbitrary example:

>avr-objdump -d -S main.bin >main.lss

Fantastic! Thanks cpldcpu.