Status 1 in response to nvmem_read

Hi Alexander, 

I tried two nvmem_read calls:

iReturnedValue = nvmem_read(NVMEM_WLAN_CONFIG_FILEID, 6, 0, sensorContent);
iReturnedValue = nvmem_read(NVMEM_MAC_FILEID, MAC_ADDR_LEN, 0, sensorContent);

The return value for both of them was 0, but the buffer was filled with the requested information.  Did you check the buffer content to see if there was any data there? 

Pedro 

Yes I did. The buffer content wasn't altered within the nvmem_reads.

From the spi packet I've sent in the previous post (the latter 5 bytes) and from the definition of  hci_evnt_hdr_t: 

{

unsigned char ucType;

unsigned short usEvntOpcode;
unsigned char ucLength;
unsigned char ucStatus;
} hci_evnt_hdr_t;

it follows that ucLength == 1 and ucStatus == 1 which probably should mean that there's no actual data present

Are your getting anything when sending this API:

nvmem_get_mac_address(unsigned char * mac)

 Are you able to send other commands like wlan_connect? 

Pedro

I'm not getting anything either.

I am able to connect to an access point though. The MAC for the tiwi-sl that appears on AP is strangely (hex) 00 12 55 55 55 55

Hi Alexanders, 

It appears that the EEPROM might not have the correct service pack, can you try using the patch programmer:

http://www.ti.com/lit/zip/SWRC254A

Pedro

I've tried using patch programmer. I'm using neither of the evaluation boards, so I had to port the code

Patch programmer uses nvmem_write_patch which relies on nvmem_write

I've tried writing driver and firmware patches obtained from patch programmer (wlan_drv_patch and fw_patch)

nvmem_write responds with an spi event packet of 14 bytes: 5 bytes of spi header + 4 bytes of hci event header with usEvntOpcode == HCI_EVNT_NVMEM_WRITE, ucLength == 5 and 5 final bytes are equal to 00 01 10 00 00 

I've used wlan_stop + delay + wlan_start after writing patches

The nvmem_read after that behaves identically to what I described in previous posts. 

I've also tried writing MAC with nvmem_write with the same effect after patch update. The MAC address that appears on access point is still 00 12 55 55 55 55

I've also tried using the mechanism of passing patch function pointers to wlan_init and then calling wlan_start(3) (3 - number of availiable patches). The tiwi-sl responds with several patch requests and patches are sent via hci_patch_send to tiwi-sl. The behaviour is still the same after this procedure

Alexander,

You are doing the nvmem_read() OK but the response of 0x1 can happen only in case there is something wrong with the I2C communication between the CC3000 and the EEPROM.

If you had the EEPROM with no allocated/valid flags on, you would get an error of 0x3.

Can you validate it?

Shlomi

thanks for the feedback Alexander.

My qustion is that able to execute nvmem_set_mac_address(unsigned char * mac), execute wlan_connect();but execute nvmem_get_mac_address(unsigned char * mac)  hang.

Hi yong,

Are you having a problem with get_mac_address, or you are not able to set a MAC address? nvmem_get_mac_address should work straight away. But anyway, try the below and let me know.

nvmem_set_mac_address(&mac[0]);

wlan_stop();
delay...

wlan_start(0);

Then mask unwanted events using..
 wlan_set_event_mask(HCI_EVNT_WLAN_KEEPALIVE|HCI_EVNT_WLAN_UNSOL_INIT|HCI_EVNT_WLAN_ASYNC_PING_REPORT);

Connect to the AP using wlan_connect()..

Then read the MAC address.. nvmem_set_mac_address(&read_mac[0]);

Thanks & Regards,

Raghavendra

Hi Raghavendra

Thanks for reply.

I have solved that problem,The reason is missing a interrupt before SimpleLinkWaitData(buff,0,0 ),causes the program to enter the infinite loop.

I check IRQ in the funcation of  unsigned char * hci_event_handler(void *pRetParams, unsigned char *from, unsigned char *fromlen), if tSLInformation.ReadWlanInterruptPin() == 0, indicate interrupt occurred., then I trigger   IntSpiGPIOHandler( ).

But now I encountered a new problem,when call recvfrom( ) to receive data,more than one minute data not received, then recvfrom( ) return -57, no longer receive data up.

Hi yong,

May I know what exact sequence you are following leading up to recvfrom? Are you providing the remote with listening port and your acquired IP?

Thanks & Regards,

Raghavendra

Tanks for reply.

Before recvfrom( ),I use to socketopt( ) and bind( ).

I'm using a microcontroller STM8S,I feel the problem is SPI driver.  

Hi yong,

Are you receiving interrupt from the CC3000 where there is data to be received? Can you please check?

Thanks & Regards,

Raghavendra