CC3220SF: Embedded Programming of PATCHES into the WiFi chip

Thank you Michael, the URL you provided is very helpful.

One other question, neither  SWPA230A or the URL you provided gives information on where to get the actual bootloader patch code used in steps 4-10.

Can you provide me a link to the bootloader patch code?

Thanks again, Glenn.  

Hi,

You find this files inside EMBEDDED-PROGRAMMING package.

Jan

Thank you Jan!

Michael,  I have started programming the SRAM with "BTL_ram.ptc". Is this the correct file? When I use this, the first chunk "get status" reported  "00 cc 00 03 40 40" which is correct. 2nd and 3rd chunk "get status" reported "00 cc 00 03 41 41". The documentation states that anything but 40 is an error, however it doesn't say what the error code means. Is there a listing somewhere of these error codes?

Also, when I ran the next steps, I was able to "Execute from RAM" and was able to Patch SFLASH using "BTL_sflash.ptc". Again, I got 40 on the 1st chunk and 41 on the second. I was was then able to start programming the image.  After I rebooted the system and tried to run again, the code runs to step 9, SFLASH erase (command 0x30), and then sends the host a NAK (0x33). The documentation is unclear as to why you get a NAK and what to do when you get it. Do you retry or send a different command? Is there information somewhere for when things don't go swimmingly?

Thanks, Glenn

    LOG_PRINTF(LOG_INFO,"Begin Image Programming...\r\n");

Another piece of info for my comment above.

After the SFLASH erase (command 0x30) responds with NAK, Get_STATUS responds with: 0 cc 0 3 50 50.

I don't know what error code 41 and 50 are....

I have uploaded the responses from the WiFi chip during programming
It looks good except the 41s,the 50s and not getting a 0 status at the end... <sigh>
Needless to say, the code did not reprogram the chip....
Any Ideas?

----------------------------------------------------------------------------

      INFO: INITIATING WIFI RE-PROGRAMMING!!!

INFO: WIFI_PROG_RAW_RCV: [cmd:0] Rsp[2]: 0 cc  
INFO: WIFI_PROG_RAW_RCV: [cmd:27] Rsp[3]: 0 cc 86  
INFO: WIFI_PROG_RAW_RCV: [cmd:33] Rsp[2]: 0 cc  
     WiFi Programmer Read Timeout 1000 ms! [cmd:0]
INFO: retry 1 netp <breaks>: -1
INFO: WIFI_PROG_RAW_RCV: [cmd:0] Rsp[2]: 0 cc  

INFO: WIFI_PROG_RAW_RCV: [cmd:31] Rsp[13]: 0 cc 0 a 29 10 0 0 19 0 0 0 0 
      INFO: ACK-step4: SRAM storage info, [cmd: 31] len=13

INFO: WIFI_PROG_RAW_RCV: [cmd:30] Rsp[4]: 0 cc 0 cc 0 
INFO: WIFI_PROG_RAW_RCV: [cmd:23] Rsp[6]: 0 cc 0 3 40 40 
      INFO: ACK-step5: SRAM erase status, [cmd: 23] len=6

INFO: WIFI_PROG_RAW_RCV: [cmd:2d] Rsp[4]: 0 cc 0 cc  
INFO: WIFI_PROG_RAW_RCV: [cmd:23] Rsp[6]: 0 cc 0 3 40 40  
      INFO: ACK-step6: SRAM 1st chunk status, [cmd: 23] len=6
INFO: WIFI_PROG_RAW_RCV: [cmd:2d] Rsp[2]: 0 cc  
INFO: WIFI_PROG_RAW_RCV: [cmd:23] Rsp[6]: 0 cc 0 3 41 41 
INFO: ACK-step6: SRAM 2nd chunk status, [cmd: 23] len=6
INFO: WIFI_PROG_RAW_RCV: [cmd:2d] Rsp[2]: 0 cc  
INFO: WIFI_PROG_RAW_RCV: [cmd:23] Rsp[6]: 0 cc 0 3 41 41  
INFO: ACK-step6: SRAM last chunk status, [cmd: 23] len=6

INFO: WIFI_PROG_RAW_RCV: [cmd:32] Rsp[4]: 0 cc 0 cc  
      INFO: step7: Executing from RAM

INFO: WIFI_PROG_RAW_RCV: [cmd:31] Rsp[13]: 0 cc 0 a 14 10 0 4 0 0 c2 28 16 
      INFO: ACK-step8: SFLASH storage info, [cmd: 31] len=13

INFO: WIFI_PROG_RAW_RCV: [cmd:30] Rsp[4]: 0 cc 0 33  
INFO: WIFI_PROG_RAW_RCV: [cmd:23] Rsp[6]: 0 cc 0 3 50 50  
      INFO: ACK-step9: SFLASH erase status, [cmd: 23] len=6

INFO: WIFI_PROG_RAW_RCV: [cmd:2d] Rsp[4]: 0 cc 0 33  
INFO: WIFI_PROG_RAW_RCV: [cmd:23] Rsp[6]: 0 cc 0 3 50 50  
      INFO: ACK-step10: SFLASH 1st chunk status, [cmd: 23] len=6
INFO: WIFI_PROG_RAW_RCV: [cmd:2d] Rsp[2]: 0 cc 0 0 0 0 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:23] Rsp[6]: 0 cc 0 3 41 41 0 0 0 0 0 0 0 0
INFO: ACK-step10: SFLASH last chunk status, [cmd: 23] len=6

       INFO: step11: Begin Image Programming...
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[8]: 0 cc 0 cc d7 dd f 40 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd f 40 0 0 0 0 0 0 0 0
INFO: Programming WiFi chip is Complete. Reseting WiFi Chip.
INFO: WiFi Module is in reset!

Hi Glenn,

Unfortunately there isn't much documentation regarding bootloader error codes beyond what is available in the Embedded Programming User's Guide.

How are you trying to program the patch files? Have you taken a look at the python scripts provided within the EMBEDDED-PROGRAMMING package? They demonstrate how to use those patch files and program them onto the CC3220.

Regards,

Michael

Hi Michael,

I am using both the document and the python scripts as reference.  For the SRAM patch, I first do the erasure for which I get the correct 0x40 back from the chip. I then write the first chunk of a 16 byte header plus the 4080 bytes of data and for this I also get the correct 0x40 response from the chip. I then write the 2nd chunk, same as the first, but then get 0x41. Both the document and the python script both expect the chip to responds with 0x40. The Python script simply aborts and the document provides no information about 0x41.

Can this be escalated to someone who would know what the error codes mean? It would be quite helpful in debugging this to know what the chip is trying to tell me. Thanks, Glenn. 

Hi Glenn,

I suggest if you haven't done so already, that you take a logic analyzer and capture the UART command flow between the CC3220 bootloader and your PC while using Uniflash to program or when running the python script. With the full capture, you should be able to compare the UART commands you are sending to the commands that Uniflash is performing and see if there is some discrepancy.

You most likely are not sending exactly what the bootloader expects, which is resulting in that error. I am not entirely sure what exactly that error code means, but unfortunately the engineer who wrote the embedded programming python scripts and the SWPA230A guide is out of office.

Regards,
Michael

Hi Michael,

We are going to run the python script and see if we can capture any differences in the chunk writes. It would still be helpful if you get the error code information from the engineer when he is back in the office. There are still many steps to debug and that information would be extremely helpful!

Thanks, Glenn.

Hi Michael,

Our engineers here were able to capture the python script's programming protocol. We mimicked this protocol and were able to get all the way through step 11 with the wifi chip sending the expected responses. After the very last chunk, the chip is suppose to send "0 cc 0 0 0 0" however we still get " 0 cc d7 dd 10 74" just on the last chunk. We have verified the data in this last chunk. (header and data matches what is sent by the python script). See our output below:

INFO: step11: Calculating checksum...
INFO: step11: Send chunk (4096)...
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc 0 2 c0 0
INFO: step11: Calculating checksum...
INFO: step11: Send chunk (4096)...
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc 0 2 d0 0
INFO: step11: Calculating checksum...
INFO: step11: Send chunk (4096)...
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc 0 2 e0 0
INFO: step11: Calculating checksum...
INFO: step11: Send chunk (3328)...
INFO: WIFI_PROG_RAW_RCV: [cmd:34] Rsp[6]: 0 cc d7 dd 10 74    <- should be zeros

We suspect a timing issue at this point and any information on what this code means would be extremely helpful.

Thanks, Glenn.

PS: An error code of 0x41 means a bad checksum.  

Hi Glenn,

The return code you get of 0xd7dd1074 from command 0x34 seems to be some form of file integrity error.

If you get an error from cmd 0x34, the first 16 bytes after the 0xcc ACK is a filesystem error number that can be referenced against source/ti/drivers/net/wifi/errors.h in the CC3220 SDK. In your case, you have 0xd7dd == -10275 or FS_PROGRAMMING_ILLEGAL_FILE. 

The second 16 bytes refers to the line number in the bootloader code at which the error was thrown. For you, that would be line 0x1074 or 4212. Unfortunately, the bootloader code for the CC3220 is not public but I looked at the source for you to identify what that line corresponds to.

At line 4212, the bootloader is checking the SHA1 hash of the file you just wrote, and comparing it against the expected SHA1 hash of the file from the file table of the .ucf file you are programming to the device. If it doesn't match, then it throws a FS_PROGRAMMING_ILLEGAL_FILE error. That means that for the file you are programming in step11, you most likely had some corrupt data passed on the UART interface during the file flashing sequence. The other potential cause would be if the file table in the .ucf file somehow had the wrong SHA1 hash for the file, but that can be tested for by running the .ucf you are programming through the embedded programming python tool released by TI and seeing if it works without an issue.

Please double-check your UART programming flow and ensure that the data passed to the CC3220 bootloader is not corrupt. Let me know if you have more questions on the internal operation of the bootloader.

Regards,

Michael

Thank you Michael!

That is very helpful information. The python script works fine with the .ucf file so  that points to an issue with the actual UART interface. We have some test equipment coming in this week which will allow us to better find what is flawed with the UART transfers. I will update the post once we have done some analysis on our side.  Again, thanks for your help! 

Glenn.

Hi Michael,

We corrected our timing issue and the WiFi chip no longer responds with illegal file error code. Also, we have verified all 47 chunk checksums against those generated by the python script. At the end of programming, the wifi chip generates the code:  "0 cc d7 fa b fc".

Hi Glenn,

Is the Uniflash project that your .ucf is coming from configured as a development mode project? For projects configured in development mode, many debug features such as JTAG access are unlocked and as a safeguard against such images being programmed into devices in a production environment there is the requirement that the .ucf contain the MAC address of the target CC3220 being programmed. If the MAC address doesn't match or is missing, then the SL_ERROR_FS_DEVELOPMENT_BOARD_WRONG_MAC error is thrown. The MAC address can be provided manually through the Advanced-> General -> Settings -> Original MAC address field in the Uniflash GUI if you want to retain development mode capabilities in your .ucf, but that step will need to be done for every device you are programming. For production line purposes, your Uniflash project should be set to production mode.

I suggest you double-check your Uniflash project to ensure that you are in production mode and not development mode, and then see if you are able to flash that new .ucf correctly.

Regards,

Michael

Hi Michael,

After recreating the .ucf file using production mode, our programming function is now operational!  Thank you again! We couldn't have done it without all your help!

One last question regarding the generation of the .ucf file. To get past the MAC_ERROR, we needed to be in production mode as you mentioned, but we also needed to specify a MAC of all FF's. Otherwise the python script (or our code) would only work on the device used to create the .ucf file. The problem with this is that it's changing all device MAC addresses to FF's. (See the uniflash settings below).  Would you know what the correct settings or procedure needs to be so that the .ucf file is independent of the MAC address?

Glenn.

Hi Glenn,

Good to hear that you have gotten the progrmaming process working with your code.

For the Uniflash project settings, you should be able to just tick the "Use device MAC Address" checkbox and let the CC3220 use its unique device MAC address. With TI's embedded programming python scripts, I am able to take a .ucf configured in Production mode with "Use device MAC Address" set and program multiple different CC3220SF devices without issue. 

I suggest you double-check that the ..ucf you are using to ensure that it is indeed in production mode. I would also try your .ucf with the TI-provided python scripts, to see if the problem lies with the .ucf or with your code.

Regards,

Michael