Fails at first time about cc2538-bsl HOT 18 CLOSED

Hi @dazhbog, thanks for submitting this issue.

I'm presuming you're using the latest version of the script (you can check with --version), since I fixed a problem with the upload failing due to an unflushed serial port in the past (but you mentioned you've tested this).

Is there a specific reason why you're forcing the serial speed? The Synch command (0x55 0x55) is the first sequence the script sends and the chip determines the communication speed depending on this sequence of bits. (after that first 'slow' init, it switches to a higher speed and can do a much faster upload)

I'm suspecting a problem with the chip not properly receiving that first Synch command and thus not being able to determine the baud rate for the answer.

What hardware are you using?
Can you try without forcing the baud rate?
Can you try manually sending the synch sequence (at a speed <500000 baud) and see if you get an ACK back from the chip (on the first try)?

from cc2538-bsl.

Hi @JelmerT , I just quickly tried a few things.

I updated the py script to the latest one, still the same issue.

The reason I force the speed down to 115200 is that anything above does not work reliably or at all.

My hardware is an FTDI chip and the CC2538SF53.

When I manually send a 0x55 0x55 I get back 0x00 0xCC at 115200 and 500000 (interesting).

Let me know if you want me to test anything else.

from cc2538-bsl.

Ok so ive been playing more and more with the program. I put a serial sniffer in between and I can see the traffic. In both cases the micro seems to be responding with 0x00 0xCC.

Then I edited the code and put some prints around.

def _wait_for_ack(self, info="", timeout=0):
        print(self.sp.inWaiting())

        stop = time.time() + timeout
        got = None
        while not got:
            got = self._read(2)
            if time.time() > stop:
                break

        print(self.sp.inWaiting())

To my surprise I get
0
32 (a variable number)

So I try printing out the array after your read routine and I get

def _wait_for_ack(self, info="", timeout=0):
        print(self.sp.inWaiting())
        stop = time.time() + timeout
        got = None
        while not got:
            got = self._read(2)
            if time.time() > stop:
                break
        print(self._read(self.sp.inWaiting()))

The result
0
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 204]
So the 0xCC is in there, but what are all those zeros?

I shall investigate more :-)

from cc2538-bsl.

The 0x00 0xCC is the ACK, so that's indeed what you're looking for.

It still sounds to me like synchronisation problems (the chip responding at a different rate / too late). Can you try making the serial lines between the ftdi chip and the and CC2538 as short as possible (if you are using wires), and increasing the timeout value?

timeout=0.5             # set a timeout value, None for waiting forever

from cc2538-bsl.

@dazhbog did you get this fixed eventually?

from cc2538-bsl.

I have exactly the same problem, @dazhbog . Did you find a solution?
I noticed that if I tune down the speed to 38400 or less, then it always works.

from cc2538-bsl.

@davidrojas did you try increasing the timeout value?

from cc2538-bsl.

Yes, I already tried that, makes no difference.

from cc2538-bsl.

@davidrojas what hardware are you using?

from cc2538-bsl.

A custom board with an ftdi chip FT232RQ

from cc2538-bsl.

Sorry for the late reply, I made another, custom board with very short traces and a different FTDI chip and now i can take the baud rate up to 500000. I still have to manually bring the board into the bootloader mode though..

from cc2538-bsl.

Using the auto bootloader start feature only works if your hardware supports it (RTS and DTR should be connected to the chip).
There might be some other issues with it too, for more info have a look at #27

from cc2538-bsl.

I've done some tests, and this behaviour is somewhat erratic. I noticed it is dependant on the actual binary that you uploaded before, but I don't know exactly what it is. If some peripheral is activated/deactivated, low power mode, etc. in the previous firmware, it always takes two attempts to flash (bootloader always comes up alright everytime, you can check because the LEDs are half-way on). Then if I try a different code, it flashes first time always. We could start with a hello world and then add timers, putting it in LPM1/2, etc. until we see when it starts failing at first time.

from cc2538-bsl.

I too have been in a situation where synch fails after a reset and I have to reset again. This happens on occasion, not always. I've not double checked whether the cause is the same as what is being discussed here, but will do.

Perform the following steps to successfully receive a packet:

1. Waiting for the device to return non-zero data is important because the device can send zero bytes between a sent and received data packet. The first nonzero byte received is the size of the packet being received.

Could it be that we simply need to wait for the first non-zero while waiting for an ACK/NACK rather than hard-coding a two-byte read?

from cc2538-bsl.

I think we need to re-open this.

I now have a theory: When the running firmware sends stuff out of the UART, these things get somehow buffered (on some FTDI on the board? somewhere in the driver or line discipline?). The first N bytes read after sending the synch sequence are exactly those bytes. The reason we see them as zeros is because we open the port at a different baud rate than the one those chars were sent at. In fact, if we force -b {115200 , 230400 , 460800} we may get non-zeros. It looks like we must first send something to the device before those bytes start streaming down our line, which is why (I assume) flushInput() doesn't seem enough to prevent this.

Since we cannot rely on them to be all zeros, I can only think of changing _wait_for_ack to reading from the line byte-byte byte and check the last two bytes for the ACK/NACK sequence. This needs a non-zero timeout. Something like:

    def _wait_for_ack(self, info = "", timeout = 1):
        stop = time.time() + timeout
        got = bytearray(2)
        while got[-2] != 00 or got[-1] not in (0xCC, 0x33):
            got += self._read(1)
            if time.time() > stop:
                break

        mdebug(10, "0x%02x: 0x%s" % (len(got), " ".join("%02X" % x for x in got)))

        # wait for ask
        ask = got[-1]

        if ask == 0xCC:
            # ACK
            return 1
        elif ask == 0x33:
            # NACK
            mdebug(10, "Target replied with a NACK during %s" % info)
            return 0

        # Unknown response
        mdebug(10, "Unrecognised response 0x%x to %s" % (ask, info))
        return 0

from cc2538-bsl.

I'm also noticing some failed first-attempts. I always assumed it was because I didn't properly (manually) start the boot loader. But now that I'm looking closer at the problem, I'm indeed also sometimes getting a bunch of zeroes, but also sometimes non-zero junk values.

I indeed thought flushInput() fixed all this in 34d4345, but apparently the chip / driver has a second buffer that dumps in the last buffer when emptied.

The problem sounds a lot like this one: https://groups.google.com/forum/#!topic/linux.kernel/kCExd47w9HI (From '07). So it might have something to do with a double buffer in the cdc-acm driver. (I'm seeing the problem on OSX)

So a quick fix might be to call flushInput() multiple times. Your solution seems a bit cleaner though, and it takes into account the possible zero bytes before a useful packet.

I'll try both and report back.

from cc2538-bsl.

I had a bit of a eureka moment to try and close the port manually before script exit. Shouldn't make any difference in theory but I'll give it a stab later!

from cc2538-bsl.

Testing on OS X here as well. cmd.close() doesn't make any difference. Behaviour consistent with Zolertia RE-Mote (some FTDI, FT2232 I think) and SmartRF + CC2650EM

from cc2538-bsl.