After embedded programming, CC3200 will not enter bootloader

Yes, programming the 8 bytes header last is exactly to avoid loading a corrupted program.

However, in your case, you decompress the image before flashing and most likely something went wrong there so the program got corrupted.

With the full image programming from Uniflash everything went well so it must be the case.

So I added a checksum verification on the decompressed data and it all is correct but after I program, I get no response.  My tech is getting sick of changing the SFLASH :-)

I have confirmed that if I program the same image file with the UniFlash tool all is well.

Is there a readback command on the sflash (the embedded programming tool does not mention/document this)?  I think I really need it.  This will allow me to make sure that the 8 to end is programmed correctly.  I do get acks and last command status success for all the blocks that I am programming.

Thanks,

..M

Hi,

I don't see the difference between the 2 tests in your last post. Do you refer to your target as a custom board? You mentioned the eval board is OK. What is the difference.

In any case, you device is OK. It is a production device.

Attached is a utility to read back the entire 1MB flash. Please note the followings:

1. it works like Uniflash via UART. You just need to supply the COM port and reset the device when prompted
2. the image you program gets extracted on the 1st reset so it is not possible to program the image and then read it back by this utility as the reset would get the image to start extraction (not sure what would happen). What I suggest is that you reset the device after programming the image and then reset it and wait for the image to get extracted (a few seconds). Then, execute this utility and provide me with the 1MB image result

Regards,

Shlomihttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/968/1464.ReadFlash_5F00_1MB.exe

Looking into the possible target vs eval bd differences.  The serial flashes are from different manufacturers.  Don't know what the diff is but the part we are using is on the sflash list in the hw guide.

Will this utility work if the image is corrupted (i.e. in the non-responsive state due to image incorrect) and not accessible to Uniflash?

Thanks,

..M

Worth a try. It should work.

Hi,

Any update on the post? 

Shlomi

Thanks ... just getting back to this problem ... will let you know soon.

..M

So I tried the utility on my working eval card and it does not read back correctly.  I program the eval unit with Uniflash image and all is working.  I read it back with the utility and nothing matches.  I've attached the working image and its associated readback.bin.

I tried it on my target for grins but no go.  I have attached my image and along with what was read back.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/968/readSflashBack.7z

Hi Mark,

I'm reopenning the thread.

Will reply soon.

Shlomi

Mark,

The reason the image is not readable is because it is encrypted.

Decrypting the image, I can see that it looks good.

The file system looks like:

file       start     size      fail-safe total               filename

index  block  [BLKs]                  size[BLKs]
--------------------------------------------------------------------------
N/A   0      5   N/A   5        FATFS
0       5     20  no    20      /sys/mcuimg.bin
9       99   1    no     1        gang.log
10    100 5   yes   10       /tmp/phy.cal
11     25  1    no     1        /cert/equifaxca.cer
12     26  1    no     1        /cert/tisiteca.cer
13     27  1    no     1        /cert/dexcom8ca.cer
14     28  1    no     1        /cert/tisiterootca.cer
15     29  1    no     1        /cert/dexcom7rootca.cer
16     30  1    no     1        /cert/dexcom7ca1.cer
17     31  1    no     1        /cert/dex7.cer
18     32  1    no     1        /cert/usertrust.cer
19     33  33 yes   66       /sys/servicepack.ucf
20    110 1   yes    2        /sys/stacfg.ini
21    112 1   yes    2        /sys/ipcfg.ini
22    114 1   yes    2        /sys/mode.cfg
23    116 1   yes    2        /sys/pmcfg.ini
24    118 1   yes    2        /sys/mdns.cfg

Flash usage
-------------------------
used space: 120 blocks
free space: 136 blocks
memory hole: [120-255]

gang.log which logs the image extraction procedure is:

Start Log
=================================
CommandStartLogger, Processing time = 635 uS ,
Command = 2 (Opcode = 4)
CommandWriteFile, Name = /sys/mcuimg.bin
Actual file size = 79496, FailSafe = 0, Secure = 0, Sig = 0, Processing time = 389501 uS ,
Command = 3 (Opcode = 4)
CommandWriteFile, Name = /cert/equifaxCA.cer
Actual file size = 804, FailSafe = 0, Secure = 0, Sig = 0, Processing time = 11213 uS ,
Command = 4 (Opcode = 4)
CommandWriteFile, Name = /cert/TiSiteCa.cer
Actual file size = 1409, FailSafe = 0, Secure = 0, Sig = 0, Processing time = 14207 uS ,
Command = 5 (Opcode = 4)
CommandWriteFile, Name = /cert/dexcom8CA.cer
Actual file size = 1144, FailSafe = 0, Secure = 0, Sig = 0, Processing time = 13075 uS ,
Command = 6 (Opcode = 4)
CommandWriteFile, Name = /cert/TiSiteRootCA.cer
Actual file size = 1213, FailSafe = 0, Secure = 0, Sig = 0, Processing time = 13306 uS ,
Command = 7 (Opcode = 4)
CommandWriteFile, Name = /cert/dexcom7RootCA.cer
Actual file size = 1082, FailSafe = 0, Secure = 0, Sig = 0, Processing time = 12901 uS ,
Command = 8 (Opcode = 4)
CommandWriteFile, Name = /cert/dexcom7CA1.cer
Actual file size = 1403, FailSafe = 0, Secure = 0, Sig = 0, Processing time = 14293 uS ,
Command = 9 (Opcode = 4)
CommandWriteFile, Name = /cert/dex7.cer
Actual file size = 1459, FailSafe = 0, Secure = 0, Sig = 0, Processing time = 14580 uS ,
Command = 10 (Opcode = 4)
CommandWriteFile, Name = /cert/USERTRUST.cer
Actual file size = 1082, FailSafe = 0, Secure = 0, Sig = 0, Processing time = 12848 uS ,
Command = 11 (Opcode = 4)
CommandWriteFile, Name = /sys/servicepack.ucf
Actual file size = 10100, FailSafe = 1, Secure = 1, Sig = 1, Processing time = 80090 uS ,
CommandWriteGangImageFile ,
CommandWriteGangImageFile ,
Set num = 0 processed successfully,set Processing time = 1443223 uS
=================================
Gang Image vendor version = verExample
GangProgram: version 1.0.2.5
GangProgram: Program was build with Gang Image builder version 1.0.2.5
GangProgram: Data was build with Gang Image builder version 1.0.2.5
Gang Programmer finished successfully,Total processing time = 4330387 uS
=================================
End Of Log

Shlomi

OK .. makes sense.  So I am now sending the dump from my target (scout) and the eval board of the same image (uploaded previously).

My target is definitely different.  Note that the first 8 location of my target are NOT programmed because when I do program them I lose all access to the part and have to replace the serial flash to recover.  Hopefully this comparison will solve my dilemma.https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/968/readSflash_5F00_eval_5F00_vs_5F00_target.7z

Thanks,

..M

Maybe I am missing something but it is different because the image from your target has not been extracted (i.e. remained as you programmed it).

The reason is the missing 8 header bytes. This header flags the boot loader to extract the image.

Are you saying that if you add this header and reset the board, it gets stuck? if so, the only option I see is that the decompression tields a non-bitwise image as produced by Uniflash.

Regardless, you use a little older version of Uniflash. What version are you using (help->about)?

Shlomi

Very frustrated :-(

I created a new image using the latest Uniflash tool ( Version: 3.4.0.00002 )

Using Uniflash Image Programming , I burned that to my eval board and it worked just fine.

Using Uniflash Image Programming, I burned it to my target (Scout) and it worked just fine.

I then checksumed my image, stored the checksum, compressed the image, and stored it in my target's file system.

My target, expanded the compressed file, verified that the uncompressed length matched, then verified that the image checksum was consistent with the image before it was compressed..

I burned this image into my target per the embedded programming documentation.

Two phases: from offset 8 to  the end, followed by offset 0 to 8.  I received acks for all flash writes.

Note: You confirmed that my image from 8 to end was correctly programmed .. although the file system had not been expanded (is this true).

I reset the CC3200, waited for 30 sec and it was DEAD.  I can no longer access it with any tool ... not even UniFlash.

I am lost.

Thanks,

..M

This one is really a puzzle.

Just to clarify, when you say your target is used for compress/decompress, save the checksum, etc - I understand it is another processor on your system and not the CC3200, right?

The only 2 options I see to further debug and try to understand the root cause are:

1. when you solder out the defected serial flash, connect it to an external flash reader and dump its content. We can try to analyze it post mortem
2. try to capture the UART lines of the entire procedure (preferably with saleae logic)

One more comment: you need to make sure the CC3200 reset is applied only once after the full image is flashed (by your target I guess). If it is reset twice, the CC3200 boot loader should cope with it but it may take much longer time to extract the image as in this case the boot loader also erases the serial flash. If you are using a slow serial flash (long sub sector erase time), it may take more than 30 seconds.

Shlomi

Yes, by target I am referring to our Atmel Host.

The Atmel ARM Host has the compressed image in its Flash File system.  It (Atmel) expands it, and then runs the embedded programming protocol on the C3200.

I will have to check the reset timing but I do reset, then wait for 30 seconds.  I return after that and the reset may get asserted/reasserted on exit.  But if this were the case, I would think that when I attempted to connect with uniflash that it would function.  It is DEAD and never responds after programming.  If the reset was applied inappropriately after programming caused the ???programming to be erased??? ... maybe we are getting someplace.   I will have to get a serial flash reader. 

Thanks,

..M

The device may become DEAD only if the image is corrupted, not related to reset at all.

As I mentioned, reseting in between would cause longer image extraction time but would not make the device irresponsive.

An external flash reader should shed light on what you are experiencing. Please let me know when you have a dump.

Shlomi

BTW, we are using this part for our flash device.  Could there be a problem here?

Adesto  AT25DF081A-MH-T

Thanks!

..M

Mark,

It should be OK.

You can look under http://processors.wiki.ti.com/index.php/CC3100_%26_CC3200_Serial_Flash_Guide#Serial_Flash_Vendor_and_part_number_selection

Besides, you said that your target works fine with Uniflash, right?

Shlomi

Yes .. fine with Uniflash.

Could this be it?

I am programming a full max buffer from address 8 to 8+(4096 - 16 (command length))

Should I be subtracting 8 from this?  Does the SFLASH have a sector boundary that I could be crossing?

Thanks,

..M

Mark,

Not sure what is the 16 bytes of command length you are reffering to but the guideline is that after decompressing the image, it needs to match the original image generated with Uniflash.

The original image does not occupy the entire 256 blocks of 4KB (if you use a 1MB SFLASH) because it has some margins it reserves. This is all internal implementation. However, the erase step is very important since during the extraction process, the boot loader assumes the serial flash is erased, i.e. all 0xFF.

Shlomi

Hi,

Any update on the post?

Shlomi