CC2642R: FW write fails on reset

Hi Yu !

1. I couldn't find the answer to this. I think the best solution is to either have it to 3.3V or 0V, it should not be a floating pin or using an intermediary value.

2. The reset pin can be asserted for as long as you'd like.

3. For this you can simply set a pin to high in your firmware, which indicates that your firmware is correctly running. This allows you to also run whatever health checks you want to run on your firmware.

4. The swra466e app not mentions a minimum 10ms delay between power-on-reset and the bootloader being active and ready to receive communication. However, a timeout doesn't seem to be specified. I would advise you to use a logic analyzer to see if the communcation looks like what you are expecting when sending the FW after 100ms. For example does the device properly reply with ACK (0xCC) after your commands ? Does it enter into the bootloader at all or does it run your firmware ? You can also send CMD_GET_STATUS commands in between your commands to make sure that the device has not refused them.

Additionally, could you please give me more information on your setup ? Are you using a custom board ? Which SDK version are you using ? What device is sending the bootloader commands ?

Kind regards,
Lea

Dear Lea-san,

I asked Sato-san these questions originally.

Regarding to 1. and 2, I understood. 

Regarding to 3, I think your method is available after FW is written. But, I would like to know the method before FW is written. 

Because writing FW fails.

Regarding to 4, I'll try to check the waveform by oscilloscope first (I don't have logic analyzer).

Best regards,

Yamaguchi

Hi !

About detecting if the chip has woken up properly, you can try attaching a debugger to the chip while it is running. If you're able to attach and read registers, then you know that your chip is awake. Reading the PC address will also allow you to see if you are in the ROM or the Flash.

Kind regards,
Lea

Dear Lea-san,

I don't have debugger. I'll consider to buy it.

By the way, I measured UART waveform when FW was being updated.

CC2642R on my board is connected to CPU by UART (level shifter is used).

And FW update command is input via the CPU. 

Actually, there are 2 type of board. One succeeded in writing FW smoothly (1st time sample).

Another failed to writing FW first, but succeeded in writing FW second time (2nd time sample)

When FW update command was input, CPU on 1st time sample sometimes received CC2642R responces (CPU Rx=blue waveform).

But CPU on 2nd time sample didn't receive CC2642R responses. 

HW design is same. So, I don't know why the result was different.

Is there anything that comes to mind? 

Best regards,

Yamaguchi

Hi !

Just to clarify, when you say that you don't have a debugger, do you mean that the only way you've been flashing firmware into the chip has been through the bootloader backdoor ?

The command input you are sending in the 2nd image seems to be much larger than the one in the first image, especially considering the time scale. Can you zoom in and see what is it that you are sending on your CPU Rx line in both cases ? Because perhaps the data sent is invalid.

I also see spikes on the CPU Tx line in the second image, are those measurement errors ? It looks like the chip does reply to your command input. It may reply with a useful error code, so it would be useful to zoom in right on the command input part.

Kind regards,
Lea

Dear Lea-san,

>>Just to clarify, when you say that you don't have a debugger, do you mean that the only way you've been flashing firmware into the chip has been through >>the bootloader backdoor ?

->Yes.

>>Can you zoom in and see what is it that you are sending on your CPU Rx line in both cases ? Because perhaps the data sent is invalid.

->I re-measured waveform. Please see the attached file : UART_Waveform_Zoom_In.xlsx

>>I also see spikes on the CPU Tx line in the second image, are those measurement errors ? 

->No. Please see the zoom in figure in the attached file. I guess that CPU tried to make connection to CC2642R.

UART_Waveform_Zoom_In.xlsx

Best regards,

Yamaguchi

Hi !

The UART waveform you sent helps a lot to understand the issue.

When you mention that the firmware write works the second time, do you reset the board in between the first and second firmware write ?

One possibility might be that you are entering the Halt-In-Boot state if activity is detected on the TCK pin. Can you make sure that this pin is receiving no activity ? Could you try shorting this pin to the supply voltage to make sure that it is always high ?

The only way to exit the Halt-In-Boot state is to either reset the board, or to have an external emulator connect to the device and first HALT, then RESUME the CPU through DAP, which you can't do because you apparently do not have a debugger. Shorting the pin would disable halt-in-boot and it would make sure that this is not the issue.

Kind regards,
Lea

Dear Lea-san,

>>do you reset the board in between the first and second firmware write ?
->Yes. Before first firmware write, I reset CC2642R.
If first firmware write fails, I reset CC2642R again. Then, I try to write firmware.

>>Can you make sure that this pin is receiving no activity ? Could you try shorting this pin to the supply voltage to make sure that it is always high ?
->Thank you for your advice. I'll try measurement.

By the way, I got logic analyzer result when FW update.

I don't know if this helps, but I'll attach the result : UART_logical_report.xlsx

UART_logical_report.xlsx

Best regards,
Yamaguchi

Dear Lea-san,

I measured TCK waveform when FW update.
I measured two cases. One was that TCK was not short-circuited to supply voltage (default),
another was that TCK was short-circuited to supply voltage.
In former case, TCK was changed to Low when CC2642R's reset pin was changed to Low (both of 1st and 2nd samples).
In latter case, TCK was always High even though CC2642 was reset (both of 1st and 2nd samples).
However, first FW writing failed on 2nd sample in both of former and latter cases.
I'll attach my measurement result : UART_Waveform_with_TCK.xlsx
Please see it.

Best regards,

Yamaguchi
UART_Waveform_with_TCK.xlsx

Dear Lea-san,

Did you find anything out from my measurement result?

Best regards,

Yamaguchi

Hi !

Sorry for the late reply. A difference I notice between your two samples is that in the 2nd sample you send the firmware update command about 50ms after the reset pin is put to high, while in the 1st sample you wait about 250ms. Have you tried waiting a longer period (like 250ms) for the 2nd sample ?

It's surprising to me that the issue always happens on one chip and never happens on another chip. What exactly do you mean by 1st and 2nd sample ? Did you order these chips are 2 different times ? Is the revision or the inscriptions/text on the chip the same ?

Kind regards,
Lea

Dear Lea-san,

Basically, I used "usleep 10000" command (wait 10ms) before FW writing command.
I changed the command from 10000 to 250000 (wait 250ms), but 2nd sample behavior was not changed.
I'll attached the result : UART_Waveform_250ms_Wait_before_FW_Writing_Command.xlsx

>>What exactly do you mean by 1st and 2nd sample ? 

->1st sample means EVT sample and 2nd sample means DVT sample.

    But CC2642 circuit is same (for availability, only resister and MOSFET for level shifter were changed)

 >>Did you order these chips are 2 different times ? Is the revision or the inscriptions/text on the chip the same ?

->Yes. CC2642R on each sample was ordered different time. The incription on the chip is different.

     The incription on the each chip is shown in the attached file.

Best regards,

Yamaguchi

UART_Waveform_250ms_Wait_before_FW_Writing_Command.xlsx

Hi !

Could you two to maybe swap the CC2642R chip from a EVT sample board and a DVT sample board ?

If the issue still happens on the DVT sample and still does not happen on the EVT board after the swap, then the issue is likely in your board revision, and we would need to see the files for the two board to check for any difference that could cause an issue.

Kind regards,
Lea

Dear Lea-san,

I'll try to swap CC2642R on EVT and that on DVT.

By the way, when I reset CC2642R, CPU's Rx (= CC2642R's Tx) UART waveform was different between EVT and DVT.
On EVT board, CPU's Rx kept high when CC2642R's reset pin changed from High to Low, and from Low to High.
However on DVT board, CPU's Rx changed from High to Low when CC2642R's reset pin changed from High to Low,
and CPU's Rx kept Low even though CC2642R's reset pin changed from Low to High.
I'll attach the measurement result.
Please see the attached file : UART_Waveform_when_Reset.xlsx

Do you know which CPU's Rx(=CC2642R's Tx) behavior is correct, EVT or DVT?
The simple block diagram is shown in the attached file.

Best regards,
Yamaguchi
UART_Waveform_when_Reset.xlsx

Hi !

Just by looking at it I'm not sure which one is the correct one. My intuition would be to say EVT board is correct, but just to be sure I will run a firmware update on a CC2642R on my side and use a logic analyser on the UART lines to tell you what it should look like.

Keep me updated on the chip swapping :)

Kind regards,
Lea

Dear Lea-san,

Although I swapped CC2642R on EVT and DVT, the behavior of EVT and DVT were not changed.

Lea said:

I will run a firmware update on a CC2642R on my side and use a logic analyser on the UART lines to tell you what it should look like.

->Thank you. I'll wait for your update.

Best regards,

Yamaguchi

Dear Lea-san,

I got new information.

When we swapped level shifter IC (SN74AVC2T245RSWR) for UART Tx/Rx on EVT and that on DVT, 

the behavior of EVT and DVT was also swapped.

Best regards,

Yamaguchi

Hi !

Did you make any change to the level shifter IC between the DVT and EVT ? I think this is the root cause of the issue, and that we should figure out the difference between the DVT and EVT that leads to the issue. Is there any chance that you could share the schematics for the DVT and the EVT with us so we can try to give an explanation on why this level shifter IC changes the behavior of your firmware updates ?

This is a public forum so I do not advise you to send the files here. What you can do is add me as friends on E2E by clicking on my profile, and then sending me a private message.

Kind regards,
Lea

Dear Lea-san,

>>Did you make any change to the level shifter IC between the DVT and EVT ? 

->No. The schematic and level shifter IC ((SN74AVC2T245RSWR) is same.

    I compared device marking on level shifter IC on EVT and DVT.

    EVT : TQO

    DVT : TQV 

    The marking was different, but both marking was shown in the datasheet of level shifter IC.

>>What you can do is add me as friends on E2E by clicking on my profile, and then sending me a private message.

->I sent private message to you. Please check.

Best regards,

Yamaguchi