• State Not Answered
  • Locked Locked
  • Replies 17 replies
  • Subscribers 21 subscribers
  • Views 3600 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Reset after success remote update

Kobi Hayun

Hi All,

I managed to update my FW, but the new FW is not start to work.

I checked that the new FW is burn correctly (I verify it with uVision3 with the verify option at the utility settings).

Please advice Kobi

  • 0 in reply to Kobi Hayun

    Hi Kobi,

    Thanks again.

    I have a little confuse. I'd checked the address 0x14, it should be and interrupt vector (VicVectAddr) in my startup.s, like below.

    //Startup.s
Vectors
    LDR PC, Reset_Addr
    LDR PC, Undef_Addr
    LDR PC, SWI_Addr
    LDR PC, PAbt_Addr
    LDR PC, DAbt_Addr
    NOP                    ; Reserved Vector
;   LDR PC, IRQ_Addr
    LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
////////

    I know how to write flash by IAP function. Actually, I don't know how to write a program to update entire flash, so I separate my image to two regions. And hope the boot region is fixed (but not). I found the problem might happen in __user_initial_stackheap() or __user_setup_stackheap(). Because KEIL will add them if I don't override them. Similar, if my application use the new function that need C library. KEIL compiler will increase the C library into my boot region since my scatter.

    However, if I can know how to re-write the entire flash in runtime, I don't need to care the KEIL compiler did. Can you show me how?

    Best Regards,
    Dennis.

  • 0 in reply to Dennis Liao

    Hi Dennis,

    In order to update all the FLASH you need to run your IAP functions from the RAM.

    After you receive you new FW image, and you decide to burn it, your application should run a routine from the RAM that will erase all the FLASH and will burn the new one instead of it. Obviously you should save the new FW at external FLASH or save it at the upper addresses of you controller and therefore erase only half of the controller.

    In my case, I received the new image to external FLASH, then parse it and copy it to the upper controller addresses and as soon as the new FW is at the controller, I run routine from the RAM in order to copy it from the upper addresses to the lower one.
    This architecture can be more efficient (copy it from the external FLASH directly to the lower controller addresses) but the first one requires less code in the RAM.

    In addition you have to add the checksum to the new image at address 0x14. The old ISP application of NXP add the checksum to the code.

    Regards Kobi