• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 3 answers
  • Subscribers 56 subscribers
  • Views 846 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

WEBENCH® Tools/CC2538: How to solve this Fatal error : (Error -1268 @ 0x90001) Device is locked up in Hard Fault or in N

CC2538: OTA Image Upgrade Using ZIgbee Linux Gateway 3.0 goes in to Repetitive Mode.

shiv patil
Genius 3356 points
Part Number: CC2538
Other Parts Discussed in Thread: Z-STACK, , UNIFLASH

Hello E2E community,

I am working on CC2538 Zigbee Z-stack Embedded firmware. I am trying to implement OTA Upgrade to upgrade the firmware for SampleLight Application.

For that i am referring TI's "Z-stack OTA Upgrade User's Guide.pdf" 

As per the instructions given in chapter 2 3 & 4,  I made the changes for OTA upgrade in SampleLight Project.

Till now I am able to Implement OTA upgrade get processed & completed successfully. 

But now I am facing some problems like,

1. After getting OTA Upgrade End Request form the Zigbee device, it will wait for some time & then it will restart the upgrade from the beginning. 
   

     I am not getting why this is happening so far!!....

2. How I get the  running image details on Zigbee Linux Gateway Application. 

OR

How to check weather that image will written on the allocated memory slot or not.

Thanks & Regard's

Shiv Patil.

  • 0
    Expert 2745 points

    1. Please review end of function zclOTA_Init,it will send "next image request" periodically,if you don't need this feature,you can commit it as following 

    #if 0
  // Per section 6.1 of ZigBee Over-the-Air Upgrading Cluster spec, we should
  // periodically query the server. It does not specify the rate.  For example's
  // sake, here we query the server periodically between 5-10 minutes.
  uint32 queryImgJitter = ( ( uint32 ) osal_rand() % OTA_NEW_IMAGE_QUERY_RATE ) + ( uint32 ) OTA_NEW_IMAGE_QUERY_RATE;
  osal_start_reload_timer ( task_id, ZCL_OTA_QUERY_SERVER_EVT, queryImgJitter );

  // Wake up in 5 seconds and do some service discovery for an OTA Server
  queryImgJitter = ( ( uint32 ) 5000 );
  osal_start_reload_timer ( task_id, ZCL_OTA_SEND_MATCH_DESCRIPTOR_EVT, queryImgJitter );
#endif  
  // Initiliaze OTA Update End Request Transaction Seq Number
  zclOta_OtaUpgradeEndReqTransSeq = 0;

#endif // (defined OTA_CLIENT) && (OTA_CLIENT == TRUE)

    2. If you want find any associate zigbee OTA information from Zigbee Linux Gateway Application,you need review all source code in directory "Source\Projects\zstack\linux\otaserver"

  • 0
    TI__Guru**** 217417 points
    Hello Shiv,

    Please refer to the Documents/sample_app_ota_readme.txt of the Linux Gateway software package for further instructions on using the Z-Stack Gateway as a server for updating the firmware of remote devices.

    Regards,
    Ryan
  • 0 in reply to behold li
    Genius 3356 points
    Hello Behold & Ryan,

    It helps me to solve the problems related the OTA upgrade stuck in to repetitive mode. I am able to do OTA image transfer from initial image to new image over image area A & B.

    Now I want's to test it further for alternately transferring the images A & B, also for increasing the speed of the OTA upgrade image transfer by increasing payload size.
    I have made some test cases & getting some new issues related to OTA upgrade image transfer. which are as follow's...



    1. If I am transferring the upgraded version image over the image area A which already contains a running initial image( Old Version),
    OTA upgrade transfer get succeeded up to the image end request response but, my code stuck all functionality after OTA transfer &
    get reset.

    same thing happens when I am transferring image A again after successfully upgraded with image area B with another image
    version.

    Is it necessary to upgrade new image only on the image area B?
    What is the standardized procedure to swapping the image A & B areas as long as new versions are releases?


    2. As we know the OTA Image Upgrade will take minimum 10-15 minutes to successfully transfer a singe image. which is time
    consuming when we have more number of devices to upgrade.
    So I am thinking about speeding up the transfer by increasing the payload size of the frame request.
    Right now the Payload size is set to 32 bit long. I have tested the OTA image transfer successfully for the pay load size 64 byte.
    but it will throws exceptions/ errors when I have increased it up to 128 byte.

    What will be the max supported payload size?
    Is it secured & really help full to speed up the transfer by increasing the payload size?


    Will you please help me to solve those issues too...


    Thanks & Regard's
    Shiv Patil.
  • 0 in reply to shiv patil
    Expert 2745 points
    1.CC2538 OTA architecture only support upgrade "Image A" to "Image B" or vise versa,don't support upgrade "Image A" to "Image A" or "Image B" to "Image B",this must be caused chip lock unexpected,so you have do version judge on OTA server,as we all know,initial image is "Image A" but default version number equal "1".

    2.As far as know,once OTA take at least 30 minutes,you should not increase MTU(default 32 byte),this may be caused unexpected glitch,we have been test 30+ device OTA simultaneously,this work well.
  • 0 in reply to behold li
    Genius 3356 points
    Thank you behold,

    I have completely understood what are you saying.

    But I am not getting some concepts...

    1. If I have been updated image B over image A (witch in initial image). Now the running image is Image B.
    For the Next Upgrade I have to write image A. should I Mention the OTA_INITIAL_IMAGE Flag in configuration for image A?..

    2. how do I know currently which image is in running state?... either it is Image A's image or Image B.

    Thanks & Regard's
    Shiv Patil.
  • 0 in reply to shiv patil
    Expert 2745 points

    Assume you test with SampleSwitch.eww IAR project,There are three build options for ZED,The initial image named "EndDevice - OTAClient - ImageA - withBootloader" was build with bootloader,this firmware must be burn with Flash programmer 2 or Uniflash tools etc ,this is "Image A" but within bootloader intentionally,as you see,this defined Preprocesser MACRO as following:

    OTA_INITIAL_IMAGE
HAL_IMG_AREA=0

    If you build "Image A" or "Image B" without bootloader,that must be defined MACRO HAL_IMG_AREA=0 or HAL_IMG_AREA=1 without OTA_INITIAL_IMAGE.

    If the OTA server received "Query Next Image" command,this packet must be include Version identifier named "AAAA0000" for "Image A" or "BBBB1000" for "Image B",you need judge version to prevent upgrade incorrect firmware.