• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 40 subscribers
  • Views 1175 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3100: CC3100 sl_FsOpen() returns SL_FS_NO_DEVICE_IS_LOADED (-49)

Steve Tostevin
Prodigy 70 points
Part Number: CC3100
Other Parts Discussed in Thread: UNIFLASH

I have a number of custom boards containing CC3100 R1 and Winbond Serial Flash (W25Q80 - 8M-Bit). 

I am trying to apply write the patch file to serial flash. This works OK on some boards, but not on others.

Initially, I try to format the flash through the UART interface to the CC3100 and then apply the patch file using the simple link file system through the SPI interface.

The format of the flash appears to be successful, but the sl_FsOpen() returns SL_FS_NO_DEVICE_IS_LOADED (-49)

The process is successful on some boards, but fails on other boards. I get the same results using the UniFlash tool.

I have set up an SPI analyzer between the CC3100 and Serial Flash device, but can see no difference in the commands between the two devices. Signal integrity appears to be good.

My initial thought is that the Serial Flash has some Sector protection preventing the files being written, but I have no way of interrogating the serial flash without removing the serial flash from the board.

I would like to know under what circumstances the sl_FsOpen() function returns (-49) error code and any other assistance that you can give me to resolve this issue.

Steve Tostevin

  • 0
    TI__Mastermind 29085 points

    Hi Steve,

    The error code indicates that  the serial flash was not loaded correctly, which makes it inaccessible to a CC3100. Refer to the following post:

    https://e2e.ti.com/support/wireless_connectivity/simplelink_wifi_cc31xx_cc32xx/f/968/t/381382

    Can you clarify your following statement?

    Steve Tostevin said:
    Initially, I try to format the flash through the UART interface to the CC3100 and then apply the patch file using the simple link file system through the SPI interface.

    Are you using the embedded programming commands to format and then the simplelink API to load the servicepack? Do you get the same result if you try to load an initial image with the latest servicepack through the embedded programming technique or with UniFlash?

    Have you also checked that the power supplied to the serial flash is stable and within the expected range? What are the voltage levels of each?

    Thanks,

    Ben M

  • 0 in reply to Benjamin Moore
    Prodigy 70 points

    Hi Ben,

    Thanks for the quick reply,

    Yes we are using the embedded programming commands to format the flash through the UART and then Simplelink to apply the patch.

    We have also tried using UniFlash to format the flash and program the service pack with the same results.

    We have checked the voltage levels, we have 3.3V on the serial flash, but will verify that these are stable.

    I would like more detail about what causes the error code -49, device not loaded. From the SPI scope I can see that the CC3100 is talking to the Serial Flash. I see the CC3100 read the manufacturer and device code (correctly) and issuing sector erase commands, during format. During the file open operation I can see it read the manufacturer and device code and then start reading data from addresses 0x000000 and 0x0010000. This is where it seems to fall over, I suspect that it is trying to read the FAT entries and does not like what is returned to it and then generates the device not loaded error message. I am trying to determine whether the Flash erase has failed or something else.

    Are there other embedded commands that we can use to talk to the Serial Flash, to try and diagnose the issue such as Read/Write Commands, Commands to Read/Write Status Register and Write protect bits in Status register

    Steve

  • 0 in reply to Steve Tostevin
    TI__Mastermind 29085 points
    Hi Steve,

    When the network processor is initialized (i.e. turned on using sl_Start()), the device makes sure the serial flash is powered up and reads the device ID to make sure it is recognized. The size is determined from the formatted capacity of the device. After the device is recognized, the file table is loaded into the CC3100 device memory. If either of these steps fails or the initialization is not performed, the serial flash is considered "not loaded". Attempting to create, modify, or delete a file when the file table has not been loaded results in the error you are seeing.

    I recommend you try to use UniFlash to format and load the servicepack again, but run it with the additional debug printouts enabled. You can turn these on by going to Window->Preferences->UniFlash Preferences and checking the "Print out additional debug information for the supported modules" box.

    Please share the output from the console when running the commands.

    To get additional information on where the system is failing to initialize the serial flash or file system, you can also pull the NWP logs as described in the following wiki and send them to me:
    processors.wiki.ti.com/.../CC3100_&_CC3200_Capture_NWP_Logs

    I will decode them and take a look for any unexpected behavior.

    Another question, is this happening on newly manufactured systems or systems that have been in use and then formatted at a later time?

    Thanks,
    Ben M
  • 0 in reply to Benjamin Moore
    Prodigy 70 points

    HI Ben,

    I'm not convinced this is a problem with the CC3100, but more likely with the Winbond Serial Flash W25Q80BLUXIG. We are supplying the serial flash with 3.3V, but there data sheet talks about 2.3V to 2.7V parts and 2.3V to 3.6V parts without making it clear which parts it is talking about. I need to talk to Winbond about this.

    I have an SPI scope monitoring the SPI between the CC3100 and the serial Flash. I can see the CC3100 sending commands to erase sectors and write to sectors, but when these sectors are read back they seem incorrect, they don't contain what has been written. Similar results with the format command. I get the same results with uniflash as shown below.

    I haven't attempted the NWP log yet, as I don't see this as an issue with CC3100 and I don't think its going to tell me any more than the SPI logs I already have. The SPI logs seem to indicate the CC3100 doing the same commands for good and bad boards, but just getting bad results from the broken board. 

    I don't think there is anything else TI can do for us at the moment unless you can see anything in the data below (SPI log also attached)

    Thanks for your help

    Steve

    UniFlash log to perform GetVersion, Program service pack and Format commands

    [14:04:07] Begin GetVersion operation.
    [14:04:07] INFO: > Executing Operation: Connect
    [14:04:07] DEBUG: waiting and clearing uart rx buffer
    [14:04:09] INFO: setting break signal
    [14:04:09] INFO: --- please restart the device ---
    [14:04:09] DEBUG: wait for ack
    [14:04:13] INFO: connection succeeded
    [14:04:13] INFO: getting storage list
    [14:04:13] DEBUG: wait for ack
    [14:04:13] INFO: > Executing Operation: GetVersion
    [14:04:13] INFO: reading version info
    [14:04:13] DEBUG: wait for ack
    [14:04:13] INFO: > Bootloader version: 2.0.4.0
    [14:04:13] INFO: > Executing Operation: Disconnect
    [14:04:13] DEBUG: disconnecting from device . . .
    [14:04:13] DEBUG: wait for ack
    [14:04:13] Operation GetVersion returned.
    [14:04:30] Begin ServicePackUpdate operation.
    [14:04:30] INFO: > Executing Operation: Connect
    [14:04:30] DEBUG: waiting and clearing uart rx buffer
    [14:04:32] INFO: setting break signal
    [14:04:32] INFO: --- please restart the device ---
    [14:04:32] DEBUG: wait for ack
    [14:04:35] INFO: connection succeeded
    [14:04:35] INFO: getting storage list
    [14:04:35] DEBUG: wait for ack
    [14:04:35] INFO: > Executing Operation: Init
    [14:04:35] INFO: reading version info
    [14:04:35] DEBUG: wait for ack
    [14:04:35] INFO: DEVICE CC3100 ES1.33
    [14:04:36] INFO: reading version info
    [14:04:36] DEBUG: wait for ack
    [14:04:36] DEBUG: Bootloader version is 2, 0, 4, 0
    [14:04:36] DEBUG: raw storage write
    [14:04:36] DEBUG: wait for ack
    [14:04:36] DEBUG: BlockSize is 4096, number of blocks is 16
    [14:04:36] DEBUG: erasing 13 blocks starting from 0
    [14:04:36] DEBUG: wait for ack
    [14:04:36] DEBUG: status request
    [14:04:36] DEBUG: wait for ack
    [14:04:36] DEBUG: wait for ack
    [14:04:36] DEBUG: status request
    [14:04:36] DEBUG: wait for ack
    [14:04:36] DEBUG: wait for ack
    [14:04:51] DEBUG: UART timeout
    [14:04:51] DEBUG: --- COM Port timeout on ACK read
    [14:04:51] DEBUG: Error, could not write to offset 4080
    [14:04:51] DEBUG: wait for ack
    [14:05:06] DEBUG: UART timeout
    [14:05:06] DEBUG: --- COM Port timeout on ACK read
    [14:05:06] DEBUG: Error, could not write to offset 8160
    [14:05:06] DEBUG: wait for ack
    [14:05:21] DEBUG: UART timeout
    [14:05:21] DEBUG: --- COM Port timeout on ACK read
    [14:05:21] DEBUG: Error, could not write to offset 12240
    [14:05:21] DEBUG: wait for ack
    [14:05:36] DEBUG: UART timeout
    [14:05:36] DEBUG: --- COM Port timeout on ACK read
    [14:05:36] DEBUG: Error, could not write to offset 16320
    [14:05:36] DEBUG: wait for ack
    [14:05:51] DEBUG: UART timeout
    [14:05:51] DEBUG: --- COM Port timeout on ACK read
    [14:05:51] DEBUG: Error, could not write to offset 20400
    [14:05:51] DEBUG: wait for ack
    [14:06:07] DEBUG: UART timeout
    [14:06:07] DEBUG: --- COM Port timeout on ACK read
    [14:06:07] DEBUG: Error, could not write to offset 24480
    [14:06:07] DEBUG: wait for ack
    [14:06:22] DEBUG: UART timeout
    [14:06:22] DEBUG: --- COM Port timeout on ACK read
    [14:06:22] DEBUG: Error, could not write to offset 28560
    [14:06:22] DEBUG: wait for ack
    [14:06:37] DEBUG: UART timeout
    [14:06:37] DEBUG: --- COM Port timeout on ACK read
    [14:06:37] DEBUG: Error, could not write to offset 32640
    [14:06:37] DEBUG: wait for ack
    [14:06:52] DEBUG: UART timeout
    [14:06:52] DEBUG: --- COM Port timeout on ACK read
    [14:06:52] DEBUG: Error, could not write to offset 36720
    [14:06:52] DEBUG: wait for ack
    [14:07:07] DEBUG: UART timeout
    [14:07:07] DEBUG: --- COM Port timeout on ACK read
    [14:07:07] DEBUG: Error, could not write to offset 40800
    [14:07:07] DEBUG: wait for ack
    [14:07:22] DEBUG: UART timeout
    [14:07:22] DEBUG: --- COM Port timeout on ACK read
    [14:07:22] DEBUG: Error, could not write to offset 44880
    [14:07:22] DEBUG: wait for ack
    [14:07:37] DEBUG: UART timeout
    [14:07:37] DEBUG: --- COM Port timeout on ACK read
    [14:07:37] DEBUG: Error, could not write to offset 48960
    [14:07:37] DEBUG: status request
    [14:07:37] DEBUG: wait for ack
    [14:07:52] DEBUG: UART timeout
    [14:07:52] DEBUG: --- COM Port timeout on ACK read
    [14:07:52] DEBUG: 1
    [14:07:52] DEBUG: wait for ack
    [14:08:07] DEBUG: UART timeout
    [14:08:07] DEBUG: --- COM Port timeout on ACK read
    [14:08:07] DEBUG: wait for ack
    [14:08:22] DEBUG: UART timeout
    [14:08:22] DEBUG: --- COM Port timeout on ACK read
    [14:08:22] FATAL: Error loading the bootloader. Error code: -3
    [14:08:22] INFO: > Executing Operation: Disconnect
    [14:08:22] DEBUG: disconnecting from device . . .
    [14:08:22] DEBUG: wait for ack
    [14:08:37] DEBUG: UART timeout
    [14:08:37] DEBUG: --- COM Port timeout on ACK read
    [14:08:38] Operation ServicePackUpdate returned.
    [14:12:51] Begin Format operation.
    [14:12:51] INFO: > Executing Operation: Connect
    [14:12:51] DEBUG: waiting and clearing uart rx buffer
    [14:12:53] INFO: setting break signal
    [14:12:53] INFO: --- please restart the device ---
    [14:12:53] DEBUG: wait for ack
    [14:12:55] INFO: connection succeeded
    [14:12:55] INFO: getting storage list
    [14:12:55] DEBUG: wait for ack
    [14:12:55] INFO: > Executing Operation: Init
    [14:12:55] INFO: reading version info
    [14:12:55] DEBUG: wait for ack
    [14:12:55] INFO: DEVICE CC3100 ES1.33
    [14:12:55] INFO: reading version info
    [14:12:55] DEBUG: wait for ack
    [14:12:55] DEBUG: Bootloader version is 2, 0, 4, 0
    [14:12:55] DEBUG: raw storage write
    [14:12:55] DEBUG: wait for ack
    [14:12:55] DEBUG: BlockSize is 4096, number of blocks is 16
    [14:12:55] DEBUG: erasing 13 blocks starting from 0
    [14:12:55] DEBUG: wait for ack
    [14:12:55] DEBUG: status request
    [14:12:55] DEBUG: wait for ack
    [14:12:55] DEBUG: wait for ack
    [14:13:10] DEBUG: UART timeout
    [14:13:10] DEBUG: --- COM Port timeout on ACK read
    [14:13:10] DEBUG: Error, could not write to offset 0
    [14:13:10] DEBUG: wait for ack
    [14:13:25] DEBUG: UART timeout
    [14:13:25] DEBUG: --- COM Port timeout on ACK read
    [14:13:25] DEBUG: Error, could not write to offset 4080
    [14:13:25] DEBUG: wait for ack
    [14:13:40] DEBUG: UART timeout
    [14:13:40] DEBUG: --- COM Port timeout on ACK read
    [14:13:41] DEBUG: Error, could not write to offset 8160
    [14:13:41] DEBUG: wait for ack
    [14:13:56] DEBUG: UART timeout
    [14:13:56] DEBUG: --- COM Port timeout on ACK read
    [14:13:56] DEBUG: Error, could not write to offset 12240
    [14:13:56] DEBUG: wait for ack
    [14:14:11] DEBUG: UART timeout
    [14:14:11] DEBUG: --- COM Port timeout on ACK read
    [14:14:11] DEBUG: Error, could not write to offset 16320
    [14:14:11] DEBUG: wait for ack
    [14:14:26] DEBUG: UART timeout
    [14:14:26] DEBUG: --- COM Port timeout on ACK read
    [14:14:26] DEBUG: Error, could not write to offset 20400
    [14:14:26] DEBUG: wait for ack
    [14:14:41] DEBUG: UART timeout
    [14:14:41] DEBUG: --- COM Port timeout on ACK read
    [14:14:41] DEBUG: Error, could not write to offset 24480
    [14:14:41] DEBUG: wait for ack
    [14:14:56] DEBUG: UART timeout
    [14:14:56] DEBUG: --- COM Port timeout on ACK read
    [14:14:56] DEBUG: Error, could not write to offset 28560
    [14:14:56] DEBUG: wait for ack
    [14:15:11] DEBUG: UART timeout
    [14:15:11] DEBUG: --- COM Port timeout on ACK read
    [14:15:11] DEBUG: Error, could not write to offset 32640
    [14:15:11] DEBUG: wait for ack
    [14:15:26] DEBUG: UART timeout
    [14:15:26] DEBUG: --- COM Port timeout on ACK read
    [14:15:26] DEBUG: Error, could not write to offset 36720
    [14:15:26] DEBUG: wait for ack
    [14:15:41] DEBUG: UART timeout
    [14:15:41] DEBUG: --- COM Port timeout on ACK read
    [14:15:41] DEBUG: Error, could not write to offset 40800
    [14:15:41] DEBUG: wait for ack
    [14:15:56] DEBUG: UART timeout
    [14:15:56] DEBUG: --- COM Port timeout on ACK read
    [14:15:56] DEBUG: Error, could not write to offset 44880
    [14:15:56] DEBUG: wait for ack
    [14:16:11] DEBUG: UART timeout
    [14:16:11] DEBUG: --- COM Port timeout on ACK read
    [14:16:11] DEBUG: Error, could not write to offset 48960
    [14:16:11] DEBUG: status request
    [14:16:11] DEBUG: wait for ack
    [14:16:26] DEBUG: UART timeout
    [14:16:26] DEBUG: --- COM Port timeout on ACK read
    [14:16:26] DEBUG: 1
    [14:16:26] DEBUG: wait for ack
    [14:16:41] DEBUG: UART timeout
    [14:16:41] DEBUG: --- COM Port timeout on ACK read
    [14:16:42] DEBUG: wait for ack
    [14:16:57] DEBUG: UART timeout
    [14:16:57] DEBUG: --- COM Port timeout on ACK read
    [14:16:57] FATAL: Error loading the bootloader. Error code: -3
    [14:16:57] INFO: > Executing Operation: Disconnect
    [14:16:57] DEBUG: disconnecting from device . . .
    [14:16:57] DEBUG: wait for ack
    [14:17:12] DEBUG: UART timeout
    [14:17:12] DEBUG: --- COM Port timeout on ACK read
    [14:17:12] Operation Format returned.

    Below is an SPI log attempting to Format a Serial Flash. The lines begining 03 in the MOSI data are CC3100 read commands to the serial flash with a 24 bit address. After the first 4 bytes, the MISO data on the same line is the values returned.

    On good units I see 02 00 4C 53 returned for address 00 00 00 and FF FF FF FF returned for address 00 10 00. 

    Tektronix MDO4104C, version v1.06, serial number C001436
    Bus Definition: SPI
     Time  MOSI  MISO
    4.55E-06  AB  0
    9.78E-06  05 FF   00 00  
    2.51E-05  05 FF   00 00  
    4.00E-05  9F 5B BD 00   00 EF 40 14  
    5.93E-04  AB  0
    5.98E-04  05 FF   00 00  
    6.13E-04  05 FF   00 00  
    6.28E-04  9F 5B BD 00   00 EF 40 14  
    6.65E-04  05 FF   00 00  
    6.80E-04  03 00 00 00 5B BD 00 00   00 00 00 00 12 00 4C 5B  
    7.05E-04  05 FF   00 00  
    7.20E-04  03 00 10 00 5B BD 00 00   00 00 00 00 5C FF FF 5F  
    1.12E-03  05 FF   00 00  
    1.13E-03  03 00 00 00 5B BD 00 00 18 A7 06 20 18 A7 06 20 18 A7 06 20 00 00 00 00   00 00 00 00 12 08 4C 5B FF 00 FF 7F FF 01 FF 7F FF 02 FF 7F FF 23 FF 7F  
    3.07E-02  AB  0
    3.07E-02  05 FF   00 00  
    3.07E-02  05 FF   00 00  
    3.07E-02  9F 5B BD 00   00 EF 40 14  
    3.10E-02  05 FF   00 00  
    3.10E-02 6 0
    3.10E-02  05 FF   00 02  
    3.10E-02  05 FF   00 02  
    3.10E-02  01 00   00 00  
    3.10E-02  05 FF   00 03  

  • 0 in reply to Steve Tostevin
    TI__Mastermind 29085 points
    Hi Steve,

    Yes, it looks like the communication to the CC3100 is good because the GetVersion operation seems to be okay. It is interesting that there are just a few bits different in the response with the bad boards.

    For now, I'll close this thread. Please feel free to re-open it if needed by adding a response here. If the thread locks before you add a reply, go ahead and open a new post as a related question.

    Thanks,
    Ben M
  • 0 in reply to Benjamin Moore
    Prodigy 70 points

    Hi Ben,

    I have had some further thoughts on this problem. A possibility is that we are writing to the serial flash too many times and causing failure of the serial flash device.

    We don't really have any visibility of what provokes the CC3100 to write to the flash and it is difficult to decode SPI data to determine this. In normal operation we only see the CC3100 access the flash intermittently, but we also have another mode of operation where the CC3100 is searching for a connection. In this mode, we may sit in a loop indefinitely attempting to make connections to one of many different access points. During this cycle we call sl_start() and sl_DevGet(), sl_NetCfgSet() sl_WlanPolicySet() and sl_stop().

    Do any of these functions provoke the CC3100 to write to the serial flash?

    We perform this cycle approx every 15 seconds, so if we left a unit in this state for 6 days, we would just about wear out the serial flash.

    AS I'm writing this I'm thinking that you are going to ask for the NWP log, as you described previously. I'll try to set this up and get one sent out to you.

    Best Regards 

    Steve

  • 0 in reply to Steve Tostevin
    Prodigy 70 points

    Hi Ben,

    Attached are a couple of NWP Log files. They should show continually trying to connect to different Aceess Points and using the simplelink commands described previously.

    We are particularly interested in the frequency of writes to the serial flash, if that can be determined from the log files.

    Thanks and Regards

    Steve Tostevin

    TryConnectionsGoodFlash.log

    TryConnectionsBadSerialFlash.log

  • 0 in reply to Steve Tostevin
    TI__Mastermind 29085 points
    Hi Steve,

    Yes, those functions (specifically sl_NetCfgSet() and sl_WlanPolicySet()) result in serial flash writes when they are updating persistent settings for the network processor. For the persistent settings, there usually isn't a need to update that frequently.

    I'll take a look at the logs you sent. Thank you again for retrieving them.

    Are you able to (or have you tried to) swap out the serial flash on a bad board with the flash from a good board and see it work as expected (and similarly see the good board fail)?

    Best Regards,
    Ben M
  • 0 in reply to Benjamin Moore
    Prodigy 70 points

    Hi Ben,

    Thanks for the feedback, very helpful.

    Yes we did try swapping good/bad flash between boards, but we ended up with two boards not working. 2x3mm devices pretty difficult to mess with.

    Do you have any instructions or a program for decoding the NWP logs that you can send to us

    Thanks again

    Steve

  • 0 in reply to Steve Tostevin
    TI__Mastermind 29085 points
    Hi Steve,

    No, the tool for interpreting the NWP logs is not publicly available.

    Best Regards,
    Ben M
  • 0 in reply to Benjamin Moore
    TI__Mastermind 29085 points
    Hi Steve,

    I'm having a bit of trouble interpreting all of the "good" log, but I think I was able to see most of it. Looking at the commands that appear to be sent to the network processor in both files, I'm not seeing sl_NetCfgSet() and sl_WlanPolicySet() periodically.

    Could you try to check your ability to read from/write to various sectors on the flash from one of the bad systems with a SPI flashing tool? Perhaps we can see if these also show some sectors being inaccessible so we can know for sure if it is worn out.

    Best Regards,
    Ben M
  • 0 in reply to Benjamin Moore
    TI__Mastermind 29085 points
    Hi Steve,

    I haven't heard back from you in a while so I'm going to close this thread for now. If the issue is not closed on your end, you can reopen the thread by posting another reply. If you go to post a reply and the thread has locked, you can open a new thread and link to this one so we can continue the discussion.

    Thanks,
    Ben M
  • 0 in reply to Benjamin Moore
    Prodigy 70 points
    Hi Ben,

    Thanks for your help, I think we have taken this as far as we can at the moment

    Steve