This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/CC1310: Problem debugging external target by LaunchPad CC1310

Part Number: CC1310

Tool/software: Code Composer Studio

Good afternoon,

we have a customer board mounting a CC1310 and we debug it by the XDS on the LaunchPad CC1310.

We connect the customer target by the connector P7, and we have removed  all the jumper P4 of the LaunchPad.

Our problem is that a lot of customer board have problems after we have debugged them for a while. We are not able to identify the problem, also because when they stop to work, they have different behaviour. For example, the last board killed is recognized from the SmartRF Studio, but when we tried to load it by CCS we have the message below. Please, have you got any suggestion to investigate about the problem?

Cortex_M3_0: GEL Output: Memory Map Initialization Complete.

Cortex_M3_0: GEL Output: Board Reset Complete.

Cortex_M3_0: Target timed out! (Block 0)

Cortex_M3_0: Status 0x0103: Target flashloader failed to program flash. Low level function returned status 4 (Operation failed).

Cortex_M3_0: Command=4 -- addr=0x00001000 -- length=0x00001000

Cortex_M3_0: File Loader: Memory write failed: Timed out waiting for target flashloader to execute command.

Cortex_M3_0: GEL: File: C:\Projects\IRSAP\project\workspace_ti_ccs\rfIrsapNow20Meh\Now20Meh_Debug_Cli\rfIrsapNow20Meh.out: Load failed.

 

Have you got any suggestion to try to understand the problem?

  • I haven't seen this error message before.

    You write that SmartRF Studio recognize the board even if you get this error message. Are you able to send packets (as an example) with Studio? If so it sounds like a flash issue and not a jtag connection issue. (SmartRF Studio uses RAM to run the required code)

    From what you write it sounds like you get different error messages for different boards, is this the case? If so, could you give a couple of examples? Are you always able to access the different boards with SmartRF Studio?

    Are you successfully able to do a mass erase of the device and if so, are you able to upload code?

    Is this independent of the type of code you are using? If you run some of the examples in the SDK, do you see the same issue then?

    Not sure if this issue could be related to hardware, I could take a quick look at the schematic/ layout to see if something stand out, send me a friend request with the files (pdf, gerber)
  • Hello TER and thank you for your fast help.

    I try to answer to you question.

    First of all, my problem is that I'm able to work loading and debugging the code on one board and after a while it doesn't work anymore. So, I'm quite sure the connection is correct, I suppose that something else is crtical and after a while it breaks. Then, the behaviour is not the same on the broken boards. I see the message I wrote here and I connect it with SmartRF Studio tool (I'm able to send packets) using one board. I'm not able to connect the SmartRF Studion to another broken board.

    It doesn't depends on the project, if the board is not accessible, it is not independently by the project I'm using.

    Please, did you suggest me how I can erase the flash? In this condition I'm not able to open the flash panel.

    I have a question about the connection: we have remoed all the jumper of the P4 connector on LaunchPad and we have connected our target by P7 connector. How must we set the P10 connector? If we leave it in the default position, the target gets the power from the LaunchPad: is this correct? Can we work without giving other power to our target?

    Now I have another question which is not related to this problem... if you tell me I'll open another topic... Our design is based on the Concentrator-Node example. Can you tell me how the collisions are handled? By a LBT (Listen Before Talk) alghoritm? I suppose it is, because I can see that the EasyLink_init function configures the "Configure the EasyLink Carrier Sense Command" (rfc_CMD_PROP_CS_t). Can you confirm this? We must be sure about this thinking about the requirements we have on the radio link in our system.

    Thanks again, Andrea. 

  • - You have to use Flash Programmer 2 to do a mass erase. If you are not able to connect the boards with SmartRF Studio you will not be able to do mass erase.

    - The Vsense jumper has to be in the external power position if the board you are debugging is not powered by the launchpad. Just to be sure, could you post a picture of your full setup?

    - For the last question, you have to start a separate thread for this.
  • At the moment, I'm working with our board powered by the launchpad, so the Vsense jumper is in position 1-2.

    If we need to power our board by another source (not by the launchpad), must the jumper be in position 2-3 or must it be removed?
  • Have you managed to get this to work as intended?
  • Sorry TER, I was involved in another problems and this is gone in the last positions of my priorities... I have downloaded the flash programmer but I haven't used it yet. I really suppose we had some problems with the external power on our target, but I'm not sure because for the momento I'm debugging the code using the LaunchPad and in this condition we haven't any problem.

    Thanks a lot for your support, I think this issue can be considered closed.