• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 17 subscribers
  • Views 899 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.

CC2652R: serial bootloader UART interface - No Ack at data transmission

Lucas Wassenius
Intellectual 1515 points

Part Number: CC2652R
Other Parts Discussed in Thread: UNIFLASH, FLASH-PROGRAMMER

Hi,

Helping out on an student project. 

Using the CC2652RSIP with a custom PCB, with the pins brought out for the serial bootloader UART interface. They have compiled and converted the Project Zero from the resource explorer to binary in CCS using the instructions from the manual. They use a standard UART connection through a USB-UART FTDI chip. When programming the SIP they send the following:

Dummy package (got ack)
Baud Sync at 9600B (got ack),
Get status (got ok ack)

send back ack,

erase bank (got ack),
Get status (got ok ack),
send back ack,

send download address: 0, size: size of binary in bytes (got ack),
Get status (got ok ack),
send back ack,

send data, first 252 bytes (got ack),
Get status (got ok ack),
send back ack,

send data, second 252 bytes (got nack),
resend (got nack)

and it continues to give nack if continue to resend,
If they send a get status the process hangs and it stops responding.

What would be the recommended debug route?

Thanks in advance!

KR,

Lucas 

  • 0
    TI__Guru**** 223157 points

    Hi Lucas,

    Please have them refer to SWRA466 and Chapter 10 of the TRM.  Can they provide the exact packets they are sending to communicate with the Bootloader and confirm that they are receiving valid return status commands?  They could consider evaluating the sblAppEx solution with a logic analyzer or oscilloscope to further observe the proper sequence and transactions.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    TI__Intellectual 1515 points

    Hi Ryan, Thanks, 

    The bootloader stops when one of the bytes to program is 0x0a or 0xe6.  He tried programming it whilst removing those bytes and it worked to program the whole binary(minus 600 bytes). He also set the image valid address to all zeroes so it knows where to start, however, the bootloader is still enabled as the rest of the bits of the CCFG are default. But now he cannot get response from the SIP over UART even with the dummy package.

    Kind regards,

    Lucas

  • +1 in reply to Lucas Wassenius
    TI__Guru**** 223157 points

    Those values should not  have any significant impact on the bootloader.  0x0a is similar to 0x55 in terms of bit structure, which should be sent twice to establish communication after calling the bootloader during a reset and detectable bootload pin trigger.  If they cannot get the bootloader to respond any longer then this probably indicates that the CCFG has been corrupted or altered such that the bootloader has been disabled.  They can try to re-program the device with JTAG or, if this feature has been disabled as well, perform a Mass Erase with Flash-Programmer or Uniflash.

    Regards,
    Ryan