2009-02-15 15:01:00     bfin-elf-ldr returns "bad file descriptor"

Document created by Aaronwu Employee on Oct 16, 2013
Version 1Show Document
  • View in full screen mode

2009-02-15 15:01:00     bfin-elf-ldr returns "bad file descriptor"

Shawn Goff (UNITED STATES)

Message: 69464   

 

I'm trying to reflash my device and I get the following:

 

$ bfin-elf-ldr -l -v ./srv1.ldr.115k /dev/ttyUSB0

Loading LDR ./srv1.ldr.115k ... auto detected LDR as 'BF537' compatible format

OK!

Opening /dev/ttyUSB0 ... OK!

Configuring terminal I/O ... [getattr] [setattr] [speed:115200] OK!

Trying to send autobaud ... OK!

Trying to read autobaud ... Failed: Bad file descriptor

 

 

 

The cable is fine; if I reset the device not in UART boot mode, I can both send and recieve data at 115kbps. Any suggestions?

QuoteReplyEditDelete

 

 

2009-02-15 15:52:11     Re: bfin-elf-ldr returns "bad file descriptor"

Mike Frysinger (UNITED STATES)

Message: 69466   

 

what version of the toolchain are you using ?

 

can you post the log as an attachment from doing:

strace -s 4096 -o log bfin-elf-ldr ....

QuoteReplyEditDelete

 

 

2009-02-15 19:05:45     Re: bfin-elf-ldr returns "bad file descriptor"

Shawn Goff (UNITED STATES)

Message: 69467   

 

I don't know what the problem was, and it's fixed now so I can't print out the log until I encounter it again. I fixed it by borrowing a Windows system and using www.dolomitics.com/downloads/ldrviewer.html.

QuoteReplyEditDelete

 

 

2011-04-11 14:59:55     Re: bfin-elf-ldr returns "bad file descriptor"

Adam Trhon (CZECH REPUBLIC)

Message: 99762   

 

I have the same error. When I turn on my computer (Arch linux i686), I can load the firmware as many times as I want to:

 

$bfin-elf-ldr --load main.ldr /dev/ttyUSB1

 

But when I run my Python script which (successfully) communicates with the device, I get the bad file descriptor error on next load. Replugging the device doesn't help, I have to reboot the computer. Or connect to the device with Cutecom (pySerial doesn't do the job), load the firmware (successfully) and disconnect Cutecom.

 

Strace shows me two differences:

 

    something with locks

 

    Successful run:

 

    access("//var/lock", R_OK)              = 0

    open("//var/lock/LCK..ttyUSB1", O_RDONLY) = 4

    fstat64(4, {st_mode=S_IFREG|0644, st_size=5, ...}) = 0

    mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7784000

    read(4, "3948\n", 4096)                 = 5

    kill(3948, SIG_0)                       = -1 ESRCH (No such process)

    write(1, "Removing stale lock '//var/lock/"..., 46) = 46

    unlink("//var/lock/LCK..ttyUSB1")       = 0

    close(4)                                = 0

    munmap(0xb7784000, 4096)                = 0

    umask(022)                              = 022

    open("//var/lock/LCK..ttyUSB1", O_WRONLY|O_CREAT|O_EXCL, 0666) = 4

    umask(022)                              = 022

    fcntl64(4, F_GETFL)                     = 0x1 (flags O_WRONLY)

    fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0

    mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7784000

    _llseek(4, 0, [0], SEEK_CUR)            = 0

    write(4, "5490\n", 5)                   = 5

    close(4)                                = 0

    munmap(0xb7784000, 4096)                = 0

    close(4)                                = -1 EBADF (Bad file descriptor)

       

 

    

 

    Failing run:

 

    access("//var/lock", R_OK)              = 0

    open("//var/lock/LCK..ttyUSB1", O_RDONLY) = -1 ENOENT (No such file or directory)

    umask(022)                              = 022

    open("//var/lock/LCK..ttyUSB1", O_WRONLY|O_CREAT|O_EXCL, 0666) = 4

    umask(022)                              = 022

    fcntl64(4, F_GETFL)                     = 0x1 (flags O_WRONLY)

    fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0

    mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7763000

    _llseek(4, 0, [0], SEEK_CUR)            = 0

    write(4, "3520\n", 5)                   = 5

    close(4)                                = 0

    munmap(0xb7763000, 4096)                = 0

    close(4)                                = -1 EBADF (Bad file descriptor)

 

    Notice the EBADF error.

 

    

    maybe a bug in bfin-elf-ldr

    This is strace from failing run:

 

    write(1, "Trying to read autobaud ... ", 28) = 28

    read(4, "", 4)                          = 0

    dup(2)                                  = 5

    fcntl64(5, F_GETFL)                     = 0x2 (flags O_RDWR)

    fstat64(5, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0

    mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7765000

    _llseek(5, 0, 0xbfb3e290, SEEK_CUR)     = -1 ESPIPE (Illegal seek)

    write(5, "Failed: Bad file descriptor\n", 28) = 28

 

    Everything goes wrong when calling read(). I checked the source code, in the ldr_load_uart() the read_retry() function is used, which calls read(). The read() call returns a zero, which is considered to be an error in ldr_load_uart(), so ldr_load_uart() calls perror(). But there was no error, so perror() reads the EBADF code from closing closed lock.

 

$ bfin-elf-ldr --version

ldr-utils-svn-3778: /usr/src/packages/BUILD/blackfin-toolchain-2010R1/ldr-utils/ldr.c compiled Oct  5 2010

$Id: ldr.c 4850 2010-08-30 08:21:57Z shenders $

 

 

ldr-success.log

ldr-failure.log

QuoteReplyEditDelete

 

 

2011-04-11 15:34:39     Re: bfin-elf-ldr returns "bad file descriptor"

Mike Frysinger (UNITED STATES)

Message: 99764   

 

the output from strace you've noticed is irrelevant.  it's coming from the lock code and is completely harmless as the return value is never checked.  helpers.c:tty_lock().

 

so while the output is confusing (ive made some changes in svn for that), it still doesnt explain the problem.  when reading the autobaud result, you should be getting exactly 4 bytes back.

 

maybe your machine is too fast ?  what if you put a sleep(1) before the "Trying to read autobaud" step ?

QuoteReplyEditDelete

 

 

2011-04-11 16:46:10     Re: bfin-elf-ldr returns "bad file descriptor"

Adam Trhon (CZECH REPUBLIC)

Message: 99767   

 

Well, I cannot find any connection as well, but as far as I know the lock fails just when the whole program fails, so it may be another symptom.

 

Is it enough to run bfin-elf-ldr --load -p ... instead of rebuilding the toolchain with sleep(1)? If so, it doesn't help. And I think it is not the speed - I can run the loader as many times I want, I just cannot let python mess with the port:

 

#writing and reading a 41kB image and some info

vepa = serial.Serial(sys.argv[1], 921600, timeout=15)

vepa.write(size)

 

time.sleep(0.1)

 

written = 0

while (written < len(img)):

        written += vepa.write(img[written:])

 

 

main_prof_time = vepa.readline()

prof_time = vepa.readline()

 

size = vepa.read(8)

 

img = vepa.read(size[0]*size[1])

 

When I run this, I have to have the port opened in cutecom to make the loader work:

 

bfin-elf-ldr --load ... #ok

bfin-elf-ldr --load ... #ok

bfin-elf-ldr --load ... #ok

./device-client.py #ok

bfin-elf-ldr --load ... #fails

#port opened in cutecom

bfin-elf-ldr --load ... #ok

#port closed in cutecom

bfin-elf-ldr --load ... #fails

#port opened in cutecom

bfin-elf-ldr --load ... #ok

./device-client.py #ok

bfin-elf-ldr --load ... #fails

#port closed in cutecom

#port opened in cutecom

bfin-elf-ldr --load ... #ok

etc...

 

Replacing cutecom with another python script doing the same (opennig the port and waiting for the signal, then closing port and exiting) doesn't do the job.

QuoteReplyEditDelete

 

 

2011-04-11 17:20:22     Re: bfin-elf-ldr returns "bad file descriptor"

Mike Frysinger (UNITED STATES)

Message: 99768   

 

you only need to run `make` in the ldr-utils sub dir to rebuild things and use the local ./ldr binary

 

post the python script that you're running that modifies the serial settings

QuoteReplyEditDelete

 

 

2011-04-11 18:26:20     Re: bfin-elf-ldr returns "bad file descriptor"

Adam Trhon (CZECH REPUBLIC)

Message: 99771   

 

So I tried the sleep() function, it works. So do commenting out the break command when read() in read_retry() returns 0.

 

By the way, without any of these:

 

$ ./ldr --load main.ldr /dev/ttyUSB1

Loading LDR /home/.../main.ldr ... OK!

Opening /dev/ttyUSB1 ... OK!

Configuring terminal I/O ... OK!

Trying to send autobaud ... OK!

Trying to read autobaud ... Failed: Success

 

Is that OK?

 

And as for the python script, I am ataching the whole one as I use it (in the previous post there are only lines manipulating the serial port).

 

vepa-client.py

QuoteReplyEditDelete

 

 

2011-04-11 23:28:13     Re: bfin-elf-ldr returns "bad file descriptor"

Mike Frysinger (UNITED STATES)

Message: 99772   

 

does baudrate of 921600 actually work ?  i dont know of any PC laptop that supports that, and most USB converters dont either.  what hardware exactly are you using ?

 

if you run just the pyserial code before ldr does it fail ?

$ python -c 'import serial;serial.Serial("/dev/ttyS0", 921600, timeout=20);'

$ ./ldr ........

 

things still work for me after doing that.

QuoteReplyEditDelete

 

 

2011-04-12 06:32:14     Re: bfin-elf-ldr returns "bad file descriptor"

Adam Trhon (CZECH REPUBLIC)

Message: 99781   

 

I use FT2232HL and bf523, sclk=120MHz. The baudrate really works, unless both bf523 and FT2232 fake it. The code doesn't work, the svn version of ./ldr is still returning error.

 

Just an idea: due to failure of lock opening, there are no operations with it, so the read() call is performed sooner. There are no data on the port yet, so read() returns 0.

QuoteReplyEditDelete

 

 

2011-04-12 07:02:28     Re: bfin-elf-ldr returns "bad file descriptor"

Adam Trhon (CZECH REPUBLIC)

Message: 99783   

 

The idea is fail. Since SVN version of ldr doesn't use locks, I have two identical logs, one failing, one succeeding. They are attached to the message.

 

ldr.strace.failure

ldr.strace.success

QuoteReplyEditDelete

 

 

2011-04-12 09:33:11     Re: bfin-elf-ldr returns "bad file descriptor"

Adam Trhon (CZECH REPUBLIC)

Message: 99787   

 

This also works for me:

 

ssize_t read_retry(int fd, void *buf, size_t count)

{

        ssize_t ret = 0, temp_ret;

        fd_set fds;

        while (count > 0) {

                /*

                 * clear errno to avoid confusing output with higher layers and

                 * short reads (which aren't technically errors)

                 */

                errno = 0;

                FD_ZERO(&fds);

                FD_SET(fd, &fds);

                temp_ret = select(fd+1, &fds, NULL, &errfds, NULL);

                if (temp_ret == -1) {

                        break;

                }

                temp_ret = read(fd, buf, count);

                if (temp_ret > 0) {

                        ret += temp_ret;

                        buf += temp_ret;

                        count -= temp_ret;

                } else if (temp_ret == 0) {

            //only get there when device unplugged while reading

                        break;

                } else {

                        if (errno == EINTR)

                                continue;

                        ret = -1;

                        break;

                }

        }

        return ret;

}

 

QuoteReplyEditDelete

 

 

2011-04-12 12:50:53     Re: bfin-elf-ldr returns "bad file descriptor"

Mike Frysinger (UNITED STATES)

Message: 99794   

 

the svn verison of ldr-utils does use locks just like every release so far

QuoteReplyEditDelete

 

 

2011-04-12 12:53:12     Re: bfin-elf-ldr returns "bad file descriptor"

Mike Frysinger (UNITED STATES)

Message: 99795   

 

yeah, i'm not putting a select with an infinite timeout in there

 

what if you change the "break;" in the temp_ret==0 check to a "continue;" ?

QuoteReplyEditDelete

 

 

2011-04-12 14:21:21     Re: bfin-elf-ldr returns "bad file descriptor"

Adam Trhon (CZECH REPUBLIC)

Message: 99797   

 

Yes, it works, creating infinite loop if you disconnect the device just before read() reads anything (in this case read() returns 0) and the signal from alarm() in lfd.c:ldr_load_uart doesnt break any of the read() calls.

QuoteReplyEditDelete

 

 

2011-04-12 14:22:36     Re: bfin-elf-ldr returns "bad file descriptor"

Adam Trhon (CZECH REPUBLIC)

Message: 99798   

 

I can't find locks in strace logs, but never mind.

Outcomes