porting PatchProgrammer_DR_Patch.c

Hi Derek,

there are 3 defines:

#define SL_PATCHES_REQUEST_DEFAULT      (0)
#define SL_PATCHES_REQUEST_FORCE_HOST   (1)
#define SL_PATCHES_REQUEST_FORCE_NONE   (2)

0 is with patches, 2 is for patch programmer,

1 not more used (this is what made problem in earlier patch programmer).

Check if you send the right value to CC3000!

Comment out SL_PATCHES_REQUEST_FORCE_HOST, compile and check if it still anywhere used!

Best regards,

Martin

I tried the FW patch, and it got stuck at the same place, below is the unmodified main loop from the TI PatchProgrammer_FW_Patch.c

I get stuck at the initDriver(0); exact same output as above.

I modified the code and changed this to initDriver(2); and it seems like everything has worked correctly, and my CC3000 will now work with initDriver(0);

I have also verified that CC3000 Firmware Revision is now 1.28. I don't understand how the flash programmers provided by TI could work without this change??

Thanks for all the help! I assume the patch programmer provided by TI actually works. It would be helpful to understand why it did not work for me without changing initDriver(0) -> initDriver(2) on line 8 in the below code.

void main(void)
{
	WDTCTL = WDTPW + WDTHOLD;
        
		
	// init board and request to load with no patches.
	// this is in order to overwrite restrictions to write to specific places in EEPROM
	initDriver(0);

	ucStatus_FW = 1;
	
	
	while (ucStatus_FW)
	{
			//writing FW patch to EAPRROM  - PROTABLE CODE
    	//Note that the array itself is changing between the different Service Packs   
    	ucStatus_FW = nvmem_write_patch(NVMEM_WLAN_FW_SP_FILEID, fw_length, fw_patch);
	}
    
  	turnLedOn(6);

	// init board and request to load with patches.
	initDriver(0);
        
  	turnLedOn(8);


}

Hi Derek,
to be able to patch CC3000 code (no matter if driver or firmware portion) you would have to start CC3000 by forcing it NOT to load patches from NVMEM/EEPROM (thus use initDriver(2)), meaning you cannot patch the code from which CC3000 is currently running. See also here for HCI_CMND_SIMPLE_LINK_START parameters.

Cheers,
Risto

Thanks for all the help Risto!

If someone from TI reads this, you should update the source code to fix this issue  :)

I have a similar problem. I am attempting to patch the driver code and then the firmware code. I have changed the first InitDriver(2) to InitDriver(0) and have changed the SL_PATCHES_REQUEST_FORCE_HOST to SL_PATCHES_REQUEST_DEFAULT. My code successfully completes the writes, but then gets stuck during the final InitDriver(0).

The last message sent from the CC3000 is the request for patches (the patch type requested is the FW type, which sorta makes sense, given that I haven't patched it yet), which I haven't modifed the TI library to answer to, so the code eventually hangs, as it was trying to do SimpleLink_Init_Start.

My question is, how should this be handled? Should we not attempt to do the final InitDriver(0) and just try to patch the firmware? That is, just do the second part of the update? 

Sorry everyone, typo in last message. The line in my SimpleLink_Init_Start function now reads:

UINT8_TO_STREAM(args, ((usPatchesAvailableAtHost) ? SL_PATCHES_REQUEST_FORCE_NONE : SL_PATCHES_REQUEST_DEFAULT));

per suggestions on this and other threads.

Progress!

I couldn't figure out why my code running on my platform hangs when doing an InitDriver(0) after patching just the driver. The TI code running on the TI board can apparently do this and NOT hang but I couldn't figure it out. No matter. I went ahead and instead did them together as one step rather than the 2-step process used by TI. This worked for me:

InitDriver(2)

Patch Driver 

Patch Firmware

InitDriver(0)

Check Version (which reports for me as 1C = 28 = latest version)

I hope this information is helpful.

-Josh