CC3220S: Uniflash stuck on API Blocked/File System Locked after incomplete programming

Hi Chris,

I've assigned this to an expert. Please give them time to respond to you.

Jesu

Thank you Jesu, looking forward to hearing from the expert.

Meanwhile, I'm going to try out the CC3x20_Embedded_Programming_2_0_0 package to see if I can get any further on an erase and reprogram since I'm stuck on Uniflash.

Regards,
Chris Norris

Does it happen on all your boards or on a specific one?

I've never seen the programming gets stuck in the middle (without an error). How long did you wait until you turned off the power (we heard about issues when turning off the power during programming).

Are you using the launchpad or a custom board?

If it is a custom board, have you gone through the design guidance and review process (https://www.ti.com/tool/SIMPLELINK-WIFI-DESIGN-REVIEWS) 

Br,

Kobi

Hi Kobi,

We started on LaunchPad, but now we're on a custom board having multiple processors.  Eventually we want our main processor (Tiva) to send the image to the wireless module (CC3220MODAS) without Uniflash so I am learning the bootloader commands from swpa230a.

During the early development, I have our main processor receiving and retransmitting the bootloader commands and replies between the PC and the CC3220S.  Our main processor functions as a serial cable replacement for this.  I am monitoring the bootloader commands and replies in a serial sniffer.  During the hang from above, my buffer size was too small (< 4096), so I accidentally sent an incomplete packet to the CC3220S.  I waited about 5 min before removing power, and I didn't see any other commands/replies from Uniflash in the serial sniffer.

I've watched the full programming in a serial sniffer, so I am confident I will eventually have a successful programming by replicating the same commands as Uniflash.

My question is about whether recovering from an incomplete programming is possible or not possible.  If this is a permanent lockout, I will need to be much more careful because I don't want to sacrifice too many boards while developing my programming method.

Yesterday I ran the ImageProgramming.py to try recovering the CC3220S in the locked out state.  Here is verbose output from the run.  It was able to transfer the BTL_ram.ptc patch to SRAM, but it got the same NACK when querying SFLASH status.

Image Programming v2.0.0
-----------------------------
This utility programs a binary image to a serial flash connected to CC3120/CC3220 device
Only production devices are supported (i.e. no pre-production devices)
The binary image needs to be prepared in advance using Uniflash utility

Step #1 --> connect to target device
port opened
wait and clear uart rx buffer
set break signal
--- please restart the device ---
wait for ack
receive ack
connection succeeded
get storage list
wait for ack
receive ack
receive storage list

exit bootldr connect
Step #2 --> Reading version info
port opened
wait for ack
receive ack
Reading version info completed

Bootloader version is (3, 0, 1, 0)
It's a CC3220S device
Step #3 (CC3220 only) --> Switch UART to NWP core
port opened
wait for ack
receive ack
Setting Break Signal
wait for ack
receive ack
Switch to NWP bootloader completed
RawStorageWrite
port already opened
Step #4/8 --> Get SRAM/SFLASH storage info
wait for ack
receive ack
Step #5/9 --> Erasing 11 blocks from SRAM/SFLASH starting from block #0
The process of erasing blocks takes several seconds
wait for ack
receive ack
Status request
wait for ack
receive ack
Erasing completed

Step #6/10 --> Program image[0:10531] to SRAM/SFLASH
wait for ack
receive ack
Status request
wait for ack
receive ack
wait for ack 38%
receive ack
Status request
wait for ack
receive ack
wait for ack 77%
receive ack
Status request
wait for ack
receive ack
Image programming completed

Step #7 --> Execute bootloader patches from SRAM
port opened
wait for ack
receive ack
wait for ack
--- COM Port timeout on ACK read
enter get storage info
port opened
wait for ack
--- error during get storage info
---Call Trace:---
File "C:\Python27amd64\Lib\runpy.py", line 174, in _run_module_as_main
"__main__", fname, loader, pkg_name)

File "C:\Python27amd64\Lib\runpy.py", line 72, in _run_code
exec code in run_globals

File "c:\program files (x86)\microsoft visual studio\2019\community\common7\ide\extensions\microsoft\python\core\debugpy\__main__.py", line 45, in <module>
cli.main()

File "c:\program files (x86)\microsoft visual studio\2019\community\common7\ide\extensions\microsoft\python\core\debugpy/../debugpy\server\cli.py", line 430, in main
run()

File "c:\program files (x86)\microsoft visual studio\2019\community\common7\ide\extensions\microsoft\python\core\debugpy/../debugpy\server\cli.py", line 267, in run_file
runpy.run_path(options.target, run_name=compat.force_str("__main__"))

File "C:\Python27amd64\Lib\runpy.py", line 252, in run_path
return _run_module_code(code, init_globals, run_name, path_name)

File "C:\Python27amd64\Lib\runpy.py", line 82, in _run_module_code
mod_name, mod_fname, mod_loader, pkg_name)

File "C:\Python27amd64\Lib\runpy.py", line 72, in _run_code
exec code in run_globals

File "C:\Users\clnorris\Documents\Projects\Datasheets\CC3x20_Embedded_Programming_2_0_0\sources\ImageProgramming.py", line 125, in <module>
main(args, SelectedTraceLevel, EraseBeforeWrite)

File "C:\Users\clnorris\Documents\Projects\Datasheets\CC3x20_Embedded_Programming_2_0_0\sources\ImageProgramming.py", line 95, in main
BurnImage( args, SelectedTraceLevel, EraseBeforeWrite )

File "C:\Users\clnorris\Documents\Projects\Datasheets\CC3x20_Embedded_Programming_2_0_0\sources\ImageProgramming.py", line 69, in BurnImage
SflashBlockSize, SflashMaxBlocks = ldr.GetStorageInfo("SFLASH")

---Error Line:---
Traceback (most recent call last):
File "C:\Users\clnorris\Documents\Projects\Datasheets\CC3x20_Embedded_Programming_2_0_0\sources\bootldr.py", line 361, in GetStorageInfo
Info = self._GetStorageInfo(Storage)
File "C:\Users\clnorris\Documents\Projects\Datasheets\CC3x20_Embedded_Programming_2_0_0\sources\bootldr.py", line 239, in _GetStorageInfo
self._read_ack()
File "C:\Users\clnorris\Documents\Projects\Datasheets\CC3x20_Embedded_Programming_2_0_0\sources\bootldr.py", line 182, in _read_ack
raise BootloaderException('Got NACK')
BootloaderException: Got NACK

Then I tried to force an erase by creating my own block erase method in bootldr.py.  Here is my function:

    def RawErase(self, Storage, StartBlock, BlocksToErase, EraseBeforeWrite = True ):
        try:
            self._trace_msg(TRACE_LEVEL_DEBUG,"RawStorageErase")
            if (Storage not in Storages):
                self._trace_msg(TRACE_LEVEL_ERROR, "Unknown storage {:s}".format(Storage))
                return None
            self._comm_open()
            if( EraseBeforeWrite ):
                NormalTimeOut = self.comm.timeout
                self._trace_msg(TRACE_LEVEL_ACTIVITY, ("Step #5/9 --> Erasing {:d} blocks from SRAM/SFLASH starting from block #{:d}".format(BlocksToErase, StartBlock)))
                self.comm.timeout = BlocksToErase / 10.0
                if(self.comm.timeout == 0 ):
                    self.comm.timeout = 1
                self._trace_msg(TRACE_LEVEL_ACTIVITY, "The process of erasing blocks takes several seconds")
                Status = self._EraseBlocks(Storage, StartBlock, BlocksToErase)
                self.comm.timeout = NormalTimeOut
                if (True != Status):
                    raise Exception("RawStorageErase failed")

                self._trace_msg(TRACE_LEVEL_ACTIVITY, "Erasing completed \n")
        except Exception:
            self._trace_msg(TRACE_LEVEL_ERROR,'''--- error during raw write \n
                            \n ***** Please reset the board and try again *****''')
            self._printTraceback()
            sys.exit(EXIT_CODE_EXCEPTION_RAW_WRITE)

After I created the function, I called it from ImageProgramming.py to erase all blocks:

ldr.RawErase("SFLASH", 0, 1024, True)

The erase command received a NACK as well.  It seems like any bootloader command I try that uses SFLASH is not working.  Do you know of any sequence of bootloader commands to reset the SFLASH so I can try programming again?  Is there any other kind of erase tool we could upload and execute from the SRAM?

Our next revision of board has the FLASH_SPI_CLK, FLASH_SPI_MISO, and FLASH_SPI_NCS_IN from CC3220MODAS brought to a header.  I am hoping the lockout doesn't happen on another board, but if it does then I am wondering if erasing the SPI flash to all FF's using the programming pins would reset the module to a state where it can be programmed again.

Any insight is appreciated!

Thanks,
Chris Norris

You can try the Factory Reset procedure (as a recovery method).

I will need to consult regarding the bootloader code.

Br,

Kobi