I'm running into a problem with sercomm. oscmocon is unable to write() the CMD after PROMPT1 is received. I've attached a quick python client that checks from PROMPT1 and then sends CMD to confirm that it responds and its not something with the local system (OSX).
Relevant code with some added debugging: static int handle_read(void) { if (!memcmp(buffer, phone_prompt1, sizeof(phone_prompt1))) { printf("Received PROMPT1 from phone, responding with CMD\n"); dnload.print_hdlc = 0; dnload.state = WAITING_PROMPT2; rc = write(dnload.serial_fd.fd, dnload_cmd, sizeof(dnload_cmd)); /* not in src, added for debugging: */ if (rc <= 0) { printf("error writing CMD to serial\n"); exit(1); } ...
$ ./osmocon -m c155 -p /dev/tty.usbserial \ ../../target/firmware/board/compal_e99/hello_world.bin got 1 bytes from modem, data looks like: 1b got 6 bytes from modem, data looks like: f6 02 00 41 01 40 Received PROMPT1 from phone, responding with CMD could not write CMD to serial
Output from python script: (if you try this, be sure to set your serial port and change the python2.5 call on line 1) $ ./compalserialtest.py 115200 got byte(s) from phone: 1b got byte(s) from phone: f6 got byte(s) from phone: 02 got byte(s) from phone: 00 got byte(s) from phone: 41 got byte(s) from phone: 01 recieved PROMPT1 from phone. Writing CMD got byte(s) from phone: 1b got byte(s) from phone: f6 got byte(s) from phone: 02 got byte(s) from phone: 00 got byte(s) from phone: 41 got byte(s) from phone: 02 got byte(s) from phone: 43
On Sunday 14 March 2010 16:04:03 Nathan Fain wrote:
I'm running into a problem with sercomm. oscmocon is unable to write() the CMD after PROMPT1 is received. I've attached a quick python client that checks from PROMPT1 and then sends CMD to confirm that it responds and its not something with the local system (OSX).
Yes, we turn the file descriptor into non blocking mode and then the write might fail as we write too early. A patch to turn this code into to use the write_queue would be totally nice... or at least respond to PROMPT from within a ready write.
regards holger
On Sun, 14 Mar 2010 16:28:42 +0100, Holger Freyther zecke@selfish.org wrote:
On Sunday 14 March 2010 16:04:03 Nathan Fain wrote: Yes, we turn the file descriptor into non blocking mode and then the
write
might fail as we write too early. A patch to turn this code into to use the write_queue would be totally nice... or at least respond to PROMPT from within a ready write.
that is doable and i will see if I can contribute soon (weekends almost over :/ ).
because i was on the python route I went ahead and wrote code all the way through uploading. I was expecting I would get a NACK but instead I get neither a NACK nor ACK but the following response after uploading hello world. Just curious if anyone has ever seen this before:
?BDLENA time negative (%d)
BROWNOUT!1!ssd1783Error: CFI query signature not found %08x size %08x Locking down block at 0x%08x Flash Manufacturer ID: %04x Flash Device ID: %04x Flash Size: 0x%08x bytes Primary Algorithm ID: %04x Primary Extended Query: %04x Alternate Algorithm ID: %04x Alternate Extended Query: %04x Block Erase Typical: %u ms Block Erase Maximum: %u ms Word Program Typical: %u us Word Program Maximum: %u us
baseband-devel@lists.osmocom.org