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

LOL! Sounds like parallel effort with GH. I also have a support request open.

I am receiving the same error msg after flashing the board. I am going to work on it tonight along with the RAM load and see what I can get to work. I will post here if I find a solution or if support provides a solution.

[jrubis]

Posted on May 17, 2011 at 12:24

What does your vector table look like?

[ken]

Posted on May 17, 2011 at 12:24

My vector table is pretty simple. Here is how it is defined currently.

VectTableStart: DCD __ghsend_stack ; 0x00000000 Stack top address DCD _start ; 0x00000004 Reset DCD NMIHandler ; 0x00000008 NMI DCD HardFaultHandler ; 0x0000000C Hard fault DCD MemMgmtHandler ; 0x00000010 Memory management DCD BusFaultHandler ; 0x00000014 Bus fault DCD UsageFaultHandler ; 0x00000018 Usage fault DCD DefaultHandler ; 0x0000001C Reserved DCD DefaultHandler ; 0x00000020 Reserved DCD DefaultHandler ; 0x00000024 Reserved DCD DefaultHandler ; 0x00000028 Reserved DCD SWIHandler ; 0x0000002C System service call via SWI DCD DebugHandler ; 0x00000030 Debug monitor DCD PendingHandler ; 0x00000034 Reserved DCD DefaultHandler ; 0x00000038 System service DCD SysTick_ISR ; 0x0000003C systick DCD DefaultHandler ; 0x00000040 Window watchdog timer DCD DefaultHandler ; 0x00000044 PVD DCD DefaultHandler ; 0x00000048 Tamper DCD DefaultHandler ; 0x0000004C RTC DCD DefaultHandler ; 0x00000050 Flash DCD DefaultHandler ; 0x00000054 RCC DCD DefaultHandler ; 0x00000058 EXTI0 DCD DefaultHandler ; 0x0000005C EXTI1 DCD DefaultHandler ; 0x00000060 EXTI2 DCD DefaultHandler ; 0x00000064 EXTI3 DCD DefaultHandler ; 0x00000068 EXTI4 DCD DefaultHandler ; 0x0000006C DMA1 DCD DefaultHandler ; 0x00000070 DMA2 DCD DMA3TC_Handler ; 0x00000074 DMA3 DCD DefaultHandler ; 0x00000078 DMA4 DCD DMA5TC_Handler ; 0x0000007C DMA5 DCD DefaultHandler ; 0x00000080 DMA6 DCD DefaultHandler ; 0x00000084 DMA7 DCD DefaultHandler ; 0x00000088 ADC DCD DefaultHandler ; 0x0000008C CAN tx DCD DefaultHandler ; 0x00000090 Can rx0 DCD DefaultHandler ; 0x00000094 Can rx1 DCD DefaultHandler ; 0x00000098 CAN SCE DCD DefaultHandler ; 0x0000009C EXT Line[9:5] DCD DefaultHandler ; 0x000000A0 TIM1 break DCD DefaultHandler ; 0x000000A4 TIM1 update DCD DefaultHandler ; 0x000000A8 TIM1 trigger DCD DefaultHandler ; 0x000000AC TIM1 capture compare DCD DefaultHandler ; 0x000000B0 TIM2 DCD DefaultHandler ; 0x000000B4 TIM3 DCD DefaultHandler ; 0x000000B8 TIM4 DCD DefaultHandler ; 0x000000BC I2C1 event DCD DefaultHandler ; 0x000000C0 I2C1 error DCD DefaultHandler ; 0x000000C4 I2C2 event DCD DefaultHandler ; 0x000000C8 I2C2 errpr DCD DefaultHandler ; 0x000000CC SPI1 DCD DefaultHandler ; 0x000000D0 SPI2 DCD USART1_Handler ; 0x000000D4 USART1 DCD DefaultHandler ; 0x000000D8 USART2 DCD DefaultHandler ; 0x000000DC USART3 DCD DefaultHandler ; 0x000000E0 EXT line[15:10] DCD DefaultHandler ; 0x000000E4 RTC alarm DCD DefaultHandler ; 0x000000E8 USB wakeup

[jrubis]

Posted on May 17, 2011 at 12:24

I would think that the:

__ghsend_stack ; 0x00000000 Stack top address would place the correct stack address (RAM). I did run into an issues a few months ago where ghsend_stack was returning an addresss that was in flash and not RAM. I though it was a bug that has since been resolved.

[ken]

Posted on May 17, 2011 at 12:24

Yes, the stack is being set correctly by the linker. My problem now is that after flashing my application and doing a reset, I can see the first line of code is _start, as expected. However, when I try to single step, a hard fault is generated. The registers indicate the source is a line of code that is in a separate routine that has not come close to being executed by the single step I tried to execute. Prior to fixing the stack info at the base of the interrupt table, the hard fault was indicating the stack was the problem, and this was correct at the time. Now that I have fixed the stack, this new problem has me scratching my head.

[ken]

Posted on May 17, 2011 at 12:24

Can you post some specifics of the errors you are seeing with the GHS tools? Are you using the Probe, Slingshot, or SuperTrace? I am pushing to get in contact with the developers, so any additional info I can provide might be helpful.

[jrubis]

Posted on May 17, 2011 at 12:24

I am using a standard GH Probe. My the current error that I am receiving is the same one you were seeing (i believe). The verification failure after flashing the board.

While support was/is working on this, I wanted to get some basic interrupts to function while running out of RAM. The first thing I realized is that I didn’t have a vector table. I had the ISRs from the ST Firmware lib by since I didn’t have a vector table the handlers weren’t being hit. Then I started to wonder how the reset exception was being handled and started poking around in the startup code. Since then I haven’t had much time to go any further. I am doing this on the side more for self interest than for an actual project at work. [ This message was edited by: jrubis on 29-02-2008 19:45 ]

[jrubis]

Posted on May 17, 2011 at 12:24

Can you send me a copy of you project?

I am now able to flash my board my but I am not sure if I understand how you are defining your vector table.

[jrubis]

Posted on May 17, 2011 at 12:24

I now have a program running out of flash. The program is the EXTI (External Interrupt) example that is part of the STM32 firmware lib.

I am running it on my STM32EVB. Looks like the code is handling the interrupt call okay. The only issues I currently have are: 1. Some times I need to press the reset on the EVB before I flash the board. I think there is an issue with the probe being able to halt the target. 2. For some reason I needed to define _start_T instead of _start in my vector table. Not sure what the difference is. I need to research this. [ This message was edited by: jrubis on 02-03-2008 00:06 ]

[ken]

Posted on May 17, 2011 at 12:24

It's funny you mention linking to _start_T instead of _start for the reset vector. I just got an e-mail from GHS telling me to do that. The difference is that _start is in ARM mode, which of course is not allowed on the Cortex M3, while _start_T is in Thumb mode, which is *required*. Also, the vector table entries are one byte higher than the actual handler routine addresses. This also indicates Thumb mode. If you linked to _start instead of _start_T, your reset vector would be incorrect. I have rebuilt my application with _start_T, but won't get a chance to test it until Monday. I'll let you know how things work.