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.

CC3220SF-LAUNCHXL: CC3220SF-LAUNCHXL

Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: CC3220SF, CC1350

I have been using the images given onto the CC3220SF board. When I use the 1352 boards for MAC-CoP, it didnt update on the debug serial channel. The 1350 board gives updates but the local webapp which I used for debugging did not work. When I connect to the board's wifi, the webapp shows its content without styling (in raw form). After I connect them to the house's WiFi and connect to the board through that, the content of the webapp was even more buggy and did not have button as it was supposed to. 

Do you have a working version of the files that we can access? I tried the one that imported the CCS projects and got the same problem for the CC1352 board.

  • Phuc To,

    I apologize for what you are experiencing.

    This demo was developed in 2017, and our SDKs have updated multiple times from then.

    The reason for the CC1352 is not working, is that the Coprocessor Image in the package was built pre released version of the CC1352, I recommend you download the latest SDK and flash the CC1352 with latest co-processor image. You should be fine using the CC1350, since you are using the CC135x device in this mode (co-processor) using the X2 device will not give an advantage.

    As for the missing images in the html, make sure all of them are in the server (cc3220SF), try different browsers, that is a known bug of this design. One way to mitigate this issue, is to turn off all UART printouts, these take too much time during REST CB functions, I would start by the CB printouts. These are just for debugging purposes and should be commented out .

    The CC3220 is fetching a lot of js libraries and requesting information form the sub 1 ghz network and timing out. Try refreshing until it shows up, and the browser should be able to cache most of this information for future use.

    I will contact an expert on the WIFi device who should be able to give additional advice on this issue.

    regards,

    ab

  • The hex file from ti154stack in the 3.40 SDK does not work for me. The debug channel doesn't update still. Do you have a reliable one?

    I wanted to use the CC1350, but we are using all the sensors that come with the 1352. Are they compatible with 1350?

    Also this is a much related question I think. I was following the instruction for out-of-the-box example given in:
    http://www.ti.com/lit/ug/tidud09a/tidud09a.pdf
    However, the instruction told me to use the www files in C:\\tidc01002\src\www, which gives a different appearance than the one they show in the later part.
    I found the www files that have similar appearance in C:\ti\tidc01002\examples\cc3220_local_web_app\www instead. So is it safe to use the 3220 one instead?

    For clarification, when I used the given image on 3220, it gave the appearance of the www files in 3220 folder. 

  • The 1350 devices are compatible with cc1352 and viceversa. 

    Yes, use the CC3220 ones, the other folder is for the cloud application. for the local application use the ones inside the CC3220 folder.

    But, keep in mind that if the sensors using the CC1352 are on the latest sdk, you will need to modify the collector.c code to match the data being received (inside dataIndCB() ) this applies for both the CC1350 and CC1352, the problem here is that the code in this reference design has not been updated to reflect all changes done since then.