CCS/CC1352P: Configurable Hart fault Instruction access violation before code execution

Hi Matthias,

Is there any code you can show us that is running on the device?

Dear Severin,

I have no minimum working example, there is no code running on the device. The code I want to run is an empty main method, which doesn't work with either RTOS or NoRTOS. The fault appears before the jump into the main method.

Thanks,

Matthias

Hi Mattas,

It seem you can at least connect the debugger and download the software, which is nice.

When connected, can you perform a system reset (the small IC icon in CCS when in debugging mode) and try to step the disassembly step by step? It sounds to me that there might be some setup which makes your code fail before going into main. I would not suspect the HF clock for now.

How have you configured the CCFG in your case?

Dear TI,

Thanks for your expertise. 

This is the instruction which causes the fault:

And this is the CCFG Register:

Thanks in advance,

Matthias

Hi Matthias,

"SetupTrimDevice" is expected during the booting of the chip (you could also select "locate file..." and navigate to the driverlib folder in the SDK to get some context: <SDK>/source/ti/devices/<device>/driverlib).

What happens now if you step-by-step from this point, where do you run into the error state?

Hello,

It seems to jump to the ISR from different calls somewhere in the setup, run-dependent.
Mostly it is caused by  calling NOROM_SetupAfterColdResetWakeupFromShutDownCfg  - 2 and 3  in setup.c.

or in the following call:

or sometimes it fails in recognising the HW version: 

Thanks,


Matthias

There you go, that is your issue :)

Do you by any chance use pre-production ICs on your board? 

Thanks,

As i mentioned the error with the HW version only occurs sometimes. I don't think I have pre-production IC's. 
TI sent them (CC1352P1F3RGZR) to me last month. Is there something specific on the the markings I can have a look at?

Thanks,

Matthias

The easiest way to check this is to check the revision marking (either on the reel/tape you got from TI or on the IC). You would expect to have revision "E". You can also use for example Flash Programmer 2 to check the revision of the IC it detects.

The IC has the following marking: 

CC1352
P1F3
TI 91J E
P90E G4

So this seems to be Revision E.

Do you have another idea for the fault?

Thanks,

Matthias

Hi Matthias,

Which SDK are you using? Assuming you are on the latest SDK etc, then I would check your HW for errors connected to the IC.

For example, take the board that measure the impedance of all the pins against GND and see how this compare with for example a launchpad. Especially interesting is the pins that is not pure IO functionality. 

Hello,

Thanks for your advice.

Due to the situation I cannot get in the lab now.

Please confirm that a not connected Crystal could be the reason for the problem.

Thanks,

Matthias

Hi Matthias,

The HF crystal is not used by the device during boot (or normal execution) until the application requests it. If you can run for example basic driver examples (such as uartecho) on the device but not RF examples, then I would consider checking the crystal. 

It is not very clear how far into the code you make it before the exception. There is many things to consider, which is also why I asked what SDK you are running. If you can clarify just how far you get in terms of debugging this would help narrow potential issues down. Can you for example make it into main or do you crash before this? If you can make it into main, have you stepped over the code to see when the device crashes?

You can also just configure the device to only run of RCOSC_LF in the CCFG (Or device configuration view in SysConfig) to rule out problems with the 32 kHz crystal. 

Dear M-W,

I run minimal examples without using any drivers. Nothing works
The fault happens before the jump to the main method. This makes it so difficult to debug.

The 32kHz crystal is not connected, therefore, I am using RCOSC_LF.

I am using the SimpleLink CC13/26 SDK v. 3.40.00.02

Do you have an idea how to further troubleshoot without lab equipment?

Thanks,

Matthias
 

Hi Matthias,

Did you configure the CCFG to only run of RCOSC (to avoid SW trying to switch to an external crystal)? Which example do you run exactly?

I would say you should do the impedance measurement to verify if the chip is OK or not (and that no IO is accidentally grounded for example) as you already figured out where your software halts.

As you claim to use rev. E silicon and the 3.40 SDK, you should not get halted here. Assuming that the silicon is actually the correct revision (where did you get the ICs from?) it could be that they are damaged in some way (thus the request to measure the impedance of each IO to GND).