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.

CC3200: sl_FsOpen() API returns error -49 when trying to open file from flash on CC3200 based board

Part Number: CC3200
Other Parts Discussed in Thread: UNIFLASH

Hi,

We are developing on a custom board based on CC3200 MCU,

Our application requires us to have a secondary bootloader and a application .

We are flashing both of them using Uniflash.

we follow the following steps:

-> Format and then,

-> Program

our boot process is :

we have written one bootloader which is programmed on the filesystem as /sys/mcuimg.bin. The bootloader loads and execute our application and the issue which we are facing is when bootloader tries to open application.bin which is something like "/sys/XXXX.bin" on the filesystem . i.e it is added as a user file while flashing.

We reboot our board many times and on some boards we have observed this that
when calling sl_FsOpen() API to open the application file (/sys/XXXX.bin) it returns -49 error .

NOTE : this issue has been observed on a working board and not just after flashing and trying to boot.

Also this issue is very very random and we dont have the steps to reproduce it yet, but after this issue occurs our boot process is stuck and the only option to recover from this is to reflash the board i.e it does not recover even after hardware reset or even after removing the power source(battery in our case) and connecting it back again.

This happens probably when randomly reseting the board or powering the board randomly or by software reset by calling the PRCMMCUReset().


We are using CC3200 MCU and along with it 1MB SFLASH; part number : M25PX80-VMN6TP


One thing observed with this is after this issue occurs we have listed the filesystem using uniflash tool and can see /tmp/phy.cal file is missing which is not the case with the boards working fine I dont know if this is related but just a observation.
Also find attached the output of the listfilesystem taken from Uniflash tool of both the working and suddenly stuck board which was working fine previously.

0572.listfilesystem_onboardwithissue.txt
[13:47:15] INFO: > Executing Operation: ListFileSystem
[13:47:15] INFO: extracting file system information...
[13:47:15] INFO: 	file	start	size	fail	total size	filename
[13:47:15] INFO: 	index	block	[BLKs]	safe	[BLKs]
[13:47:15] INFO: ----------------------------------------------------------------------------
[13:47:15] INFO: 	N/A	0	5	N/A	5		FATFS
[13:47:15] INFO: 	0	15	7	yes	14		/sys/mcuimg.bin
[13:47:15] INFO: 	6	29	24	no	24		/sys/XXXX.bin
[13:47:15] INFO: 	7	53	1	yes	2		/sys/mcubootinfo.bin
[13:47:15] INFO: 	8	55	1	yes	2		/sys/stacfg.ini
[13:47:15] INFO: 	9	57	2	yes	4		/sys/pref.net
[13:47:15] INFO: 	10	61	1	yes	2		/sys/ipcfg.ini
[13:47:15] INFO: 	11	63	1	yes	2		/sys/mode.cfg
[13:47:15] INFO: 	12	65	1	yes	2		/sys/pmcfg.ini
[13:47:15] INFO: 	13	67	1	yes	2		/sys/mdns.cfg
[13:47:15] INFO: 	14	69	1	yes	2		/sys/ap.cfg
[13:47:15] INFO: 

	Flash usage
[13:47:15] INFO: -------------------------
[13:47:15] INFO: used space:	61 blocks
[13:47:15] INFO: free space:	195 blocks
[13:47:15] INFO: memory hole:	[5-14]
[13:47:15] INFO: memory hole:	[71-255]

7824.listfilesystem_onboardwithnoissue.txt
[14:51:22] INFO: extracting file system information...
[14:51:22] INFO: 	file	start	size	fail	total size	filename
[14:51:22] INFO: 	index	block	[BLKs]	safe	[BLKs]
[14:51:22] INFO: ----------------------------------------------------------------------------
[14:51:22] INFO: 	N/A	0	5	N/A	5		FATFS
[14:51:22] INFO: 	0	15	7	yes	14		/sys/mcuimg.bin
[14:51:22] INFO: 	4	5	5	yes	10		/tmp/phy.cal
[14:51:22] INFO: 	6	29	24	no	24		/sys/XXXX.bin
[14:51:22] INFO: 	7	53	1	yes	2		/sys/mcubootinfo.bin
[14:51:22] INFO: 	8	55	1	yes	2		/sys/stacfg.ini
[14:51:22] INFO: 	9	57	2	yes	4		/sys/pref.net
[14:51:22] INFO: 	10	61	1	yes	2		/sys/ipcfg.ini
[14:51:22] INFO: 	11	63	1	yes	2		/sys/mode.cfg
[14:51:22] INFO: 	12	65	1	yes	2		/sys/pmcfg.ini
[14:51:22] INFO: 	13	67	1	yes	2		/sys/mdns.cfg
[14:51:22] INFO: 	14	69	1	yes	2		/sys/ap.cfg
[14:51:22] INFO: 

	Flash usage
[14:51:22] INFO: -------------------------
[14:51:22] INFO: used space:	71 blocks
[14:51:22] INFO: free space:	185 blocks
[14:51:22] INFO: memory hole:	[71-255]

  • Hi,

    Why you not have ServicePack in your device? What SDK version do you use?

    Update:

    Your type of flash memory (M25PX80) is not recommended to use - see: http://processors.wiki.ti.com/index.php/CC3100_%26_CC3200_Serial_Flash_Guide

    Jan

  • Hi Sagar,

    Error (-49) is below from fs.h:
    #define SL_FS_NO_DEVICE_IS_LOADED (-49)

    Can you test your software on a Launchpad and look for a similar result? It may possibly be hardware related.

    I don't believe /tmp/phy.cal would be a deciding factor in your booting. You can take a look at the full list of system and configuration files here: processors.wiki.ti.com/.../CC3100_&_CC3200_Serial_Flash_Guide

    Best regards,
    Sarah

  • Hi Sarah,

    On behalf of Sagar, we have gsm and gps modules interfaced with our board i dont think we can run the software on the reference board. Our software will not work, also this is very random and not easily reproducible.

    Regards,

    Mohit

  • Hi Mohit,

    Definitely you have two things wrong. You have no service pack in device and you use serial flash type (M25PX80) which is not recommended. I think both points can be reason of your issue.
    Also I not agree with Sarah that missing file /tmp/phy.cal is not important factor. Missing this file can signalise issue with NWP (issue with writing radio calibration file into sFlash).

    Please follow this steps:
    - take one board with issue and do not change your firmware
    - format sFlash in your board, upload latest ServicePack, upload your firmware and test it. If this test failed go to next step.
    - exchange your flash M25PX80 to different type, format, upload ServicePack, upload your firmware and test it

    Jan

  • Hi Jan ,

    Thanx for the reply we are following the steps you have suggested and will reply with the results .


    @Sarah,@Jan
    what is the significance/meaning of this "SL_FS_NO_DEVICE_IS_LOADED " which is error -49. i mean secondary bootloader is loading properly from the flash but when this secondary bootloader tries to fetch our main application, we get this error. And Please NOTE: application is there in the same location on the flash as i can see through the logs of the list file system on the uniflash tool run on the board once the issue is observed.

    Br,
    Mohit
  • Hi Mohit,

    Meaning of error code -49 - https://e2e.ti.com/support/wireless_connectivity/simplelink_wifi_cc31xx_cc32xx/f/968/t/381382

    Just a two another question.
    - What version of SDK do you use? Is there reason why you not have Servicepack inside your device?
    - A final one dumb question. I suppose that you not forgot start SimpleLink inside your secondary bootloader before you call FS API. That is right?

    Jan

  • Hi Jan,

    -> We are using SDK version 1.1.0 and there is no particular reason for not pushing the service pack on the device and now after your suggestion we are trying to push service pack version 1.0.1.5.0.

    -> We call the sl_start api before we call any of the FS API.


    Br,
    Mohit
  • Hi Mohit,

    No, I don't agree. Using SDK 1.1.0 without particular service pack is really bad idea and definitely this is not recommended.

    Jan
  • Hi Jan,

    I have few questions :

    1. How does the service pack relate to the issue i am seeing ?

    2. Why would /tmp/phy.cal file get deleted from the flash and i know it was there before the issue occured ? 

    Br,

    Mohit

  • Hi Mohit,

    ServicePacks are designed to patch bugs in ROM firmware for NWP (network processor) firmware. All SimpleLink API calls (even filesystem API) are served by NWP and its firmware. With service packs are released notes which describes changes in specific ServicePack version. As I know, that not all changes are noted in this release notes. I am not able say, if there are not fixes related to serial flash (maybe somebody from TI can confirm that;  But something says me that I read thread at E2E forum about sFLash access bug which was planned to fix in ServcePack, now I am not able find this thread).

    Your error code signalise that you have essential problem with communication between NWP and serial flash. Also that NWP not create PHY calibration file can be connected with writing problem into serial flash. Possible reasons of issue (sorted by most likely causes):

    - problem with using unsupported serial flash M25PX80 (see: https://e2e.ti.com/support/wireless_connectivity/simplelink_wifi_cc31xx_cc32xx/f/968/p/426518/1525375#1525375 )

    - issue in NWP firmware (fixed in ServicePack?)

    - problem with your hardware design (design with QFN version of CC3200 is challenge and maybe your hardware fails in particular conditions)

    - issue with your firmware

    Alternatively there can be two possible ways (see below) how your problem hide. But I think better will be find reason of your problems. I can't guarantee that this will work in your case, you need test it.

    - you can restart NWP when issue in your bootloader is detected /sl_Stop() and sl_Start()/ and repeat attempt to file access

    - do full SOC CC3200 reset when is issue in your bootloder detected. For SoC CC3200 reset use this code:

    sl_Stop(0); // if NWP is running
    MAP_PRCMHibernateIntervalSet(330);
    MAP_PRCMHibernateWakeupSourceEnable(PRCM_HIB_SLOW_CLK_CTR);
    MAP_PRCMHibernateEnter();

    By the way... PRCM API call PRCMSOCReset() is not recommanded to use. For full CC3200 SoC recovery is recommended code above. More information you find at known issue - http://processors.wiki.ti.com/index.php/CC32xx_Summary_of_Known_Issues#Driverlib_API_changes

    Jan

  • Hello Jan,

    Since this is very rare and not easily reproducible ... So what we have done instead of resetting the soc or restarting the NWP we removed the power source and then connected it back again. Still fsopen returns -49 when trying to open the application from the boot loader ... One thing i m not convinced is if there is some problem between communication between the NWP and the sflash then before reading this application Boot loader is loaded perfectly.

    We have tried the steps suggested by you .. we flashed the service pack in our devices and strangely ... Since 3 days and out of around 200 boards it has happened in only one board ,but this time /tmp/phy.cal is not missing.

    BR

    Mohit