• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 55 subscribers
  • Views 4310 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2650 dev kit suppled error rate test

Roland King
Prodigy 210 points

Other Parts Discussed in Thread: CC2650, SEGGER, CC2650EMK

The two boards in the CC2650 kit ship with pre-loaded packet error rate test software, I have two questions about that. 

1) If you erase the software from the chip, is there an available .bin or .hex file to load it back on again, or once you've lost it, you've lost it. I was hoping to be able to put it back onto the board later. 

2) When the packet error rate test is running on the chip I found it's just about impossible to connect to it with a Segger J-Link. The J-Link works fine after the software has been erased but fails to connect 99% of the time when it's running. Is there a reason for this? Is the board put into a hard-to-debug mode or has bits of the JTAG interface turned off or is in low-power mode or anything? Or is this a bug in the Segger driver? 

  • 0
    TI__Guru** 105180 points

    Hi Roland,

    The PER test code is not present in the SDK but I will see if it's available as a pre-compiled hex.

    Regarding the debugger, are you intending to reprogram or debug the PER test code while it's running?

    Best wishes


    EDIT: Please see this thread for the PER test code: https://e2e.ti.com/support/wireless_connectivity/f/538/p/412193/1464892#1464892

  • 0 in reply to JXS
    Prodigy 210 points

    Thanks for the reply - would be handy to be able to put it back on the chip later, it probably would be quite useful when I get somewhat further with development.

    No I was trying to connect a J-Link to the chip in order to program it with my own code. I asked Segger but didn't get very far, they could only suggest the chip was set in non-debuggable or low-power mode. Somewhat of a catch-22, in order to connect the J-Link I had to erase the chip, in order to erase the chip I had to get the J-Link to connect first.

    Fortunately it did connect literally about one time in 100, just kept turning it on and off and on and off and trying until it worked. Then I was able to erase it and as soon as that was done it's been 100% fine ever since. I wanted to know whether this was by-design, or an odd timing issue when this code was running or a Segger bug I can go back to them and ask about some more.

    EDIT: and thanks for the link to the hex file = I failed dismally to find that with a forum search. Now I can attempt to erase my second dev board knowing I can get the thing back again later. 

  • 0
    Guru 735695 points

    You can refer to Svend's replies in e2e.ti.com/.../1464892

    The original program (CC2650 Packet error rate test) is currently not published as it needs to undergo some "clean-up" wrt licensing.

    Please find attached the hex file of v1.1 for the CC2650 PER test.

    per_test_v1_1.hex

  • 0 in reply to YiKai Chen
    Prodigy 210 points

    Yes it was only the binary I wanted and JKS linked to that thread above, so I have it now. I just needed to be able to put it back on the board for testing later, didn't want the source. 

    I would still like to understand why running that test binary makes the chip inaccessible to a Segger J-Link. I eventually managed to get the second board erased (at which point it works perfectly) but it took me 50-60 random attempts and turning it off and on and restarting it until I got a connection and was able to erase it. 

  • 0 in reply to Roland King
    Guru 735695 points
    I use SmartRF06EB and CC2650EMK, and don't have erase and download problem. Maybe the issue is cause by Segger J-Link.
  • 0 in reply to YiKai Chen
    Prodigy 210 points
    Perhaps it is - that's what I'm trying to figure out - Segger haven't come up with any good ideas at this point. I too am using SmartRF06 and CC2650EMK, with the debugger jumpers removed and a JLink connected as external debugger. With the test image running on the board, can't get a connction, well very, very rarely, once it's been erased there's no issue.

    I assume you're using the on-board XDS100v3
  • 0 in reply to Roland King
    TI__Guru** 105180 points
    Hi Roland,

    As YiKai states, there is no issue with the XDS100 on the RF06 board. One option may be to use the TI-RTOS backdoor to park the CPU in a while(1) loop during boot. This may allow the JLink to grab control. You can find details on the TI-RTOS backdoor in the SW Developer's Guide (SWRU393).

    Best wishes
  • 0 in reply to Roland King
    Guru 735695 points
    Yes, I use XDS100v3. Since you have SmartRF06EB, why don't you use XDS100v3?
  • 0 in reply to JXS
    Prodigy 210 points
    That enables connection, if I hold down the select key and keep holding it, JLink can connect, once the code starts running, I cannot again. I can't see why a running RTOS would affect the JLink's ability to connect to the cJTAG port but it certainly seems like it does. As far as I can tell the Segger puts the cJTAG back into 4-wire JTAG mode whereas I suspect the XDS stays in cJTAG mode, so there's one possible difference. That appears to work fine when there's nothing on the board, but not when this demo code is running.

    I've replied to my post on the Segger forums with some more information about reproducing the issue to see if I can get Segger to look at it again. If there's anything else I can suggest to them which might help them debug please suggest it else I think we've gone as far here as we're likely to and I'm going to have to rely on them to fix it. Thanks for all the help.
  • 0 in reply to YiKai Chen
    Prodigy 210 points
    I don't use XDS100v3 because it doesn't work on OSX which is what I primarily use. I'm working with the recent, and very welcome, support for open source tools, and that's going quite well in terms of building code, however for uploading and debugging, J-Link is the only game in town.

    I know CCS is coming to OSX but is currently only MPS430 and as far as I can tell the API for XDS100 isn't published so there's no support in the other common tools like OpenOCD. Rowley Crossworks supports XDS100v2, but not v3.

    Apart from that, Segger claims support for the device, and JLinks aren't cheap, so if it's supposed to work, it really ought to work. So I'm trying to gather as much information/repro cases as possible to see if I can get them to fix it.

    At least after the help here I can get the board wiped and that means I can connect, debug etc, so I'm able to work which is good. I'm just a little concerned that as my code gets more complicated I'm going to run into this again, hence the desire to get to the root cause.
  • 0 in reply to Roland King
    Guru 735695 points

    I see you point. However, I would suggest you to setup a Windows System for development since most of related tools are windows based. This would make you get rid of most of problems.

  • 0 in reply to YiKai Chen
    Prodigy 210 points
    Without wanting to get into the debate about toolsets and support which has been well-debated elsewhere, I have a lot invested in the tools I use, both time and to an extent cash, but mostly time and familiarity and a large chunk of library and other code, and I'm very productive with them and far less so when having to switch around between different tools, build environments, operating systems etc.

    I've waited quite a long time for TI to 'go Cortex' in its BTLE offering and provide some, if limited (and currently it is limited) support for open source tools and I'm very pleased they have, which is why I bought the kit. I don't expect it to be trivial to set up the tools I'm used to using, but I do expect once it's done to have a good consistent environment to work in and that's very important. I'm afraid if the answer ends up being 'you have to use tools on Windows' (and I still haven't even worked out whether CCS on windows costs or not) then the board goes back in the box and waits for the nascent (and again very much appreciated) support for open source tools to get fleshed out.

    I'm also talking to Rowley about supporting XDS100v3, which would be nice to have, I've picked apart the ccs26xxware and that's compiling and work fine, I still have a way to go with the BTLE stuff, but in the end, it's all code, it's all compiled, linked and put on a chip.
  • 0 in reply to Roland King
    TI__Mastermind 29650 points

    Roland,

    I suspect this is due to the software turning off the JTAG domain which we do as part of the initialization to save power.

    Our debuggers (and also IAR's I-jet) will set a "Force on" bit in the JTAG scan chain to prevent the device to fully power down to standby and rather "emulate" standby. It sounds like the Segger does not set this bit.

    Assigning the thread to our tools team to see if they have any updates to this.

    Regards,

    Svend

  • 0 in reply to svendbt
    Prodigy 210 points

    thanks for this - that's useful information and would certainly explain why it doesn't work. Segger asked me if the chip was in a low power mode or debug was otherwise turned off but all I could tell them was that the on-board XDS was able to connect. 

    The segger is working pretty well after I remove the error rate test code and wipe the board and I now (thanks to an earlier post) know about the back door to break in after I put it back on so I can work reasonably well at this point, it is however useful to know what was causing the problem, or potentially so. 

  • 0 in reply to svendbt
    TI__Genius 12900 points
    2) Impossible to connect with a Segger J-Link.
    This is a limitation in the Segger driver. It doesn't support the "force active" feature in the CC26xx devices, causing it to lose contact when the device enters low power modes. We are trying to work with Segger to get this fixed.