Green Hills Multi Template

[jrubis]

Posted on March 03, 2008 at 10:32

Green Hills Multi Template

[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.

[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.

[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

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

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 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 ]

[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.

[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.

[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:25

I have changed my vector table to jump to _start_T instead of _start, and my app now runs fine out of flash. Pointing to _start generates a hard fault every time when running out of flash because it points to ARM code, which does not execute on the Thumb2 Cortex. Anyway, this is the final solution to my problem. Let me know if you have any more issues, although it sounds as though you are now running without problems also.