Green Hills Multi Template

[jrubis]

Posted on March 03, 2008 at 10:32

Green Hills Multi Template

[jrubis]

Posted on May 17, 2011 at 12:24

Does anyone have a project template for an STM32 for Green Hills Multi IDE? I am looking for the linker directive file and board setup script.

Also does anyone know if the flash programmer in multi is compatible with the STM32? I am using multi 5.0.3 thanks

[ken]

Posted on May 17, 2011 at 12:24

I am also using GH Multi 5.0.3. Here is a link file that will work if you want to run out of RAM. Of course, for this to work you also need to remap the interrupt vectors to ram using the VTOR register in the SCB!

I am trying to figure out the flash programming myself. The part has 128K of flash, but it begins at 0x08000000. I can program this area using a different link file, but it is not yet repeatable. Once I get it figured out, I will follow up. The big question in my mind is, if the interrupt vectors at 0x00000000 are not in flash, where are they? I'm still researching this one. I got the app programmed entirely one time, but with no interrupt vectors it was less than stellar! MEMORY { // Start the application at 0x2008000 so as to not overwrite angel flash_memory : ORIGIN = 0x00000000, LENGTH = 128K iram_memory : ORIGIN = 0x20000000, LENGTH = 20K reg_memory : ORIGIN = 0x40000000, LENGTH = 144K } DEFAULTS { heap_reserve = 256 stack_reserve = 3000 } // // Program layout for running out of RAM. // // SECTIONS { // // The text segment // .vector : > iram_memory .picbase : > . .text : > . .syscall : > . .intercall : > . .interfunc : > . .fixaddr : > . .fixtype : > . .rodata : > . .secinfo : > . // // The data segment // .pidbase ALIGN(16) : > . .sdabase : > . .sbss : > . .sdata : > . .data : > . .bss : > . .heap ALIGN(16) PAD(heap_reserve) : > . .stack ALIGN(16) PAD(stack_reserve) : > . // // These special symbols mark the bounds of RAM and ROM memory. // They are used by the MULTI debugger. // __ghs_romstart = MEMADDR(flash_memory); __ghs_romend = MEMENDADDR(flash_memory); __ghs_ramstart = MEMADDR(iram_memory); __ghs_ramend = MEMENDADDR(reg_memory); }

[jrubis]

Posted on May 17, 2011 at 12:24

Currently I cant even get my probe to program the board. I have attempted both a build for RAM execution and one for ROM execution. Neither load properly.

Have you had any luck programming your board? What debugger are you using? If you are using a GH probe can you tell me your firmware version and settings? thx

[ken]

Posted on May 17, 2011 at 12:24

Here is the result of my ''target info'' command:

Target: Green Hills Probe v3.1 Target: DEVELOPMENT RELEASE Target: Firmware built Sep 25 2007 16:06:46 Target: Serial No: 7439 Target: Major version: 3 Target: Minor version: 1 Target: Protocol version: 85 Probably just as important, check the following with ''target set''. Pay close attention to the target = other(...). That has to do with the JTAG toolchain and it will not function if that is not correct. Target: dhcp = off Target: ip = 172.16.13.45 Target: netmask = 255.255.255.0 Target: gateway = 0.0.0.1 Target: hostname = ghprobe7439 Target: single_mpserv_only = off Target: adapter = auto [arm-20] Target: clock = 1 MHz Target: use_rtck = off Target: rtck_use_timeout = on Target: logic_high = 3.300000 Target: target = other(5,0x1f,1) cortexm3 Target: checker = on Target: power_detect = on Target: user_button = tri-state Target: user_string = Target: baudrate = 9.6 kbaud Target: rst_pulse = 1 s Target: rst_settle = 1 s Target: jrst_pulse = 1 s Target: jrst_settle = 1 s Target: target_reset_pin = independent Target: catch_buserr = off Target: catch_chkerr = off Target: catch_harderr = off Target: catch_interr = off Target: catch_mmerr = off Target: catch_nocperr = off Target: catch_reset = off Target: catch_staterr = off Target: endianness = little I am making slow progress programming the flash. I can now program my app, but still can't do the interrupt vectors at 0x00000000.

[jrubis]

Posted on May 17, 2011 at 12:24

We are using the same firmware version. I modified my probe settings to match yours. Still no luck. Are you running a board setup script? If so can you share it with me? Do you have any patches applied to 5.0.3?

[ken]

Posted on May 17, 2011 at 12:24

I have spent literally all day working on this very issue. I have an open incident with Green Hills. I have spoke with the tech support guy there as well as my FAE, who suggested I get passed through to the engineer at the main office who worked with this board.

In my case, the GHS flash program tells me it programmed successfully, but it does not verify. Here is my romrun linkfile - maybe it will help you a little way on the path to success. If I ever get my flashing to work, I'll update here. Please do the same if you figure it out before I do. Thanks. By the way, I'm currently looking at the BOOT0:BOOT1 pins, but I have tried all 4 possible combinations and none work. MEMORY { // Define memory map // vector_memory: ORIGIN = 0x00000000, LENGTH = 1K flash_memory : ORIGIN = 0x08000000, LENGTH = 128K iram_memory : ORIGIN = 0x20000000, LENGTH = 20K reg_memory : ORIGIN = 0x40000000, LENGTH = 144K } DEFAULTS { heap_reserve = 256 stack_reserve = 3000 } // // Program layout for starting in ROM, copying data to RAM, // and continuing to execute out of ROM. // SECTIONS { // // ROM SECTIONS // .vector : > flash_memory .text : > . .syscall : > . .intercall : > . .interfunc : > . .rodata : > . .sdata2 : > . .secinfo : > . .fixaddr : > . .fixtype : > . .CROM.sdata CROM(.sdata) : > . .CROM.data CROM(.data) : > . // // RAM SECTIONS // .sdabase : > iram_memory .sbss : > . .sdata : > . .data : > . .bss : > . .heap ALIGN(16) PAD(heap_reserve) : > . .stack ALIGN(16) PAD(stack_reserve) : > . // // These special symbols mark the bounds of RAM and ROM memory. // They are used by the MULTI debugger. // __ghs_romstart = MEMADDR(flash_memory); __ghs_romend = MEMENDADDR(flash_memory); __ghs_ramstart = MEMADDR(iram_memory); __ghs_ramend = MEMENDADDR(iram_memory); // // These special symbols mark the bounds of RAM and ROM images of boot code. // They are used by the GHS startup code (_start and __ghs_ind_crt0). // __ghs_rombootcodestart = ADDR(.text); __ghs_rombootcodeend = ENDADDR(.fixtype); __ghs_rambootcodestart = 0; __ghs_rambootcodeend = 0; }

[ken]

Posted on May 17, 2011 at 12:24

I have not applied any patches. My script is VERY simple, here it is in all its glory!

target tr -s d

[jrubis]

Posted on May 17, 2011 at 12:24

Looks like I may have had a bad JTAG cable. I am now programming the RAM and the program looks to be executing.

The flash programmer is still reporting an error when I attempt to program the flash. Not sure why.

[ken]

Posted on May 17, 2011 at 12:24

I can now program the flash successfully every time, but now I am trapping on faults that I never experienced when running out of RAM. I have tracked the problem down to the SP being set to a location in flash, which doesn't work very well ! If I get it figured out, I'll post here.

By the way, my problem with not being able to flash repeatedly came down to the fact I needed to set SCB->VTOR = 0x08000000. I had mistakenly assumed this should be 0, but figured it out last night.