CC2642R: Bluetooth forum

As a point of clarification HIB stands for Halt-In-Boot, not hibernate.

1. How are you assuring that there are 8 rising and 8 falling edges? Has this been confirmed with an oscilloscope capture? Are you confident there is no noise or errant pulses that haven’t been accounted for?
2. You may short TCK to VCC to assure that it is always pulled up and that no errant pulses will wake up the debug circuitry and issue a Halt-in-boot (HIB) flag
3. Software would work but you would no longer be able to program or debug the device through the JTAG interface as the TCK pin would be disabled. You would then need to rely on the bootloader
4. I don’t understand the question
5. I don’t understand the question
6. If you are only trying to disable TCK then no other configuration is required
7. I suppose there are many cases that could cause software not to execute. Invalid hardware configurations such as a missing external crystal or incorrect power. Entering the bootloader backdoor. Invalid CCFG or and invalid SW image. I’m not really sure how to answer the question without understanding the particular issue or the context for the question
8. When the HIB flag is set the bootloader waits for the external emulator to take control. This is by design. See section 6.6 from the technical reference manual
9. Interfering with the clock will result in a reset if the clock loss detection feature is enabled. The AON_PMCTL:RESETCTL.RESET_SRC register shows clock loss as the source of reset in this case. If clock loss detection isn’t enabled, though I haven’t really run this kind of test, but if you are continuously and randomly interfering with the clock at different points in boot and code execution I suppose it’s feasible that you could get the system into an indeterminant state which would require a reset to resolve.
10. Power measurements will be higher due to the debug circuit being active as well as not being able to enter standby. Is this being evaluated on a LaunchPad or only the custom hardware? This still seems a little higher than I would expect but it’s hard to know without details on the system.

BR,

Jake

Hi, thank you for your reply. I still have the following questions:
1. Why does the program stop running when we press the 32.768K crystal oscillator for a long time, regardless of whether the crystal source is LF_XOSC or not?
2. When we press the crystal oscillator to reproduce the fault, the current stabilizes at around 90uA. This doesn't seem like a random fault state but a stable one. Could you help determine what state it is?
3. We used both static electricity and finger pressing on the crystal oscillator to reproduce the fault. After the fault occurred, we measured the voltage of the chip's pins and compared it with the normal state. We believe that the fault reproduced by static electricity occurs in HIB mode, while the fault reproduced by pressing the crystal oscillator occurs after the application program successfully configures the pins. Is this conclusion correct? Can you provide more information?
4. How can we prevent the program from entering the fault state so easily when pressing the crystal oscillator with a finger?
5. Finally, we would like to confirm whether disabling TCK using HWREG(AON_IOC_BASE + AON_IOC_O_TCKCTL) = 0x0 is effective in avoiding entering HIB mode without using an external pull-up on VCC? At which point in the program is it reasonable to disable it?E:\CHANG_AN_AWT\TI资料\E12钥匙静电袭击与按压晶振芯片引脚状态.xlsx

E:\CHANG_AN_AWT\TI资料\E12钥匙静电袭击与按压晶振芯片引脚状态.xlsx 

hi, add this table

Hello,

1. When you say whether the crystal source is LF_XOSC or not, do you mean whether you’re using LFOSC (internal RC oscillator) versus the external crystal or otherwise referenced from the 48MHz clock? I suppose this would depend on the configuration and if clock loss detection is enabled. See section 7.5.1.1 of the technical reference manual for the various clocking options for the device.
2. Looking at your table it in the post below it looks like both DCDC (pin 33) and DCOUPL (pin 23) are at 0V when the current draw is 90uA. This implies that the system is not in reset and may be in an indeterminate state and that the internal voltage regulators are not working. The 90uA could be drawn because the system was forced into this invalid state and something is active but I don't think it would be possible to determine exactly what is drawing the current.
3. If the system is in HIB mode then you could attempt to follow the procedure in 6.6 of the technical reference manual to exit HIB. If you can halt and resume the CPU and it resumes your program execution then I think your conclusion is correct regarding HIB. As noted above in (2) the 90uA state seems to be and invalid state.
4. It is not recommended to be actively probing, touching, or otherwise interfering with the clock signals while the device is active. What is the use case for touching and pressing on the crystal? This should not be done.
5. You can do this but then all debugging would be completely disabled. The TI recommendation as per the technical reference manual (section 6.4, paragraph 4) is to only disable this pin when HIB has not been set by reading FLASH:FWFLAG[2]. However if you think that noise on the TCK pin is causing you to enter HIB unintentionally then this may be necessary if the noise cannot be avoided either by adding pull resistors or blocking contact to these pins.

BR,

Jake