CC2340R5: Receive unexpected response on bootloader

Hi YuWen,

The CC2340 bootloader CMD_DOWNLOAD cmd id is 0x26, please refer to Technical Reference Manual section "8.5.3 ROM Serial Bootloader Commands".

The cmd id 0x21 is CMD_GET_STATUS.

(Note there are differences in ROM Bootloader between CC26xx and CC23xx).

Thanks,
Toby

Dear Sir,

Thanks for providing the information.

Is it possible for us to modify the codes of bootloader? or where can we check the exact code flow of CC2340 bootloader?

Thanks.

BR,

YuWen

No, it is not possible since the bootloader is in ROM (read only memory).

Although we do not provide source code for ROM, the bootloader functionality is detailed in the TRM (Technical Reference Manual).

It is good you already have a way to interface with it, so please follow the command details in the TRM to achieve FW download.
Specifically, this section: "8.5.4 Bootloader Firmware Update Example".

Dear Sir,

While reviewing the process of bootloader, we found something weird:

According to the TRM p470, we saw below procedure:

We initially expected to receive ACK/NACK after we sent BLDR_CMD_GET_STATUS.

However, after we sent BLDR_CMD_GET_STATUS, we received 0x03 0x40 0x40, which seemed to be the BLDR_CMD_RET_SUCCESS value.

We thought there might be something missing.

1. Could you help us clarify if this was expected behavior of bootloader or was it incorrect?

2. Plus, we see this description:

The transmitter is allowed to send zeros until a nonzero response is received, which is necessary for SPI and is allowed by the UART. The receiver is allowed to return zeros until it is ready to ACK or NACK the packet that is being sent. Neither device transfers a nonzero byte until it has received a response after transmitting a packet.

Does this mean each 0x00 we receive after sending any CMD can be ignored?

Thanks.

BR,

YuWen

ACK is returned after every command.
Then you use BLDR_CMD_GET_STATUS after you receive the ACK, to check the status of the previous command.

YW Lin said:

Plus, we see this description:

The transmitter is allowed to send zeros until a nonzero response is received, which is necessary for SPI and is allowed by the UART. The receiver is allowed to return zeros until it is ready to ACK or NACK the packet that is being sent. Neither device transfers a nonzero byte until it has received a response after transmitting a packet.

Does this mean each 0x00 we receive after sending any CMD can be ignored?

Yes, based on this, the SPI host may ignore those zero bytes.

Dear Sir,

ACK is returned after every command.
Then you use BLDR_CMD_GET_STATUS after you receive the ACK, to check the status of the previous command.

-> I'm still a bit confused.

We expected to see another ACK/NACK after sending BLDR_CMD_GET_STATUS.

But we didn't get any ACK/NACK for BLDR_CMD_GET_STATUS.

We directly get something other than ACK/NACK.

We thought this was incorrect.

Could you explain why was this happening?

Thanks.

BR,

YuWen

Yes, you should be receiving an ACK/NACK after every command... Can you confirm the CMD ID you are sending for BLDR_CMD_GET_STATUS? Is it 0x21?

What value do you see from the device after sending BLDR_CMD_GET_STATUS?

Can you provide logic analyzer shot of the communication wires when the issue happens? Include a few commands also just before the issue happens.

Dear Sir,

1. Can you confirm the CMD ID you are sending for BLDR_CMD_GET_STATUS? Is it 0x21?
-> Yes, we have confirmed that we were sending exactly 0x21.

2. What value do you see from the device after sending BLDR_CMD_GET_STATUS?
-> We met two conditions:

a) We directly received 0x03 0x40 0x40 without 0xCC or 0x33 before them.

b) We received 0xCC / 0x33 and waited for a long time, but didn't get any other bytes after the ACK / NACK.

None of the conditions above is correct based in the TRM.

Please help to clarify how we can figure out the issue.

Thanks for sharing more details of your investigation.

I will look into and provide an update within 3 business days.

Is this a custom board? Or launchpad?