• Locked Locked
  • Replies 3 replies
  • Subscribers 119 subscribers
  • Views 6352 views
  • Users 0 members are here
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

Need help with IAR Embeeded Workbench Linker

ckuecker ckuecker
Note: This was originally posted on 5th January 2010 at http://forums.arm.com

Hello,

I am working with a Luminary LM3S6965 processor in a product that is intended to be firmware-upgradable in the field. We have an Ethernet port that we connect to a server that can use a proprietary protocol to download new firmware. Our product code is divided into two sections, a boot loader that resides at the start of flash, and an application that resides at 0x10000. If the boot loader detects a valid downloaded upgrade, it copies it from an unused area of flash to 0x10000 and erases the downloaded code. The boot loader is self-contained, and after verifying a valid application, jumps into a fixed vector table located at 0x10000. The application takes care of all its' initialization. Interrupt vectors are steered up to the same vector table at 0x10000 and handled in the application. The bootloader does not use any interrupts.

I had the system working originally by building one big program, with the boot loader and application code separated by linker configuration file commands. Unfortunately, the IAR linker does not allow me to reliably keep various parts of the code separated - for instance, the initialization code that should have been for the bootloader gets placed somewhat randomly in the application code, and therefore the vector from the bottom of flash points to the wrong location after we do a firmware upgrade.

I tried to fix this by going to two separate programs, and the IAR debugger disassembly window tells me I have succeeded in getting everything into its' proper place. Unfortunately, the debugger refuses to load the application code and run properly, telling me 'Warning: __vector_table symbol not found." The code runs directly into the fault IRQ handler and hangs.

I had previously loaded the bootloader section of the code into flash using the debugger, exited, and then loaded the application code with the debugger. The bootloader's vector table is still at the start of flash memory, and it appears proper in the disassembler window. The debugger evidently cannot figure out how to start the code correctly.

I tried running the code as a system, without the debugger, and it hangs up, so there's a bug in there for real. I need to get the system running under the IAR debugger to find and fix the problem.

Anyone had a similar situation and lived to tell of it?
  • Note: This was originally posted on 6th January 2010 at http://forums.arm.com

    Got the linker squared away - but there's a problem in the IAR startup code. The code executes a pop in one of the initialization routines, and the resulting PC is garbage.

    I've sent the zip file of the whole project to IAR - they are looking into the issue.

    Chuck
  • Note: This was originally posted on 7th January 2010 at http://forums.arm.com

    Hello,

    I am working with a Luminary LM3S6965 processor in a product that is intended to be firmware-upgradable in the field. We have an Ethernet port that we connect to a server that can use a proprietary protocol to download new firmware. Our product code is divided into two sections, a boot loader that resides at the start of flash, and an application that resides at 0x10000. If the boot loader detects a valid downloaded upgrade, it copies it from an unused area of flash to 0x10000 and erases the downloaded code. The boot loader is self-contained, and after verifying a valid application, jumps into a fixed vector table located at 0x10000. The application takes care of all its' initialization. Interrupt vectors are steered up to the same vector table at 0x10000 and handled in the application. The bootloader does not use any interrupts.

    I had the system working originally by building one big program, with the boot loader and application code separated by linker configuration file commands. Unfortunately, the IAR linker does not allow me to reliably keep various parts of the code separated - for instance, the initialization code that should have been for the bootloader gets placed somewhat randomly in the application code, and therefore the vector from the bottom of flash points to the wrong location after we do a firmware upgrade.

    I tried to fix this by going to two separate programs, and the IAR debugger disassembly window tells me I have succeeded in getting everything into its' proper place. Unfortunately, the debugger refuses to load the application code and run properly, telling me 'Warning: __vector_table symbol not found." The code runs directly into the fault IRQ handler and hangs.

    I had previously loaded the bootloader section of the code into flash using the debugger, exited, and then loaded the application code with the debugger. The bootloader's vector table is still at the start of flash memory, and it appears proper in the disassembler window. The debugger evidently cannot figure out how to start the code correctly.

    I tried running the code as a system, without the debugger, and it hangs up, so there's a bug in there for real. I need to get the system running under the IAR debugger to find and fix the problem.

    Anyone had a similar situation and lived to tell of it?


    "I had the system working originally by building one big program" This sentence does not sound right.
    Normally the bootloader is some self-contained stand-alone application. And the firmware is also like that.
    Bootloader generally has nothing to do with the Firmware except the FirmwareEntryPointAddress...
    Just develop 2 different projects titled as Bootloader and Firmware and stick with it...

    For the debugging part , you should debug them separately. You debug the Firmware
    just as if no bootloader exists. After debugging , fix its link map and build for the last time
    to package it as the new firmware. You may build a very small test firmware just to test
    if the bootloader jumps to the right place. You can even debug the bootloder as it jumps
    to the Firmware. Do not forget , after the jump, everything will be in assembly...

    I do not work with IAR but Keil. I do not think they differ at all...
  • Note: This was originally posted on 10th January 2013 at http://forums.arm.com


    Hello,

    I am working with a Luminary LM3S6965 processor in a product that is intended to be firmware-upgradable in the field. We have an Ethernet port that we connect to a server that can use a proprietary protocol to download new firmware. Our product code is divided into two sections, a boot loader that resides at the start of flash, and an application that resides at 0x10000. If the boot loader detects a valid downloaded upgrade, it copies it from an unused area of flash to 0x10000 and erases the downloaded code. The boot loader is self-contained, and after verifying a valid application, jumps into a fixed vector table located at 0x10000. The application takes care of all its' initialization. Interrupt vectors are steered up to the same vector table at 0x10000 and handled in the application. The bootloader does not use any interrupts.

    I had the system working originally by building one big program, with the boot loader and application code separated by linker configuration file commands. Unfortunately, the IAR linker does not allow me to reliably keep various parts of the code separated - for instance, the initialization code that should have been for the bootloader gets placed somewhat randomly in the application code, and therefore the vector from the bottom of flash points to the wrong location after we do a firmware upgrade.

    I tried to fix this by going to two separate programs, and the IAR debugger disassembly window tells me I have succeeded in getting everything into its' proper place. Unfortunately, the debugger refuses to load the application code and run properly, telling me 'Warning: __vector_table symbol not found." The code runs directly into the fault IRQ handler and hangs.

    I had previously loaded the bootloader section of the code into flash using the debugger, exited, and then loaded the application code with the debugger. The bootloader's vector table is still at the start of flash memory, and it appears proper in the disassembler window. The debugger evidently cannot figure out how to start the code correctly.

    I tried running the code as a system, without the debugger, and it hangs up, so there's a bug in there for real. I need to get the system running under the IAR debugger to find and fix the problem.

    Anyone had a similar situation and lived to tell of it?

    Hi,
    I have the same issue. Did you fix it?

    Thank you.