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.

Incorrect data received from CC3000

Hi guys,

           I am porting CC3000 to another MCU. DUring the port I observed that the CC3000 is returning incorrect data for the CC3000 ->> Host - HCI_CMND_SIMPLE_LINK_START command complete. I receive a 0xFF at a place where I am not supposed to receive it. What am I doing wrong?

  • Hi Sab VS,

    first picture does not look bad, second and third picture is the same as in first picture, but cut in two pieces?

    Which 0x02 do you think is wrong?

    Can you record the complete init sequence into 1 logfile and upload it?

    Best regards,

    Martin

  • Hi,

    I made a mistake while uploading the images and also wrote 0x02 instead of 0xFF. I have edited the question. Please take a look now. The 0xFF after the 0x00 in the third picture is what is incorrect. 

    Also with respect to the last question, I am relatively new to Salae. Do you mean export as CSV?

  • The first picture looks like it is equal to third picture.

    Check WLAN_ENABLE, move it only once at startup and not more later. Otherwise a new startup is needed.

    I am still missing a logic analyzer trace where the complete startup can be seen.

    Perhaps print the bytes which you send and which you receive. It is easier to handle then data in logic analyzer trace.

  • I am making too many mistakes right now. Anyway I have uploaded the right pictures now. The enable is actually the Chip select. I haven't renamed it correctly.

    I have attached the .txt file. 

    Time [s],Packet ID,MOSI,MISO
    14.0295679583333,0,0x01,0x02
    14.0295739583333,0,0x00,0x00
    14.02958,0,0x05,0xFF
    14.02958625,0,0x00,0x00
    16.1608377083333,0,0x00,0x00
    16.16084375,0,0x01,0x00
    16.16084975,0,0x00,0x00
    16.160856,0,0x40,0x00
    16.1608625,0,0x01,0x00
    16.1608685416667,0,0x00,0x00
    21.4375156666667,,0x03,0x02
    21.4375216666667,,0x00,0x00
    21.4375276666667,,0x00,0xFF
    21.4375339166667,,0x00,0x00
    21.4375404583333,,0x00,0x00
    21.4375464583333,,0xFF,0x00
    21.4375524583333,,0xFF,0x00
    21.4375584583333,,0x00,0x00
    21.43756475,,0x00,0x00
    21.43757125,,0x02,0x00
    

  • In second picture the line 4 (labeled as ENABLE, as you have written, it is CS), seems to be not stable???

    There are two lines: one on bottom, one a bit higher in the middle???

    Can you also record additionally WLAN_ENABLE?

    Can you also upload the raw SALAE logic analyzer trace (after capturing with WLAN_ENABLE), not only pictures or exported data, so i can look at it myself? I already have the viewer installed on my PC.

  • Please find the capture file attached. I set a break point at the last part after serial transmission so you wont see chip select going high again.

    	Data save6nʚ;���OǺ�\��>�ԙ��OǺ�\���	Channel 0OǺ�\���E�	Channel 1OǺ�\����	Channel 2OǺ�\�����VBAT_ENABLEOǺ�\�����CHIP_SELECTOǺ�\����MOSIOǺ�\����MISOOǺ�\��� ��CLOCKTTTTTTTEdge FinderT
    State 1������������������������Tʚ;Tʚ;���TOǺ�\����;��;a	TTTT6nOǺ�\����;��;��;��;��;��;��;��;�	�M�0�	�����������;C��\�#�E�H��������������y	y		��;!M��R�#			��¼��Ό���M2�h�ʈ.�~}�������������HZ�H'�H��H�5:6�6�6�7�7�G�.H�M�
    ��;[I��V�#H�H�������˫H����Ē:��;����������˫H�H��H�D�D�G��G���;'M��R�#===��������6��������6��������<����������������6��������7��������6��������6��������6����������������<��������B��������6��������6��������6��������=��������B��������6��������6��������0ʈ��~>��T�$$$��������ʫH�H
    	r�H��H�H('��H21ɭH<;ۭH>5?U5IH�5SR�5]\j6gf�6qp7{z~7���7��&8��D8��G���G���FH����H����H���fI����I���J���zJ����J���)K�eK��K�IL� �L�*)�L�43OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��6nSPI�22 serialization::archive 5 17 SaleaeSpiAnalyzer 0 8 15831812250785204047 5 15831812250785204047 6 15831812250785204047 7 15831812250785204047 4 0 8 0 1 0T

    Also I have renamed the file as a .txt since otherwise I cant upload it here. Please rename it to .logicdata and then open with the logic analyzer.

  • Hi,

    many thanks for the trace. I don't see anything, you are making wrong, but answer from CC3000 looks wrong. Like it has restarted? I have not looked/compared if timing is correct. Please do this yourself.

    Can you add also the interrupt line to your capture and upload a trace again?

    When you read a frame, there is usually one 0x03 at the beginning, but you can always send a 0x03 on SPI. This makes analysis a bit easier.

    By the way: Which host uC are you using (perhaps already written above)?

    Have you some C near power supply of CC3000? What voltage/max. current does your power supply deliver?

    Best regards,

    Martin

  • Hey there,

    Sorry for the late reply. Please find the new trace attached. I am using the renesas RL78 microcontroller. I am also using the adafruit breakout board tested with the Arduino which seems to work okay http://www.adafruit.com/products/1469

    	Data save6nʚ;���OǺ�\����OǺ�\���	Channel 0OǺ�\���E�	Channel 1OǺ�\����IRQOǺ�\�����VBAT_ENABLEOǺ�\�����CHIP_SELECTOǺ�\����MOSIOǺ�\����MISOOǺ�\��� ��CLOCKTTTTTTTEdge FinderT
    State 1������������������������Tʚ;Tʚ;���TOǺ�\����;��;�	TTTT6nOǺ�\����;��;��;��;��;��;[�a�@(���fhQ�w�����������;�
    Y��.�
    ����������;��a	@(�
    T:���G���������T:�mI��a	��;�a�@(			���Ɍ�Ȍ� ��S!�n9���fcBM���������.?�j?�7@��@��F��F��G��G�hH��H��a.�a�a
    ��;�a@(I�H����������>��[�:�֯�����������>�/?�jI�������a�a��;"�a�@(===��������6��������7��������6����������������<��������B��������6��������6��������6����������������6��������6��������6��������<��������B��������6��������6��������6��������<���������O���fc�L�$$$���������>�?�
    	�?��?�+@�('�@�21�@�<;�@�>�E�?�E�IHoF�SR�F�]\$G�gf�G�qp�G�{z8H����H����H����H����a�ڕa��F�a����a���a��[�a����a��	�a����a����a��*�af�aҙa>�a z�a*)�a43OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��OǺ�\��6nSPI�22 serialization::archive 5 17 SaleaeSpiAnalyzer 0 8 15831812250785204047 5 15831812250785204047 6 15831812250785204047 7 15831812250785204047 4 0 8 0 1 0T

    Once again you would have to rename it to see the data. Thanks a lot for your help. I really appreciate it since  I have no clue what I am doing wrong.

  • Hi,

    i had a look on your trace, but must say sorry: I can't see what is wrong. Looks like as CC3000 does not behave as it should.

    One special thing i have seen already in your last trace and again in this trace: There is a level change on MISO line (data line from CC3000) just before IRQ goes down the second time. But this is much later. Too late.

    How have you connected the CC3000? Do you have a schematic?

    Can you check how you have connected WL_EN1 and WL_EN2? Are they both connected, but not connected to anything? Have you connected Reserved_1 and Reserved_2 to anything?

    Can you check if and where you have VIO_HOST, VBAT_IN, ... perhaps check against your working environment (adafruit).

    Best regards,

    Martin

  • This is the schematic that I am using(http://learn.adafruit.com/system/assets/assets/000/010/985/original/adafruit_products_cc.png?1379351147).

    I also observed the glitch. But I have enabled a Pull up resistor on the MCU side. So it appears that the cc3000 is indeed pulling it low. But the surprising thing is the board works with the Arduino. SO it is not a board problem. But I cant find anything I am doing wrong either. 

    I am also using the platform independent host driver interface. However according to the wiki the command that should be going out is not what I observe on the scope. Maybe its an updated version? I see  0xFF 0xFF 0x00 0x00 0x02 going out.  But according to the wiki this is not what should be goiung out - http://processors.wiki.ti.com/images/8/88/2CC3000.png

    But then again this should not really matter since the response is wrong well before this? Any ideas about this?

  • @TI

    Please continue here with new ideas and internal knowledge what could be wrong!

  • Some more ideas:

    - I don't know the RL78. What voltage(s) do you feed into RL78 (5V, 3.3V)? What voltage does the RL78 use on SPI? Is it different from "main power supply" of RL78 (perhaps internal regulator for voltage of SPI/GPIO)?

    - There is a level shifter on the adafruit board for signals to CC3000. So it looks like the signals on adafruit board to CC3000 need to have 5V level, but signal coming back from CC3000 seems to have 3.3V. Do I understand this correct? Do you have knowledge in hardware area, to decide that RL78 does deliver right levels?

    - There seems to be a voltage regulator on the adafruit board. What voltage do you feed into VIN (JP3 pin 7)?

    - Do you feed in something on VBAT (JP3 pin 8)?

  • Hi Sab,

    Yes, there is a glitch on MISO. Just to avoid any further problems, please check the ideal pull up resistor value on the host.

    Please also get the ideal clock from the master. It does look fine, but you can give it a try. Currently it is 2MHz. It can go upto 16 MHz.

    And also, the data over MOSI, which generates the clock for reading on MISO, seems to be wrong. If the host driver is the same one, but the data on the lines are different, makes me think MOSI also is behaving unconventionally.

    At the CC3000 side, just try flashing the patches again. And at the host, make sure you are using wlan_start(0).

    Thanks & Regards,

    Raghavendra

  • Hi Martin,

    Your advise really helped. I had orginally posted a question to Adfruit regarding this same Voltage shifting and had got this reply:http://forums.adafruit.com/viewtopic.php?f=19&p=230293. Looks like I grossly misunderstood what they were trying to tell me :-)

    So I thought it was all good. Apprently it looks like it wasnt. What was more preplexing was that the first command actually seemed to go through correctly so I was doubting that it was a software configuration issue and not really a hardware related one. 

    But once you wrote regarding the voltages I decided to give it another try. I directly connnected the CC3000 to 3.3V instead of the Vin. 

    Now I get an actual correct replies back from the cc3000. I really appreciate the help because without that statement I would not have gone back and double checked. 

  • Hi,

    this is good to hear that it is working now and thanks for your positive feedback!

    Best regards,

    Martin