CC2640: temperature problem

Hello,

Thank you for reaching out to us. I have a few questions that will help us resolve this in an efficient manner. Can you provide the temperature ranges in which this behavior occurs? According to the datasheet for the CC2640, the device is intended to operate in an environment in which the temperate is between -40C and 150C. Does this behavior occur at any negative temperature? Is the behavior consistent? Are you using a custom design or is this behavior observable on an evaluation board? If you are using a custom design, have you had your design reviewed via SIMPLELINK-2-4GHZ-DESIGN-REVIEWS?

Best Regards,

Jan

Jan said:

Can you provide the temperature ranges in which this behavior occurs?

Range from about -5 and below, degrees Celsius

Jan said:

Does this behavior occur at any negative temperature? Is the behavior consistent?

when the temperature drops below -10 degrees, it becomes noticeable.
Reboot happens randomly

Jan said:

Are you using a custom design or is this behavior observable on an evaluation board?

Own design is used, no validation was performed on the debug board.

Jan said:

If you are using a custom design, have you had your design reviewed via SIMPLELINK-2-4GHZ-DESIGN-REVIEWS?

no, such a check was not carried out

-----------------------------------------------------------

It was also noticed that when updating "over the air" through the OAD starter, the program is updated. But at a negative temperature, it does not start, although the update takes place in a warm room and the program starts

thanks for the answer, I look forward to your recommendations

Hi,

Thank you for the prompt response. I have a few follow up questions and a debug suggestion that may provide further insight.

What reference design was used when designing the custom board? Does this occur with any firmware, only with firmware that is updated via OAD, or your own custom firmware? For example, is this behavior visible when using an unmodified simple_peripheral?

As a test, can you flash the firmware in which the behavior is observed on a debug board and run the temperature test? This will help us further isolate what might be causing this behavior.

I would also recommend submitting a design review request to the link provided earlier. Please reference this thread for better tracking, if a request for a design review is submitted.

Best Regards,

Jan

Jan said:

I would also recommend submitting a design review request to the link provided earlier. Please reference this thread for better tracking, if a request for a design review is submitted.

Yes, now I have sent an email with all the files and a questionnaire to 24ghz-hw-review@list.ti.com

I will answer the rest of the questions today .. how will I conduct tests according to your recommendations

Hi,

I would suggest running the same test that was ran on your custom board to recreate the issue on a dev board. I look forward to your response.

Best Regards,

Jan

do you mean to LAUNCHXL-CC2640R2?

Hi,

To clarify, are you using the CC2640 or the CC2640R2? If you are using the CC2640R2, then the appropriate dev board would be the LAUNCHXL-CC2640R2. 

Best Regards,

Jan

Jan said:

What reference design was used when designing the custom board

reference design taken from here https://www.ti.com/lit/zip/swrc335

Jan said:

Does this occur with any firmware, only with firmware that is updated via OAD, or your own custom firmware? For example, is this behavior visible when using an unmodified simple_peripheral?

At -15 degrees replaced their OAD program with an example
simple_peripheral_cc2640r2lp_oad_offchip_app_FlashROM_unsecure.bin. the same thing, the program worked only in a warm room.

Jan said:

To clarify, are you using the CC2640 or the CC2640R2? If you are using the CC2640R2, then the appropriate dev board would be the LAUNCHXL-CC2640R2. 

It will take some time to transfer our project to LaunchPad (we use other PIN codes) СС2640R2

Hi,

Got it. Thank you for the clarification with regards to the IC. The ideal dev board to use to run the test would be the LAUNCHXL-CC2640R2. Thank you for verifying that the behavior can be observed with an unmodified OAD example. Can you verify if the behavior also occurs with a non-OAD example on your custom board? The non-OAD simple_peripheral would be a good example to verify with. 

Best Regards,

Jan

a custom board reprograms simple_peripherals via a wire?

Hi,

I am glad to hear you were able to resolve the issue! Thank you for sharing the solution with us. This will help the community in case anybody runs into a similar issue.

Best Regards,

Jan

but we did not solve the problem that was originally, constant reboot on cold

how can you find out the reason for the restart? simple_peripheral works stably!

Hi,

My apologies. I misunderstood. I thought you meant that the original firmware worked with the new battery. To make sure I am understanding everything correctly, is the following correct?

1. Custom board with custom FW reboots randomly in sub-zero temperatures

2. Custom board with simple_peripheral OAD works perfectly in sub-zero temperatures.

Are you able to run the the two tests above with a LAUNCHXL-CC2640R2?

Best Regards,

Jan

Yes, you understood correctly! what test should be done? maybe the problem is in the code, but I don't see any errors

Hi,

It is possible that the error is in the code. Running the two test with the LAUNCHXL-CC2640R2 will help isolate the cause. The two test that I believe will be helpful are the following:

1. Flash your custom FW on a LAUNCHXL-CC2640R2 and place in sub-zero temperature

2. Flash simple_peripheral OAD on a LAUNCHXL-CC2640R2 and place in sub-zero temperature.

If we see the same results as we saw with your custom board, then this points to a software issue. If we see different results, then this may be a hardware problem as well.

Best Regards,

Jan

Thank you. if this is a problem in the code, can you somehow trace the reason for the reboot?

After reboot at -15 degrees, the AON_SYSCTL: RESETCTL register changed
its meaning
0x3AF2 (Reset pin) to 0x3AF4 (VDDS failure detection)

Hi,

With regards to tracing the problem in the code, I would highly suggest referring to the Debugging chapter (BLE / BLE5). Another test that may be helpful to run (besides the LAUNCHXL tests mentioned in my last reply), would be to replace the battery with a DC power supply to eliminate the battery as a variable.

Best Regards,

Jan

maybe with a small consumption, we have 130 uA .. dc-dc is not stable. and should we try LDO?

Is there any recommendation as to which converter is best to use when?

Hi,

Were you able to try using a DC power supply to power the board? Did the board function as expected when using the power supply?

Best Regards,

Jan

Hi

external power supply with regulation .. And changed the voltage from 3v to 3.6v. the effect was the same (3v works fine, 3.6v restarts).

Hi,

Thank you for the confirmation. Did you use a custom board for this test or the LAUNCHXL-CC2640R2? If the issue is present on the LAUNCHXL-CC2640R2, then this points to a software issue. However, if the issue is present only on the custom board, then there may be a hardware design issue present.

Best Regards,

Jan

how do you predict that the temperature can affect the error in the program, that is, at + temperature everything is stable, and at - it reboots

Hi,

If the issue occurs when using your custom firmware on a LaunchPad powered via a DC power supply or via the USB cable, then I believe the behavior may be software related. If the issue does not occur, then it would point to a hardware design concern. By running the test, we would be able to isolate the possible cause and aid in debugging.

Can you try using the LAUNCHXL-CC2640R2 with your custom firmware to see if the behavior is still observed?

Best Regards,

Jan