• State
  • Locked Locked
  • Replies 31 replies
  • Subscribers 43 subscribers
  • Views 7266 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.

No WI-FI on CC3200

Joshua Cox
Prodigy 220 points

I have created a PCB that was built by referencing the CC3200-LAUNCHXL schematic as strictly as possible, but I have yet to get any WIFI capabilities.

When using the CC3200-LAUNCHXL to run the MDNS Application example code from the 3200SDK in Code Composer Studio 6.0.1 debug mode, I see the following output from the Terminal:

 

The problem is when I run the code from my custom PCB I see the following:

 

Note: I have hardcoded the access point name and password so it should connect on boot. I have also tried other application examples such as the out-of-the-box and wlan_station examples with similar results.

 

I have tried updating the service pack using the CC3200 UniFlash tool with hope that it might help, but the UART always times out during the operation, even though there are no issues with formatting, programming, or reading the version information.

 

Trying to investigate why the updating the service pack fails you can see below where the CC3200 fails to respond.

When probing the RF Pin(RF_BG/Pin 31) I see no output at all on the custom board.

I have verified the following:

  • The microcontroller executes all processes aside from WI-FI flawlessly.
  • The crystal oscillators are outputting the correct frequencies.
  • The code works on a CC3200-LAUNCHXL as expected.
  • The antenna and filter design is functional. This was tested with a spectrum analyzer tracking generator. We attached the spectrum analyzer to the RF Pin of the microcontroller (RF_BG/Pin 31) and used the tracking generator to confirm signal transmission.

I am at a lost on how to debug this further and any help resolving this issue would be awesome!

I have access to a CC3200-LAUNCHXL, spectrum analyzer, oscilloscope, logic analyzer, and basic lab equipment.

Additional Details:

  • SOP2 Pulled High
  • SOP1 Pulled Down
  • SOP0 Pulled Down
  • CC3200 TX(GPI01) - FTDI RX
  • CC3200 RX(GPI02) - FTDI TX
  • COM Port 37

 

  • 0
    TI__Guru 56650 points

    Hi,
    have you tried to test your custom board with the Radio Tool?
    processors.wiki.ti.com/.../CC31xx_%26_CC32xx_Radio_Tool

  • 0 in reply to Leo Hendrawan
    Prodigy 220 points

    Nope, we are looking into this now and will post back with results ASAP.

    Could this uncover why the service pack programming is failing?


    Thanks,
    Josh

  • 0 in reply to Leo Hendrawan
    Prodigy 220 points

    Leo,

    I hope we are on track to resolving the issue. We attempted to use the radio tool, but are unable to get past the initial steps.

    Steps we did:

    Flashed the radio firmware, radio.tool.bin, onto the CC3200.(Erase, update, and verify checked) - appeared to have no issues

    Removed the SOP2 jumper

    Launch the CC3100/3200 Radio Tool v1.0.5358 Application

    We are able to connect, but a device warning pops up fails as followed:

    Possible issues:

    From the radio tool, "Note: The Radio Tool version matches SDK version. For example, if the Radio Tool has a version as 0.5.x.x, you'll need to flash the devices with Service Pack 0.5.x."

    We can not flash the service pack so we are unsure how to determine which service pack version is currently on the device.(Tried using previous versions of the radio tool...Same result)

    Additional details:

    We followed this same procedure with a LauchXL and it worked fine.

  • 0 in reply to Leo Hendrawan
    Prodigy 220 points
    Leo, are there any addition details I can provide to help you debug our issue remotely?
  • 0 in reply to Leo Hendrawan
    Prodigy 220 points

    Leo, Out of curiosity are you even getting these messages?

    I have tried to contact TI for support through the following:

    • My distributor
    • Calling Support
    • Chatting with TI 
    • Emailing
    • Submitting a support ticket
    • Requesting a call back
    • Message on Twitter
    • This forum post

    Can I expect a response at all?

  • 0 in reply to Joshua Cox
    TI__Intellectual 2500 points
    Hi Joshua,

    Given this note on the initial post: "I have created a PCB that was built by referencing the CC3200-LAUNCHXL schematic as strictly as possible, but I have yet to get any WIFI capabilities." Can you expand on the items that you didn't copy from the LaunchXL design files?
    Did you look at this www.ti.com/.../swru370 for the hardware design layout guidelines?

    Regards,
  • 0 in reply to Beatrice Fankem
    Prodigy 220 points

    Beatrice, It was built technically speaking Identical. As shown above we are having an issue updating the firmware, but the micro controller functions are all intact...This leads me to think the problem is not hardware. Though this could be inaccurate and hardware could be an issue. The parts used were suitable crosses of components used. I am hoping for help debugging this issue. Yes, all layout guidelines were followed strictly!

  • 0 in reply to Joshua Cox
    TI__Intellectual 2500 points
    Which version of the board do you read from Uniflash?
    Paste the full prints of Uniflash debug console, for when you are trying "get the version" and "update the service pack".
    What is the outcome of the hyperterminal, when you run the getting started as a WLAN AP?
  • 0 in reply to Beatrice Fankem
    Prodigy 220 points

    Beatrice, Find the responses to your questions below:

    I know how to get the bootloader and chipset version from uniflash, but I am not sure how to get the board version.

     

    The following information is printed on the actual chip:

    • CC3200R1 M2
    • 4A3
    • ZDRJ G3

    "Get the Version" Debug Console Output

    [15:29:57] Begin GetVersion operation.
[15:29:59] INFO: > Executing Operation: Connect
[15:30:00] DEBUG: waiting and clearing uart rx buffer
[15:30:02] INFO: setting break signal
[15:30:02] INFO: --- please restart the device ---
[15:30:02] DEBUG: wait for ack
[15:30:02] INFO: connection succeeded
[15:30:02] INFO: getting storage list
[15:30:02] DEBUG: wait for ack
[15:30:02] INFO: > Executing Operation: GetVersion
[15:30:02] INFO: reading version info
[15:30:02] DEBUG: wait for ack
[15:30:02] INFO: > Bootloader version: 2.1.4.0
[15:30:02] INFO: > Chipset version: 16
[15:30:02] INFO: > Executing Operation: Disconnect
[15:30:02] DEBUG: disconnecting from device . . . 
[15:30:02] DEBUG: wait for ack
[15:30:02] Operation GetVersion returned. 
     

    "Update the Service Pack" Debug Console Output

    [15:32:12] Begin ServicePackProgramming operation.
[15:32:15] INFO: > Executing Operation: Connect
[15:32:15] DEBUG: waiting and clearing uart rx buffer
[15:32:17] INFO: setting break signal
[15:32:17] INFO: --- please restart the device ---
[15:32:17] DEBUG: wait for ack
[15:32:17] INFO: connection succeeded
[15:32:17] INFO: getting storage list
[15:32:17] DEBUG: wait for ack
[15:32:17] INFO: > Executing Operation: ServicePackProgramming
[15:32:17] INFO: Path to the service pack file: C:/ti/CC31xx_CC32xx_ServicePack_1.0.0.1.2/servicepack_1.0.0.1.2.bin
[15:32:17] INFO: reading version info
[15:32:17] DEBUG: wait for ack
[15:32:17] INFO: CC3200R Device detected.
[15:32:17] INFO: NWP/MAC/PHY Version from Service Pack: 
[15:32:17] INFO:  NWP Patch version: 2.2.0.1
[15:32:17] INFO:  MAC Patch version: 1.2.0.2
[15:32:17] INFO:  PHY Patch version: 1.0.3.23
[15:32:17] INFO: reading version info
[15:32:17] DEBUG: wait for ack
[15:32:17] INFO: DEVICE CC3200 ES1.33
[15:32:17] INFO: reading version info
[15:32:17] DEBUG: wait for ack
[15:32:17] DEBUG: Bootloader version is 2, 1, 4, 0
[15:32:17] DEBUG: It's a CC3200 device: PG1.33 or higher
[15:32:17] DEBUG: Switch UART pinmux to APPS
[15:32:17] DEBUG: wait for ack
[15:32:17] DEBUG: wait for ack
[15:32:18] DEBUG: Switch to NWP bootloader complete
[15:32:18] INFO: reading version info
[15:32:18] DEBUG: wait for ack
[15:32:18] DEBUG: Bootloader version is 2, 0, 4, 0
[15:32:18] DEBUG: raw storage write
[15:32:18] DEBUG: wait for ack
[15:32:18] DEBUG: status request
[15:32:18] DEBUG: wait for ack
[15:32:18] DEBUG: BlockSize is 4096, number of blocks is 16
[15:32:18] DEBUG: erasing 13 blocks starting from  0
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: status request
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: status request
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: status request
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: status request
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: status request
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: status request
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: status request
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: status request
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: status request
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: status request
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: wait for ack
[15:32:19] DEBUG: status request
[15:32:19] DEBUG: wait for ack
[15:32:20] DEBUG: wait for ack
[15:32:20] DEBUG: status request
[15:32:20] DEBUG: wait for ack
[15:32:20] DEBUG: wait for ack
[15:32:20] DEBUG: status request
[15:32:20] DEBUG: wait for ack
[15:32:20] DEBUG: wait for ack
[15:32:20] DEBUG: status request
[15:32:20] DEBUG: wait for ack
[15:32:20] DEBUG: status request
[15:32:20] DEBUG: wait for ack
[15:32:20] DEBUG: 0
[15:32:20] DEBUG: wait for ack
[15:32:20] DEBUG: wait for ack
[15:32:20] INFO: Downloading file "/sys/servicepack.ucf" with size 6100
[15:32:20] DEBUG: sending start download command
[15:32:20] DEBUG: Granularity conversion: G(1024) * N(128) = 131072
[15:32:20] DEBUG: Access code is 3
[15:32:20] DEBUG: wait for ack/nack
[15:32:35] DEBUG: UART timeout
[15:32:35] DEBUG: --- received unexpected data!!!!!
[15:32:35] INFO: > Executing Operation: Disconnect
[15:32:35] DEBUG: disconnecting from device . . . 
[15:32:35] DEBUG: wait for ack
[15:32:37] Operation ServicePackProgramming returned.

    The Tera Term output for "getting started as a WLAN_AP". The Example was imported from CC3200SDK_1.0.0.

                     *************************************************
                       CC3200 WLAN AP Application
                 *************************************************


Host Driver Version: 1.0.0.1
Build Version 2.0.7.0.31.0.0.4.1.1.5.3.3
Device is configured in default state
Device started as STATION
Enter the AP SSID name: TestFi
Device is configured in AP mode
Connect a client to Device

    Note: None of my WiFi devices can detect the "TestFi" SSID configured in this application

    I want to thank you for your continued support towards solving my issue. 

  • 0 in reply to Joshua Cox
    TI__Guru 64455 points

    Hi Joshua,

    You have a production CC3200 (ROM part) and according to the logs you are communicating with the device but for some reason fails to program the service pack. Although it does seem as software issue, I'm still not negating this possibility. However, please provide the followings so I can have the full picture:

    1. you mentioned: "there are no issues with formatting, programming, or reading the version information". Can you elaborate what you were trying to program that succeed? more specifically, what file sizes?
    2. please indicate what version of Uniflash you are using. You can find it under help->about.
    3. It seems you have saleae logic. Can you provide the capture files (not the screen shots only) for formatting, successful programing and failing Service Pack programming? It can shed light on the root cause.
    4. Which SFLASH part are you using?
    5. Can you try and flash any user file with the same size of 128KB. It does not have to be this size exactly. You can use a much smaller file but configure "MAX size" for 131072.

    The only obvious reason I can think of is related to the size of the file (which is 128KB for service pack). What happens is that Uniflash needs to erase 128KB before writing to the SFLASH and since 15 seconds elapsed with no answer, you get a UART timeout. On LaunchPad it takes ~4 seconds to erase all blocks so if you have some kind of HW issue or a very very slow SFLASH, then it can be expected.

    Since Service Pack is almost like any other file, I expect that 128KB file would also fail. This is why I asked for test #5.

    Regards,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    TI__Genius 11120 points
    JoshuaCan you list the exact part number of the serial flash used on your board?
    Note that we would need a s-flash of 8Mbit or more on the CC3200.
    The issue seems to be mostly a s-flash size problem or incompatible part.Regards
    Prajay
  • 0 in reply to Prajay Madhavan
    Prodigy 80 points
    Sorry to butt in on this discussion. Is there a document for the CC3100 or CC3200 bootloader somewhere? Or is it Top Secret? It would really really be helpful. Not just for me, but for the OP as well.

    I have been having issues updating the CC3100 to the newest Firmware on an "own-design" board. The bootloader running at 921600 baud, and only that Baudrate, was the first of the many nasty surprises that we have had.

    Which is why -> documentation.
  • 0 in reply to Shlomi Itzhak
    Prodigy 220 points

    1. The attempts to program the sflash came from the original "out_of_box.ucf" file with no modifications from the cc3200SDK_1.0.0. All of the files within that UCF configuration are less than the file size of the service pack individually.

    2. The Uniflash version is: 3.2.0.00120 for all our operations.

    3. The output of the Seleae logic generate .logicdata file sizes that are very large, so I compressed the file and posted the smallest one that would fit on this site and added a dropbox link the other files that wouldn't fit.

    Get Version Capture:

    Get Version Capture.zip

    Fomatting 16MB Capture:

    Link

    Programming with large file Capture:

    Link

    4. Our design currently incorporates a 16MB SFLASH part that operates at 108MHz. This part was chosen from a list of compatible parts found in another post on this forum  which can be found at the link below:

    e2e.ti.com/.../1262696

    Actual SFLASH part details below:

    Memory size: 128Mb

    Speed: 108MHz

    Manufacturing Part Number: N25Q128A11ESE40G

    Digi-Key Part Number: 557-1572-5-ND

     

    There are plans to implement an alternate 2MB SFLASH part that was prepared for our design, but it is not the part being tested in the prototype nor is it one that can be found in the compatibility list. It was evaluated based on the command list presented in the same forum post. We could test this part to check is the error still persists. The details of this part can be found below:

     Memory size: 2Mb

    Speed: 108MHz

    Manufacturing Part Number: M25PX16-VMN6TP

    Digi-Key Part Number: M25PX16-VMN6TPTR-ND

     

    5. The UniFlash Debug Console Output for programming with the Blinky application while including an additional file [large_test_file.txt] with a MAX size set to '131072'

    [09:25:28] Begin Program operation.

[09:25:31] INFO: Checked for update config groups: []

[09:25:31] INFO: List of files to be generated: []

[09:25:31] INFO: > Executing Operation: Connect

[09:25:31] DEBUG: waiting and clearing uart rx buffer

[09:25:33] INFO: setting break signal

[09:25:33] INFO: --- please restart the device ---

[09:25:33] DEBUG: wait for ack

[09:25:40] INFO: connection succeeded

[09:25:40] INFO: getting storage list

[09:25:40] DEBUG: wait for ack

[09:25:40] INFO: > Executing Operation: Init

[09:25:40] INFO: reading version info

[09:25:40] DEBUG: wait for ack

[09:25:40] INFO: DEVICE CC3200 ES1.33

[09:25:40] INFO: reading version info

[09:25:40] DEBUG: wait for ack

[09:25:40] DEBUG: Bootloader version is 2, 1, 4, 0

[09:25:40] DEBUG: It's a CC3200 device: PG1.33 or higher

[09:25:40] DEBUG: Switch UART pinmux to APPS

[09:25:40] DEBUG: wait for ack

[09:25:41] DEBUG: wait for ack

[09:25:41] DEBUG: Switch to NWP bootloader complete

[09:25:41] INFO: reading version info

[09:25:41] DEBUG: wait for ack

[09:25:41] DEBUG: Bootloader version is 2, 0, 4, 0

[09:25:41] DEBUG: raw storage write

[09:25:41] DEBUG: wait for ack

[09:25:41] DEBUG: status request

[09:25:41] DEBUG: wait for ack

[09:25:41] DEBUG: BlockSize is 4096, number of blocks is 16

[09:25:41] DEBUG: erasing 13 blocks starting from 0

[09:25:42] DEBUG: wait for ack

[09:25:42] DEBUG: status request

[09:25:42] DEBUG: wait for ack

[09:25:42] DEBUG: wait for ack

[09:25:42] DEBUG: status request

[09:25:42] DEBUG: wait for ack

[09:25:42] DEBUG: wait for ack

[09:25:42] DEBUG: status request

[09:25:42] DEBUG: wait for ack

[09:25:42] DEBUG: wait for ack

[09:25:42] DEBUG: status request

[09:25:42] DEBUG: wait for ack

[09:25:42] DEBUG: wait for ack

[09:25:42] DEBUG: status request

[09:25:42] DEBUG: wait for ack

[09:25:42] DEBUG: wait for ack

[09:25:42] DEBUG: status request

[09:25:42] DEBUG: wait for ack

[09:25:42] DEBUG: wait for ack

[09:25:42] DEBUG: status request

[09:25:42] DEBUG: wait for ack

[09:25:42] DEBUG: wait for ack

[09:25:43] DEBUG: status request

[09:25:43] DEBUG: wait for ack

[09:25:43] DEBUG: wait for ack

[09:25:43] DEBUG: status request

[09:25:43] DEBUG: wait for ack

[09:25:43] DEBUG: wait for ack

[09:25:43] DEBUG: status request

[09:25:43] DEBUG: wait for ack

[09:25:43] DEBUG: wait for ack

[09:25:43] DEBUG: status request

[09:25:43] DEBUG: wait for ack

[09:25:43] DEBUG: wait for ack

[09:25:43] DEBUG: status request

[09:25:43] DEBUG: wait for ack

[09:25:43] DEBUG: wait for ack

[09:25:43] DEBUG: status request

[09:25:43] DEBUG: wait for ack

[09:25:43] DEBUG: wait for ack

[09:25:43] DEBUG: status request

[09:25:43] DEBUG: wait for ack

[09:25:43] DEBUG: status request

[09:25:43] DEBUG: wait for ack

[09:25:43] DEBUG: 0

[09:25:43] DEBUG: wait for ack

[09:25:43] DEBUG: wait for ack

[09:25:43] INFO: > Executing Operation: Program

[09:25:43] INFO: > File name: /sys/mcuimg.bin, Update: true, Erase: true

[09:25:44] INFO: > Erase File: /sys/mcuimg.bin

[09:25:44] INFO: erasing file "/sys/mcuimg.bin"

[09:25:44] INFO: deleting file "/sys/mcuimg.bin"

[09:25:44] DEBUG: wait for ack

[09:25:44] DEBUG: status request

[09:25:44] DEBUG: wait for ack

[09:25:44] DEBUG: Error -11 : File not exists

[09:25:44] INFO: erase file completed

[09:25:44] INFO: > Size of file = 4888

[09:25:44] INFO: > Update File: /sys/mcuimg.bin

[09:25:44] INFO: Downloading file "/sys/mcuimg.bin" with size 4888

[09:25:44] DEBUG: sending start download command

[09:25:44] DEBUG: Granularity conversion: G(256) * N(20) = 5120

[09:25:44] DEBUG: Access code is 3

[09:25:44] DEBUG: wait for ack/nack

[09:25:45] DEBUG: receive ack

[09:25:45] DEBUG: send chunk

[09:25:45] DEBUG: wait for ack

[09:25:45] DEBUG: status request

[09:25:45] DEBUG: wait for ack

[09:25:45] DEBUG: send chunk

[09:25:45] DEBUG: wait for ack

[09:25:45] DEBUG: status request

[09:25:45] DEBUG: wait for ack

[09:25:45] DEBUG: wait for ack/nack

[09:25:45] DEBUG: receive ack

[09:25:45] INFO:

 

New Token is 0x0

[09:25:45] INFO: Download complete

[09:25:45] INFO: Verifying Data...

[09:25:45] INFO: get file

[09:25:45] DEBUG: enter get file info

[09:25:45] DEBUG: wait for ack

[09:25:45] DEBUG: status request

[09:25:45] DEBUG: wait for ack

[09:25:45] DEBUG: sending start download command

[09:25:45] DEBUG: Granularity conversion: G(256) * N(20) = 5120

[09:25:45] DEBUG: Access code is 0

[09:25:45] DEBUG: wait for ack/nack

[09:25:45] DEBUG: receive ack

[09:25:45] DEBUG: get chunk

[09:25:45] DEBUG: wait for ack

[09:25:45] DEBUG: Receiving chunk of 4096 bytes

[09:25:45] DEBUG: status request

[09:25:45] DEBUG: wait for ack

[09:25:45] DEBUG: get chunk

[09:25:46] DEBUG: wait for ack

[09:25:46] DEBUG: Receiving chunk of 792 bytes

[09:25:46] DEBUG: status request

[09:25:46] DEBUG: wait for ack

[09:25:46] DEBUG: wait for ack/nack

[09:25:46] DEBUG: receive ack

[09:25:46] INFO: Done. Reading 4888 bytes

[09:25:46] INFO:

 

Verification OK

[09:25:47] INFO: > Updated Token value: 0x0

[09:25:47] INFO: > File name: /cert/ca.pem, Update: false, Erase: false

[09:25:47] INFO: > File name: /cert/client.pem, Update: false, Erase: false

[09:25:47] INFO: > File name: /cert/private.key, Update: false, Erase: false

[09:25:47] INFO: > File name: /sys/macadd.bin, Update: false, Erase: false

[09:25:47] INFO: > File name: /sys/mode.cfg, Update: false, Erase: false

[09:25:47] INFO: > File name: /sys/ipcfg.ini, Update: false, Erase: false

[09:25:47] INFO: > File name: /sys/ap.cfg, Update: false, Erase: false

[09:25:47] INFO: > File name: /sys/devname.cfg, Update: false, Erase: false

[09:25:47] INFO: > File name: /sys/mdns.cfg, Update: false, Erase: false

[09:25:47] INFO: > File name: /sys/dhcpsrv.cfg, Update: false, Erase: false

[09:25:47] INFO: > File name: /sys/httpsrv.cfg, Update: false, Erase: false

[09:25:47] INFO: > File name: /sys/pref.net, Update: false, Erase: false

[09:25:47] INFO: > File name: /sys/smartconfigkeys.cfg, Update: false, Erase: false

[09:25:47] INFO: > File name: /sys/stacfg.ini, Update: false, Erase: false

[09:25:47] INFO: > File name: /sys/p2p.cfg, Update: false, Erase: false

[09:25:47] INFO: > File name: /sys/pmcfg.ini, Update: false, Erase: false

[09:25:47] INFO: > File name: new file/large_test_file.txt, Update: true, Erase: true

[09:25:47] INFO: > Erase File: new file/large_test_file.txt

[09:25:47] INFO: erasing file "new file/large_test_file.txt"

[09:25:47] INFO: deleting file "new file/large_test_file.txt"

[09:25:47] DEBUG: wait for ack

[09:25:47] DEBUG: status request

[09:25:47] DEBUG: wait for ack

[09:25:47] DEBUG: Error -11 : File not exists

[09:25:47] INFO: erase file completed

[09:25:47] INFO: > Size of file = 12

[09:25:47] INFO: > Update File: new file/large_test_file.txt

[09:25:47] INFO: Downloading file "new file/large_test_file.txt" with size 12

[09:25:47] DEBUG: sending start download command

[09:25:47] DEBUG: Granularity conversion: G(1024) * N(128) = 131072

[09:25:47] DEBUG: Access code is 3

[09:25:47] DEBUG: wait for ack/nack

[09:25:55] DEBUG: receive ack

[09:25:55] DEBUG: send chunk

[09:25:55] DEBUG: wait for ack

[09:25:55] DEBUG: status request

[09:25:55] DEBUG: wait for ack

[09:25:55] DEBUG: wait for ack/nack

[09:25:55] DEBUG: receive ack

[09:25:55] INFO:

 

New Token is 0x0

[09:25:55] INFO: Download complete

[09:25:55] INFO: Verifying Data...

[09:25:55] INFO: get file

[09:25:55] DEBUG: enter get file info

[09:25:55] DEBUG: wait for ack

[09:25:55] DEBUG: status request

[09:25:55] DEBUG: wait for ack

[09:25:55] DEBUG: sending start download command

[09:25:55] DEBUG: Granularity conversion: G(1024) * N(128) = 131072

[09:25:55] DEBUG: Access code is 0

[09:25:55] DEBUG: wait for ack/nack

[09:25:55] DEBUG: receive ack

[09:25:55] DEBUG: get chunk

[09:25:55] DEBUG: wait for ack

[09:25:55] DEBUG: Receiving chunk of 12 bytes

[09:25:55] DEBUG: status request

[09:25:55] DEBUG: wait for ack

[09:25:55] DEBUG: wait for ack/nack

[09:25:55] DEBUG: receive ack

[09:25:55] INFO: Done. Reading 12 bytes

[09:25:55] INFO:

 

Verification OK

[09:25:56] INFO: > Updated Token value: 0x0

[09:25:56] INFO: > Executing Operation: Disconnect

[09:25:56] DEBUG: disconnecting from device . . .

[09:25:56] DEBUG: wait for ack

[09:25:57] Operation Program returned.

     UPDATE:

    Attempts to flash the cc3200 with a larger file size than the Service Pack resulted in the same UART timeout error seen while trying to update the Service Pack. This was also tested with the same process on the Launchpad and it programmed successfully. The Uniflash Debug Console Log is shown below:

    [15:59:44] Begin Program operation.
[15:59:46] INFO: Checked for update config groups: []
[15:59:46] INFO: List of files to be generated: []
[15:59:46] INFO: > Executing Operation: Connect
[15:59:46] DEBUG: waiting and clearing uart rx buffer
[15:59:48] INFO: setting break signal
[15:59:48] INFO: --- please restart the device ---
[15:59:48] DEBUG: wait for ack
[15:59:53] INFO: connection succeeded
[15:59:53] INFO: getting storage list
[15:59:53] DEBUG: wait for ack
[15:59:53] INFO: > Executing Operation: Init
[15:59:53] INFO: reading version info
[15:59:53] DEBUG: wait for ack
[15:59:53] INFO: DEVICE CC3200 ES1.33
[15:59:53] INFO: reading version info
[15:59:53] DEBUG: wait for ack
[15:59:53] DEBUG: Bootloader version is 2, 1, 4, 0
[15:59:53] DEBUG: It's a CC3200 device: PG1.33 or higher
[15:59:53] DEBUG: Switch UART pinmux to APPS
[15:59:53] DEBUG: wait for ack
[15:59:53] DEBUG: wait for ack
[15:59:54] DEBUG: Switch to NWP bootloader complete
[15:59:54] INFO: reading version info
[15:59:54] DEBUG: wait for ack
[15:59:54] DEBUG: Bootloader version is 2, 0, 4, 0
[15:59:54] DEBUG: raw storage write
[15:59:54] DEBUG: wait for ack
[15:59:54] DEBUG: status request
[15:59:54] DEBUG: wait for ack
[15:59:54] DEBUG: BlockSize is 4096, number of blocks is 16
[15:59:54] DEBUG: erasing 13 blocks starting from  0
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: status request
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: status request
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: status request
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: status request
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: status request
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: status request
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: status request
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: status request
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: wait for ack
[15:59:55] DEBUG: status request
[15:59:55] DEBUG: wait for ack
[15:59:56] DEBUG: wait for ack
[15:59:56] DEBUG: status request
[15:59:56] DEBUG: wait for ack
[15:59:56] DEBUG: wait for ack
[15:59:56] DEBUG: status request
[15:59:56] DEBUG: wait for ack
[15:59:56] DEBUG: wait for ack
[15:59:56] DEBUG: status request
[15:59:56] DEBUG: wait for ack
[15:59:56] DEBUG: wait for ack
[15:59:56] DEBUG: status request
[15:59:56] DEBUG: wait for ack
[15:59:56] DEBUG: wait for ack
[15:59:56] DEBUG: status request
[15:59:56] DEBUG: wait for ack
[15:59:56] DEBUG: status request
[15:59:56] DEBUG: wait for ack
[15:59:56] DEBUG: 0
[15:59:56] DEBUG: wait for ack
[15:59:56] DEBUG: wait for ack
[15:59:56] INFO: > Executing Operation: Program
[15:59:56] INFO: > File name: /sys/mcuimg.bin, Update: true, Erase: true
[15:59:56] INFO: > Erase File: /sys/mcuimg.bin
[15:59:56] INFO: erasing file "/sys/mcuimg.bin"
[15:59:56] INFO: deleting file "/sys/mcuimg.bin"
[15:59:56] DEBUG: wait for ack
[15:59:56] DEBUG: status request
[15:59:56] DEBUG: wait for ack
[15:59:56] DEBUG: Error -11 : File not exists
[15:59:56] INFO: erase file completed
[15:59:56] INFO: > Size of file = 4888
[15:59:57] INFO: > Update File: /sys/mcuimg.bin
[15:59:57] INFO: Downloading file "/sys/mcuimg.bin" with size 4888
[15:59:57] DEBUG: sending start download command
[15:59:57] DEBUG: Granularity conversion: G(256) * N(20) = 5120
[15:59:57] DEBUG: Access code is 3
[15:59:57] DEBUG: wait for ack/nack
[15:59:58] DEBUG: receive ack
[15:59:58] DEBUG: send chunk
[15:59:58] DEBUG: wait for ack
[15:59:58] DEBUG: status request
[15:59:58] DEBUG: wait for ack
[15:59:58] DEBUG: send chunk
[15:59:58] DEBUG: wait for ack
[15:59:58] DEBUG: status request
[15:59:58] DEBUG: wait for ack
[15:59:58] DEBUG: wait for ack/nack
[15:59:58] DEBUG: receive ack
[15:59:58] INFO: 

New Token is 0x0
[15:59:58] INFO: Download complete
[15:59:58] INFO: Verifying Data...
[15:59:58] INFO: get file
[15:59:58] DEBUG: enter get file info
[15:59:58] DEBUG: wait for ack
[15:59:58] DEBUG: status request
[15:59:58] DEBUG: wait for ack
[15:59:58] DEBUG: sending start download command
[15:59:58] DEBUG: Granularity conversion: G(256) * N(20) = 5120
[15:59:58] DEBUG: Access code is 0
[15:59:58] DEBUG: wait for ack/nack
[15:59:58] DEBUG: receive ack
[15:59:58] DEBUG: get chunk
[15:59:58] DEBUG: wait for ack
[15:59:58] DEBUG: Receiving chunk of 4096 bytes
[15:59:58] DEBUG: status request
[15:59:58] DEBUG: wait for ack
[15:59:58] DEBUG: get chunk
[15:59:58] DEBUG: wait for ack
[15:59:58] DEBUG: Receiving chunk of 792 bytes
[15:59:58] DEBUG: status request
[15:59:59] DEBUG: wait for ack
[15:59:59] DEBUG: wait for ack/nack
[15:59:59] DEBUG: receive ack
[15:59:59] INFO: Done. Reading 4888  bytes
[15:59:59] INFO: 

Verification OK
[16:00:00] INFO: > Updated Token value: 0x0
[16:00:00] INFO: > File name: /cert/ca.pem, Update: false, Erase: false
[16:00:00] INFO: > File name: /cert/client.pem, Update: false, Erase: false
[16:00:00] INFO: > File name: /cert/private.key, Update: false, Erase: false
[16:00:00] INFO: > File name: /sys/macadd.bin, Update: false, Erase: false
[16:00:00] INFO: > File name: /sys/mode.cfg, Update: false, Erase: false
[16:00:00] INFO: > File name: /sys/ipcfg.ini, Update: false, Erase: false
[16:00:00] INFO: > File name: /sys/ap.cfg, Update: false, Erase: false
[16:00:00] INFO: > File name: /sys/devname.cfg, Update: false, Erase: false
[16:00:00] INFO: > File name: /sys/mdns.cfg, Update: false, Erase: false
[16:00:00] INFO: > File name: /sys/dhcpsrv.cfg, Update: false, Erase: false
[16:00:00] INFO: > File name: /sys/httpsrv.cfg, Update: false, Erase: false
[16:00:00] INFO: > File name: /sys/pref.net, Update: false, Erase: false
[16:00:00] INFO: > File name: /sys/smartconfigkeys.cfg, Update: false, Erase: false
[16:00:00] INFO: > File name: /sys/stacfg.ini, Update: false, Erase: false
[16:00:00] INFO: > File name: /sys/p2p.cfg, Update: false, Erase: false
[16:00:00] INFO: > File name: /sys/pmcfg.ini, Update: false, Erase: false
[16:00:00] INFO: > File name: new file/thefemaleform.jpg, Update: true, Erase: true
[16:00:00] INFO: > Erase File: new file/thefemaleform.jpg
[16:00:00] INFO: erasing file "new file/thefemaleform.jpg"
[16:00:00] INFO: deleting file "new file/thefemaleform.jpg"
[16:00:00] DEBUG: wait for ack
[16:00:00] DEBUG: status request
[16:00:00] DEBUG: wait for ack
[16:00:00] DEBUG: Error -11 : File not exists
[16:00:00] INFO: erase file completed
[16:00:00] INFO: > Size of file = 372188
[16:00:00] INFO: > Update File: new file/thefemaleform.jpg
[16:00:00] INFO: Downloading file "new file/thefemaleform.jpg" with size 372188
[16:00:00] DEBUG: sending start download command
[16:00:00] DEBUG: Granularity conversion: G(4096) * N(91) = 372736
[16:00:00] DEBUG: Access code is 3
[16:00:00] DEBUG: wait for ack/nack
[16:00:18] DEBUG: UART timeout
[16:00:18] DEBUG: --- received unexpected data!!!!!
[16:00:18] INFO: > Executing Operation: Disconnect
[16:00:18] DEBUG: disconnecting from device . . . 
[16:00:18] DEBUG: wait for ack
[16:00:22] Operation Program returned.

    I appreciate your help debugging and feel like we are on the way to resolving this issue.  How do you suggest we find the root cause of the issue? Should we investigate my connection to the SFLASH or the SFLASH IC? I am confident that the SFLASH chip is compatible, but I am open to any and all suggestions.

     

  • 0 in reply to Prajay Madhavan
    Prodigy 220 points
    See the previous post for additional details.

    Our design currently incorporates a 16MB SFLASH part that operates at 108MHz. This part was chosen from a list of compatible parts found in another post on this forum which can be found at the link below:

    e2e.ti.com/.../1262696

    Actual SFLASH part details below:

    Memory size: 128Mb
    Speed: 108MHz
    Manufacturing Part Number: N25Q128A11ESE40G
    Digi-Key Part Number: 557-1572-5-ND

    We also have an alternate 2MB SFLASH part that was prepared for our design, but it is not the part being tested in the prototype nor is it one that can be found in the compatibility list. It was evaluated based on the command list presented in the same forum post. We could test this part to check is the error still persists. The details of this part can be found below:

    Memory size: 2Mb
    Speed: 108MHz
    Manufacturing Part Number: M25PX16-VMN6TP
    Digi-Key Part Number: M25PX16-VMN6TPTR-ND
  • 0 in reply to Joshua Cox
    TI__Guru 64455 points

    Hi Joshua,

    Thanks for the details info. For some reason I'm not able to open the saleae files but I think I know what the problem is.

    As suspected, I believe it is related to the erase time of the 4KB sub-sector.

    Uniflash assumes a worst case of 200mSec per block multiply by the number of blocks or 15 seconds, the maximum.

    So let's take as an example the 131072 bytes. You can see from the log it takes ~8 seconds:

    [09:25:47] DEBUG: Granularity conversion: G(1024) * N(128) = 131072

[09:25:47] DEBUG: Access code is 3

[09:25:47] DEBUG: wait for ack/nack

[09:25:55] DEBUG: receive ack

    Calculating per block yields in 8000/(131072/4096) = 8000 / 32 = 250mSec.

    Looking in the data sheet, it is the same typical value for sub-sector erase. The max value is 800mSec.

    So, it is a very slow serial flash in terms of erasing blocks.

    Now let's calculate the same for the larger file. The size is 372188. Taking 250mSec yields 372188/4096 * 250 = 23 seconds!!! Uniflash waits for 18 seconds, hence the timeout.

    Please note there is always a tradeoff. If we increase this time per block it would mean larger timeout in case of UART issues. So, it may be a good idea to make it configurable somehow.

    I'll think of a way to verify my theory and let you know.

    Regards,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Prodigy 220 points

    Thanks for your input! I will fix the  saleae files so they can be opened and also work towards testing this theory.

    With regard to the theory that the flash being slow is where the error is originating. I have the following questions:

    • Is there away around this issue? 
    • Should we consider an alternate Flash IC?
    • Does this have other non-obvious detrimental implications?

    Thanks for your continued support and we look forward to your reply! 

  • 0 in reply to Joshua Cox
    TI__Guru 64455 points

    Joshua,

    You can use this flash, just need an updated Uniflash to support it.

    Attached is a library FlashAPI.dll. Can you please replace your current file with this one and check?

    It is under .\eclipse\plugins\com.ti.uniflash.wireless.files_1.0.0.201502021424\cc3xxx\bin (save a copy of the original one).

    This one is with larger delay and should be enough in your case.

    If it fixes your issuehttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/968/FlashAPI.dll, can you clarify if this is good enough (since Uniflash is released once in a few months and we just released one)?

    Regards,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Prodigy 220 points

    I tested the solution you posted and the situation improved slightly. The fix allowed me to program the much larger file onto the cc3200 with my current version of Uniflash. Below shows that it waited at least 22 seconds before receiving the ACK.

    [08:04:18] INFO: erase file completed
[08:04:18] INFO: > Size of file = 372188
[08:04:18] INFO: > Update File: new file/thefemaleform.jpg
[08:04:18] INFO: Downloading file "new file/thefemaleform.jpg" with size 372188
[08:04:18] DEBUG: sending start download command
[08:04:18] DEBUG: Granularity conversion: G(4096) * N(91) = 372736
[08:04:18] DEBUG: Access code is 3
[08:04:18] DEBUG: wait for ack/nack
[08:04:40] DEBUG: receive ack
[08:04:40] DEBUG: send chunk

    The problem is still present with updating the service pack however, the timeout period is still set to 15 seconds.

    [08:19:46] INFO: Downloading file "/sys/servicepack.ucf" with size 6100
[08:19:46] DEBUG: sending start download command
[08:19:46] DEBUG: Granularity conversion: G(1024) * N(128) = 131072
[08:19:46] DEBUG: Access code is 3
[08:19:46] DEBUG: wait for ack/nack
[08:20:01] DEBUG: UART timeout

    I tried opening the files I posted earlier and it worked fine, so it may just be a software difference. The hardware I am using in my test is the Seleae Logic 4 it's compatible software, Seleae Logic 1.1.34 Beta. It can be found at this Link.

    There is no problem implementing this solution provided it works.

    What needs to be done to edit the timeout period for the service pack?

  • 0 in reply to Joshua Cox
    TI__Guru 64455 points

    Joshua,

    If it is OK, then I can provide a new DLL to fix it. However, it would need to wait for Sunday.

    You still see 15 seconds with Service Pack is that 131072/4096 * 400mSec = 12.8 seconds which is less than the default 15 seconds so Uniflash picks 15 seconds timeout. However, Service pack is actually twice the size as it also has rollback (which is not part of the formula). Taking it into account yields a 262144/4096 * 250mSec = 16 seconds in your case which is larger than 15 seconds.

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Prodigy 220 points

    Shlomi,

    Sounds great! I am glad we are still making significant progress.

    Please Correct me if anything below is incorrect:

    • You don't currently need anymore information from us to perform the fix.
    • The current problem is that UART times out during the service pack update.
    • Uniflash UART timeout period does not account for the rollback which double size.
    • Uniflash currently calculates the timeout without the rollback, thus Uniflash calculates the file size which is less then the default 15 Seconds.
    • Due to the time being calculated is less then the default 15 Seconds, Uniflash timeout is set to 15 seconds default.

    Solution:

    Your suggested solution is for us to wait until Sunday(3/1/15). On Sunday you will provide to us an updated DLL file which should adjust the timeout of the UART during the service pack update.

    Additional Thoughts:  

    • We are currently assuming that the inability to update the service pack is also causing the inability to use the radio tool.
    • We are unsure if is safe to assume that WIFI not working could be related to this issue.
    • Our goal is that updating the service pack will allow the use of the radio tool which could uncover why the WIFI is not working properly.

    Thanks again for your continued support!

  • 0 in reply to Joshua Cox
    TI__Guru 64455 points

    Joshua,

    Yes, I confirm all items above.

    On Sunday you would get a fixed DLL for testing.

    Regards,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    TI__Guru 64455 points

    Joshua,

    Please find attached an updated library. Should fix the Service Pack issue.

    Give it a try and report back.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/968/8176.FlashAPI.dll

    Thanks,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Prodigy 220 points

    Shlomi,

    I have tried the DLL the file that you have posted and thankfully it has solved the issue with updating the service pack issue. Updating the service pack did resolve the issue with using the radio tool also. Unfortunately though, this did not help with the initial WiFi issues we have been having. We tried the 31xx/32xx Radio Tool 1.0 after updating the service pack and it was able to grab the ROM Ver., FW Ver., and MAC details which did not happen before, but using a spectrum analyzer it seems that the RF output of the cc3200 is in the lower 500MHz frequency.  

    Steps taken to test WiFi using Radio Tool:

    • Open a new UCF target configuration for the cc3200 and Formatted the SFLASH memory for 1MB
    •  Applied the Service Pack Bundle 1.0.0.1.2 bin file, which completed successfully.
    [15:28:19] INFO: Downloading file "/sys/servicepack.ucf" with size 6100
[15:28:19] DEBUG: sending start download command
[15:28:19] DEBUG: Granularity conversion: G(1024) * N(128) = 131072
[15:28:19] DEBUG: Access code is 3
[15:28:19] DEBUG: wait for ack/nack
[15:28:24] DEBUG: receive ack
[15:28:24] DEBUG: send chunk
[15:28:24] DEBUG: wait for ack
[15:28:24] DEBUG: status request
[15:28:24] DEBUG: wait for ack
[15:28:24] DEBUG: send chunk
[15:28:24] DEBUG: wait for ack
[15:28:24] DEBUG: status request
[15:28:24] DEBUG: wait for ack
[15:28:24] DEBUG: wait for ack/nack
[15:28:24] DEBUG: receive ack
[15:28:24] INFO:

New Token is 0xCBD46394
[15:28:24] INFO: Download complete
[15:28:24] INFO: > Executing Operation: Disconnect
[15:28:24] DEBUG: disconnecting from device . . .
[15:28:24] DEBUG: wait for ack
[15:28:24] Operation ServicePackProgramming returned.

    • We programmed the cc3200 chip with the radiotool.bin file provided with the Radio Tool, which was also completed successfully. The erase, update, and verify option was checked during the programming operation.
    • After removing the SOP2 jumper, we tried to run the Radio Tool the console debug information is shown below:
    [3/3/2015 4:02:07 PM] Program Ready, version 1.0.5358.30883
[3/3/2015 4:02:30 PM] Connecting...
[3/3/2015 4:02:30 PM] Connected
[3/3/2015 4:02:30 PM] Fetching Information
[3/3/2015 4:02:30 PM] Chip ID=0x10 (CC3200R), ROM_ver=0x3333, FW_ver=2.2.0.1.31.1.2.0.2.1.0.3.23, MAC=54:4A:16:29:AF:0F
[3/3/2015 4:02:58 PM] Tx Testing Started
[3/3/2015 4:04:32 PM] Tx Stopping...
[3/3/2015 4:04:32 PM] Tx Testing Finished

    Results:

    Probing the output of the micro-controller(between the filter and the RF pin):

    • There seemed to be no significant signal existed at the correct frequency. Rather when altering between turning the TX on and off the content seemed to be in the sub 500 MHz. 

    Probing after the filter - Connected to Murata RF connector - Resistor removed(disconnected the antenna) - Using Preamp:

    • We could see a small correlation of approximately -62Dbm(with an amplifier) at 2.402Mhz with the start and stop of the test with the following setting as continuous mode, Rate - 1 Mbps (DSSS), and all other setting as default.

    Note: When running these test with the launchpad all the frequency content was in the correct area with significant power(no need for the amplifier). Our results show that nothing between the boards is similar with regard to the RF output and all the results look nothing short of wrong. 

    Recap:

    While using the radio tool and probing between the filter and the RF Pin on the microcontroller, no significant signal existed at the correct frequency. Rather when altering between turning the TX on and off the content seemed to be in the sub 500 MHz. Using the launchpad we noted that the signal was indeed at the correct frequency and much higher amplitude.

    What else have we tried?

    • Replaced the IC – Same outcome
    • Tested Clocks – is working correctly

     

  • 0 in reply to Joshua Cox
    TI__Guru 64455 points

    Hi Joshua,

    Thanks for the update. It is good that all Uniflash issues are now solved.

    With the Radio Tool, it does seem that the right version is read from the device.

    Now it looks as if yoy are experiencing pure radio issues. Let me loop in Vivek for further analisys.

    Regards,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    TI__Guru 58035 points

    Hello Joshua,

    Can you probe the voltage level on the device pin 33 ( which is the C 42 on the Launch pad board)  during the transmission? It would be helpful if you probe it using an ossiloscope since you might see the voltage go low in between. I am interested in knowing the voltage level when you see the level is high.

    You can also measure the voltage on pin 48 (C 31 in the Launchpad).

     

    Regards,

    Dham

  • 0 in reply to Vivek Dham
    Prodigy 220 points

    Dham,

    Thanks for dropping in. I have measured the voltages and checked over the circuit. In doing so I may have may have found the culprit of our issue, but I'll let you weigh in on if this is the issue.

    Pin 33:

    • TX ON: 1.92V
    • TX OFF:  ~0V

    Pin 48:

    • TX ON: 1.96V
    • TX OFF: 1.96V

    I tested this with the launch pad and noticed a difference in the waveform on pin 48. I checked over the Schematic and noticed that mistakenly Pin 36 (LDO_IN1) has been left not connected(NC) when it should have been shorted to Pin 25 (LDO_IN2).

    Our waveform on Pin 48 is a constant DC voltage(no waveform) during TX ON while on the launchpad this is not the case. 

    Launchpad Pin 48 TX On image below:

    Update:

    Improvements were verified by connecting the LDO_IN1 and LDO_IN2 pins on our circuit. We programmed the cc3200 with the wlan_ap example and the test SSID showed up on our WiFi enabled devices.

    Note: All voltage outputs on PIN 48 and 33 look identical.

    Testing the RF output yielded positive results. See image below for output from the RF switch. 

    Problems:

    For some reason the prototype does not allow any stable/permanent connections in AP mode. It also does not connect to any external AP routers in station mode. We tested RX input using the Radio Tool and noticed that we received some valid packets, but there were also some occasional FCS Errors. We still need to do further testing on our end to provide the most amount of information as possible, but we would appreciate any suggestion that could help us further pinpoint the root of the issue.

    Plans:

    We will investigate any differences between the output of our board and the Launchpad on the RF pin with the spectrum analyzer. Our guess is that a problem exist between the RF pin and the antenna.

    Can you provide any documentation or information about how to characterize and tune the radio and antenna circuit using the RF switch / test-port?

    Additional Details:

    I thought I would add that the only difference in our RF antenna design is how we implemented our RF switch.

    The thought is that this allows us to test both RX and TX depending on how we populate the resistors:

    Normal:

    • R7 - DNI
    • R3 - DNI
    • R8 - 0 ohm

    Radio:

    • R7 - 0 ohm
    • R3 - DNI
    • R8 - DNI

    Antenna:

    • R7 - DNI
    • R3 - 0 ohm
    • R8 - DNI

    I have no reason to believe this difference is the source of the problem. I was including the details in-case it may be valuable to the debugging procedure. 

  • 0 in reply to Joshua Cox
    TI__Guru 58035 points

    Hello Joshua,

    You rightly mentioned that the RF problem was due to not connecting LDO_IN1. This would mean some of the RF section was not getting any supply. Glad to hear that after fixing this you are now able to see the RF output on the sepctrum analyzer and Rx is also working.

    About the AP connection issue, can you check what is the ppm error on the reference clock? If you have a WLAN analyzer you can trasnmit a paclet (say 54OFDM) using radio tool and recevie it in the WLAN Analyzer and that would indicated the center freqency error or ppm error. The ppm error should be < 25ppm for proper communication between the transmitter and recevier.

    If you dont have a WLAN analyzer you can use the radio tool to transmit a CW and select tone '1'. This would transmit a RF tone at 312.5Khz away from the center frequency. ie if you tune to channel 1 (2412 Mhz) this would transmit a unmodulated tone at 2412.3125 Mhz. You can measure this frequency on the spectrum analyzer and see the error from the expected frequency. This error should be less than 25ppm ( ie < 60khz). For accurate measurement use a low span and low RBW (<1Khz ) on the spectrum analyzer.

    The ppm error would depend on the load capacitance on the 40Mhz XTAL connected to pin 22/23 (including the parasitic capacitance on teh PCB). If the frequency if off you might need to adjust the shunt cap on the XTAL P/ M pins to center the frequency and reduce the error.

     

    Regards,

    Dham

     

  • 0 in reply to Vivek Dham
    Prodigy 220 points

    Dham,

    We are working! Caps did the fix. We do, however, have just a few more questions. I have tried flashing the SFLASH with a 'Debug' configured version of our firmware using Uniflash, and even though the operation was successful, the board showed no signed that the firmware was operating correctly. Everything is fine however if a 'Release' configured SDK example is flashed instead. Would the difference between Debug and Release cause any issues on how the program works after being flashed with Uniflash?

    Also how can we get our hands on the TI software development kit (SDK) for HomeKit? We just joined the MFi Program and want to break ground on this development ASAP.

    I again want to say Thank you for your teams time and support. Your teams skill-sets are invaluable!

    THANK YOU.

  • 0 in reply to Joshua Cox
    TI__Guru 64455 points

    Joshua,

    I'll find out regarding HomeKit.

    Regarding Debug mode, as I can see, SDK examples include only release mode. Haven't tried myself to work in debug but since you are flashing it to the serial flash, why do you need a debug version?

    Please note that the elf output needs to be converted to a binary using the tiobj2bin utility. Make sure you get a binary. Also, the size for debug is probably much larger than the one for release. Make sure it can fit to the available space in the serial flash (on production device should be up to 240KB).

    Regards,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    TI__Guru 64455 points

    Joshua,

    As I understand, TI representative has communicated you regarding HomeKit.

    What about the debug item? is it OK? if so, please let me know so I can close this thread.

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Prodigy 220 points

    Shlomi,

    Thanks for your help! All our issues are resolved and this thread can be closed.