CC3100: Format in bootloader mode returns 0x00 0x80

Hi,

Is the host_programming.pdf this one?

https://software-dl.ti.com/ecs/CC3100SDK/1_3_0/exports/cc3100-sdk/docs/examples/host_programming.pdf

That guide is outdated and we've removed it from newer SDKs. The main issue with that guide is that one missing step is that after the serial flash is erased, you're supposed to load in new files - there is no way for the CC3100 to boot into a new servicepack if you've erased all of the flash, since there is no data at all.

In such a case where the serial flash is erased, the device is supposed to boot from the ROM code. That being said, ordinarily tools such as Uniflash don't simply erase the serial flash without loading anything back on, so perhaps there is some unexpected state that occurs in such a case. In order to recover the CC3100, you need to write the serial flash with filesystem contents, so that the CC3100 bootloader can detect a valid serial flash and filesystem and boot normally. Indeed, the 0x80 event shouldn't occur - looking at the bootloader it doesn't look like that is a defined return code that is used anywhere. The expected ACK after a serial flash erase command is the usual 0xCC.

Have you checked the serial flash to see if it's actually erased? If it is, the CC3100 should boot from ROM and then create its filesystem.

Also, in the future reference, please use section 16.2 of the production line guide for instructions on how to update the servicepack from your host device using the sl_Fs* APIs. This has more up-to-date information than the document you are using.

Regards,

Michael

Hi Michael, yes, that's the host_programming guide I was using.  I didn't realize that it was possible to write to the filesystem or write a service pack without exiting the bootloader.

I don't currently have visibility into the SPI flash to see if it is erased so we're instrumenting that bus to at least look at the transactions.  I can guarantee that the flash _wasn't_ formatted and didn't contain a servicepack prior to my attempt to format. When we assemble our boards, those parts remain unprogrammed from the manufacturer.

I'll investigate using the sl_Fs* APIs while the CC3100 is still in bootloader mode.  Can you provide a link to the relevant production line guide?

In the file_operations example code, it seems to imply that the sl_Fs* APIs can only be used once you've booted the CC3100 with sl_Start() and have entered a valid mode (like STA mode.)  Since I can't get to these modes, am I going to be able to use sl_Fs*()?

Hi,

Sorry for not linking the production line guide, here it is: www.ti.com/lit/swra658

Yes, the sl_Fs* APIs can only be performed once sl_Start() has returned and your CC3100 is active in a valid mode.

Assuming your serial flash came blank, on first boot the CC3100 would have loaded its ROM firmware and booted from that, allowing sl_Start() to return. From there, you will need to perform the steps in section 16.2 of the production line guide to update the device to the latest SP.

Now, it is a bit strange that your CC3100 appears to not respond to sl_Start() anymore. If the flash was erased and formatted, then it should boot into the ROM code. If it wasn't, then it should still have no contents and as such boot into the ROM code.

Do you have another board or serial flash part you can try those updating steps on? As there is no non-volatile storage on the CC3100, replacing the serial flash will be enough to restore it to its default functionality.

If you wanted to confirm what is causing the CC3100 device boot to fail, you can also capture the debug UART logs from the device. Please take a look at the instructions in section 19.1 of the programmer's guide: www.ti.com/lit/swru368

You can skip the first step of muxing out those logs in the instructions - that pin is always enabled for UART debug on the CC3100.

Regards,
Michael

Thanks Michael.  I haven't been able to examine the contents of the sFlash yet but I think that I've gathered some of the encrypted UART debug logs.  I hope that I've collected it properly.

cc3100-debug.zip

This log covers an attempt to init the CC3100 with sl_Start() where I got the asynchronous timeout.  Then resetting into the bootloader and attempting to format the sFlash.  I waited until it settled into a pattern of spitting out alternating chunks of 212 and 209 bytes of encrypted debug data before stopping the log.

Hi,

Thanks for the logs, they are decodable by my logger tool and I'm performing my analysis on it.

There appear to be quite a few bootloader errors that I'll need to sift through and debug, so I'll let you know my findings next week

Regards,

Michael

Hi Michael, any update for me?

Hi,

Taking a close look at the logs, it looks like the serial flash is corrupt. At boot, the bootloader will attempt to read the serial flash and perform a series of checks to ensure the validity of the filesystem. These checks are failing on your device very early in the boot process, and as such the filesystem is not loaded, causing the rest of the boot process to fail. At that point, the async error is thrown to the host.

Now, since the bootloader doesn't appear to be able to operate with the corrupt serial flash you will need to erase that serial flash with an external SPI programmer, or replace that part entirely with a blank part. Erasing through Uniflash or host programming won't be an option unfortunately as those both assume that the bootloader can startup correctly.

Regards,

Michael

Ok.  I'll look into finding a way to reformat the SPI flash manually to recover the board.  In the meantime, what you can tell me about my issue formatting a blank part with host programming?

Hi,

If you can connect to your CC3100 using your host and perform sl_Start(), what you should do next is simply follow section 16.2 of the production line guide to program the new servicepack file onto the CC3100 serial flash.

Let me know if that doesn't seem to work on your setup.

Regards,

Michael

Michael, perhaps you lost track of this thread? I can’t sl_Start() because the format failed, we just discussed that. I’m investigating re-erasing the SPI flash with an external too.

My question to you was about the failed bootloader format. What can we do to debug the failed format? Would it be helpful for me to dump the contents of the flash once the format has failed? Would that provide insight into the reason for the failure?

Hi,

I misunderstood your previous post, as it had appeared that you were asking for advice on what to do once you had recovered your device.

As for debugging the failed format, there isn't much else that we can do to debug the failure now that the serial flash is corrupt, as the failure has already occurred.

If once you reformat the serial flash with your SPI flash programmer you see further reproducible failures after using the format command, then the most useful debug info would be to capture the NWP logs that are printed as the bad format command is executed. The contents of the serial flash might also be interesting to double-check, but the primary debug info would be from those NWP logs as it will output debug messages through every step of the format process and I'll be able to better identify exactly what goes wrong vs trying to work backwards from the corrupt serial flash.

That being said, it is not necessary to run the format command at all. I took a look deep into the bootloader code, and confirmed that all the format bootloader command does is ensure that the filesystem and indeed the entire serial flash is erased and zeroed out. If your serial flash is already blank, than that step is actually not needed.

So, as I mentioned in my previous post, once you have a blank serial flash connected to the CC3100, then you can simply skip the format step and perform the following steps, namely downloading the SP to the CC3100.

Regards,

Michael

Ok.  I'm working on a method to erase the SPI flash manually.  However, the NWP logs that I uploaded originally include an attempt to format the SPI flash in the bootloader.  Were you able to glean anything from that portion of the NWP log?

Hi,

Within the NWP logs, the main logged data seems to consist of two bootloader startup sequences. In both cases, the boot fails very early on, as the serial flash binary is detected to be corrupt. In both cases, the boot ends with the async error returned to the host.

As such, it doesn't appear that bootloader attempted to run the format command, even if it was received.

Regards,

Michael

That's confusing.  To start, yes, I tried to init the device with sl_Start().  Once that failed I'm confident that I reset into the bootloader and waited to receive 0x00 0xcc before issuing the format command.  Once issuing the format command the bootloader delayed for 4-5 seconds before returning 0x00 0x80.  Are you saying that the bootloader itself failed to initialize because the serial flash was corrupt even though it returned 0x00 0xcc?  That doesn't seem right.

Hi,

In your first post, you mention

Patrick Voelker said:

Prior to attempting to format, I could init the CC3100 and put it into STA mode.

Does this mean that sl_Start() worked at some point?

From the logs you have gathered, my observations so far point to the conclusion that something in the formatting process went wrong and caused the serial flash to be corrupted. Whether there might have been an intermediate failure state, where the bootloader still functioned but was in a bad state causing the format to fail, may or may not be the case. Since we don't have the logs of that first format command, where things went awry, I cannot say for sure what caused the serial flash corruption to occur.

If at some point sl_Start() worked, then you can skip the whole formatting step and simply use the regular application APIs to write the new servicepack files to the serial flash. This is what I suggest you try doing once you recover your serial flash.

Regards,

Michael

Yes, prior to attempting to format the flash, when it was freshly unprogrammed from the factory, sl_Start() worked and I could use the CC3100 in STA and transciever mode to a certain extent. There were some operations that didn't seem to work and I was working with support on this site until I had to update the service pack and then I had to wait for new boards.  (See my other posts for examples.)

We've been able to rework a board to have access to the serial flash on the board that is failing to init the CC3100 after format.  On dumping the flash it we found that it was completely erased (all 0xffs.)

Then I created a gang image to manually program (gang_1.1.14-2.12.2.8_1.zip).  After programming, we read verified that it had been written successfully except for the remaining portion of flash that the gang image didn't cover (it's not 1MB in size exactly.)

After removing the rework, we attempted initializing the CC3100 again with sl_Start() and found that it was still reporting an async timeout.

I collected NWP logs again of several attempts to boot in a row (cc3100-debug2.zip.)

Additionally, prior to programming the gang image, we did a trace of some of the activity on the SPI bus between the CC3100 and the formatted serial flash.  Here's a textual representation and I'll also attach the images:

* Master sends 0xab, 0x05, 0xff, 0x05, 0xff (release from power down)
* Master sends 0x9f, clocks out 3 bytes - 0xc8 0x40 0x14 - the flash device's ID (this means the device is responding)
Things go silent for 500+ microseconds, then the following occurs:
* Master sends 0xab, 0x5, 0xff, 0x05, 0xff (again, release from power down) again
* Master sends 0x9f, clocks out 3 bytes - 0xc8 0x40 0x14 - the flash device's ID (just like before)
* Master sends 0x05 (read status register)
* Master clocks out 0x00 from the device
* Master sends 0x03, 0x00, 0x00, 0x00
* Master clocks in 0xff, 0xff, 0xff, 0xff from the device
* Master sends 0x05 (read status register)
* Master clocks in 0x00 from the device
* Master sends 0x03, 0x00, 0x10, 0x00
* Master clocks in 0xff, 0xff, 0xff, 0xff from the device
Then the device waits a while and does this:
* Master sends 0x05 (read status register)
* Master clocks in 0x00 from the device
* Master sends 0x03, 0x00, 0x00, 0x00 again
* Master clocks in 0xff, 0xff, 0xff, 0xff,.... 14 bytes. However it might be more, but the Logicport doesn't have a buffer that's big enough to catch what comes after it.

Hi,

Thanks for performing those tests and providing the new NWP logs.

Like the previous logs, it appears that the CC3100 detects the filesystem as corrupt, albeit at a different area of the bootloader code. This is a strange outcome, seeing this time we know for sure that you applied the gang image to the serial flash directly through SPI and so the SPI should be good.

The most unusual finding is that prior to reprogramming the SPI flash, you saw that it was actually erased correctly by the CC3100. So, the CC3100 should not have detected a corrupt serial flash in the first place.

Perhaps your CC3100 is damaged or otherwise defective. Do you have another CC3100 you can use, or an EVM you can test with? It will be good to make sure that the CC3100 IC itself is not the cause of the error.

Regards,

Michael

Hi, Michael. Yes, we duplicated the behavior on at least two CC3100s that (after the format and re-init failures) had their serial flashes programmed with the gang image.

What other reasons could we have for the CC3100 detecting corruption?  We've verified that the serial flash is seeing requests from the CC3100 and is responding on the bus.

Hi,

Finding the precise reason for why corruption might be detected will rely on sifting through the NWP logs and comparing the error codes to the CC3100 ROM bootloader source code.

There are a variety of checks that occur, but the basic concept is that at boot the serial flash contents such as the file table, key system files, etc. are checked. If there is an error during the boot due to a serial flash read error or file mismatch then the bootloader will mark the serial flash as corrupt.

Do you have a CC3100 boosterpack that you can use for testing? I wonder if there some issue perhaps with your board or maybe the serial flash that is causing the apparent corruption somehow. If we can reproduce the same behavior on a CC3100 boosterpack EVM that will greatly narrow down the potential source of the issue, and allow me to debug this directly on my end.

Is the serial flash part you are using on the list of recommended known-good serial flash devices? The list can be found in Table 8 of the CC3100/CC3200 serial flash guide: https://www.ti.com/lit/swra657

Regards,

Michael

If you could start sifting through the logs, as you say, to help me diagnose the specific reason for the corruption, that would be very helpful.  I really need to get this issue figured out.

The serial flash that we're using is GigaDevice GD25D80C.  Don't forget that I provided SPI trace and analysis on April 30th of the CC3100 fetching the device ID and reading from it.

In the meantime, I have a CC3100MODBOOST that I'm working on getting wired up to our board to attempt to duplicate the behavior.

Hi,

Looking through the datasheet for your serial flash, ti seems like it should be compatible.

Getting a CC3100MODBoost wired up and duplicating the behavior would be very helpful.

Regards,

Michael