• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 56 subscribers
  • Views 436 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2630: ROM bootloader sometimes not ACK-ing Baud Rate automatic detection

Liviu Cristian Berceanu
Intellectual 460 points
Part Number: CC2630


We are running our CC2630 based design with the Bootloader backdoor functionality enabled. This is connected to the PC through an FTDI based cable.

In a normal situation, the PC software would initialize communication by "ping"-ing the microcontroller with a sequence of three bytes 0x03, 0x00, 0x00 which the micro correctly ignores (as no baud rate detection has been performed yet). Next, after waiting about 450ms, the PC sends the necessary sequence of 0x55, 0x55 (two bytes) for automatic baud rate detection. The microcontroller ACKs this by the regular 0x00, 0xCC sequence and then the PC knows the micro is alive and well and starts asking for ID and a lot of other stuff.

However, we have some situations when the microcontroller does not ACK the automatic baud rate detection. This does not always happen, but when it does happen it is always after a fresh power-up.

In such cases, the PC pings with 0x03, 0x00, 0x00, waits 450ms, then sends 0x55,0x55. The microcontroller ignores this and the PC application stops, and sends a message that it cannot communicate with the microcontroller. If we then run the PC application again (without powering-cycling or resetting the micro), the PC pings with 0x03,0x00,0x00 and the micro (surprisingly) ACKs this with the 0x00,0xCC sequence. I suppose this is an indication that the previous automatic baud rate detection attempt during the previous run of the PC application was successful, but the micro just dd not ACK it at the time. Anyway, on this second run the PC is perfectly happy receiving this ACK to its initial ping, it skips the 0x55, 0x55 sequence (as it is not needed anymore) and continues successfully asking for ID and for the rest of the communication.

Any idea what could be causing this behavior? I have monitored the waveforms on VDDS, VDDR, RESET and DIO2 (which is our BL_PIN_NO) and they look identical in the cases when this situation occurs and in the cases when the communication works from the first attempt after power up.

Best regards,

Cristian

  • 0
    TI__Guru**** 219957 points
    Hi Cristian,

    Can you please provide waveform screenshots to further emphasize your point? How long of a delay is there between MCU power-up and PC action and does changing this delay make any difference in behavior?

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 460 points

    Hello,

    It does not matter how long we delay PC action from MCU power-up. It can be many seconds and this scenario which I have described before still occasionally happends. And I am not sure what is making the MCU behave this way. I can see no practical difference of the power-up waveforms in-between a working sequence and a non-working sequence. I have included below both screenshots of the Logic Analyzer captures of the UART communication and scope plots of the power-up waveforms (for both a working sequence and a non-working sequence).

    DIO2 is our BL_PIN_NO and it steadily drops to about 2.9V after the initial swing to VDDS due to the effect of the oscilloscope input impedance (combined with a 1Meg external pull-up to VDDS on that pin). We also have an external 1Meg pull-up on the UART_RX pin.

  • 0 in reply to Liviu Cristian Berceanu
    Intellectual 460 points

    I did some more investigations today, it seems that about 500ms after power-up, the FTDI cable decides to throw some garbage on the UART_RX line (note UART_RX means the RX line of the micro). This occurs prior to the launch of the PC software (we cannot launch the PC software earlier than that, as we need to manually interact with the keyboard to launch it).

    Strange enough, it seems the garbage consists of several half-way pulses in the working scenario, and just a single half-way pulse in the non-working scenario. And the relation between these pulses and the normal/abnormal behavior of the micro is quite deterministic (meaning that always when we get the several garbage pulse the micro performs the normal expected sequence, ACKs the 0x55 0x55 sequence from the first attempt; and always when we get the single garbage pulse the micro requires the second run of the PC software to ACK). UART_RX is the purple trace in the scope plots below.

    I am a bit puzzled now, because these several pulses of garbage should be worse, yet it seems to make the micro behave as normal...

         

  • 0 in reply to Liviu Cristian Berceanu
    TI__Guru**** 219957 points
    Hello Cristian,

    Perhaps this garbage on the UART_RX line interferes with the communication establishment, in which case some dummy bytes must be sent to reset the interface in some way. Would there be any harm in sending dummy data by default to work around the issue? I am trying to loop in the Hardware Team to further comment.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 460 points

    Hi Ryan,

    Thank you for your message. In fairness, I believe it is time to close this thread, without any further debates. It is clear it is not something wrong within the microcontroller, and that this behavior is really cause by the UART_RX signal garbage.

    It is not even the FTDI cable generating this, as I stated before, but some piece of supposedly "perfect" circuitry (which we inherited) between the FTDI cable and the UART lines of the microcontroller itself the purpose of which is to provide some sort of "isolation" between FTDI and micro. Anyway, this circuit is far from perfect, it actually uses some by the book "don't do"-s (like for instance using an opamp as a comparator, which sometimes works but in this case doesn't; or like ignoring the specified power-up sequence for some bidirectional buffers). So it is up to us to either change this circuit or accept the necessary re-run of the PC application (and be thankful that this at least works!).

    Best regards,

    Cristian