CCS/CC1352P: CCS

Hi, 

1. These devices support 4-wire JTAG, which is the only mode the XDS100v2 supports. If you need 2-wire cJTAG, you will have to use either the TMDSEMU110-U  or a XDS100v3 - some models are shown at the XDS100 page:

https://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_xds100.html  

2. I am not sure what you mean by "project about the bootloader", but to program these devices via its internal SBL you can use the Uniflash. 

Hope this helps,

Rafael

Hi Rafael,

thanks your reply.

1. for the first question, if i use 4-wire JTAG, so XDS100v2 support to program these devices ,right?

2. does Jlink support to read and program these device. i have a test ,the jlink can connect to the device, which mean it can recongnize the device, but can not read. and if i erase the device for the first time , then the device can not be connected anymore. so how could this happen.

3. you have mentioned Uniflash, this is a software. So should i use it work with a tool like XDS100v2 ? we have soldring the chip into our borad , we don't have TI official EVM borad. in our board we intend to use  a SPI interface or 4-wire Jtag for program. we don't keep the UART .

Hi,

1. Yes.

2. I am not sure what may be going on in your case - Jlink sometimes does not fully support the flash operations on the device. I would validate the connections and everything else with the XDS100v2 you already have. 

3. Yes, Uniflash is a programmer software that is able to use the SBL via UART. Since that does not seem to be your case, I would use the 4-wire JTAG instead. 

Regards,

Rafael

Hi Rafael,

The 4-JTAG can work to program the chip in our boards.  now there's another question.

in our design that the SPI interface is for updating the firmware. for these device include a simple, ROM-based bootloader that can communicate with an external device over the SPI or Uart. we now only have SPI.

The communication protocol is described in the datasheet. see in the red rectangle. but in our test, we found that the packet from the chip don't contain the first byte which mean the size of the packet. e.g we read 6 bytes from a chip, and we save the waves in the last picture. the wave shows that there's no size byte, but the other bytes in the packets are right.

and we also have try some other command, and the response packet don't have the size byte. 

so could you help us to confirm that should the manual to be update or there's something wrong with the chip in our hand.

thanks a lot

Hi,

Thanks for the reply. 

I am not well versed on the SBL of the CC13x2 devices, but I can see the device responded with an ACK after the sequence of bytes was transferred, indicating the packet was complete and therefore I suspect the data capture may not be showing the entire story.

Perhaps the logic analyzer is missing a prior transition which is failing to trigger the start of the data capture? Also, if subsequent data transfers are correct, this may confirm the data capture issue with the very first packet. 

At any rate, I will redirect this to the device experts as they may have additional insights that I am missing. 

Hope this helps,

Rafael

Hi Rafael,

thanks your reply.

we can communicate to the SBL of these device well if we suppose that the response don't have the first byte size. so we don't think the logic analyzer miss the start capture.

if you redirect this to the device experts and get some new information, please let me know. i'll be appreciate you a lot.

thanks.