Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #57387 > unrolled thread

Trying to bring up mecrisp-stellaris on ARM M0 STM32F030F4P6, getting infinite loop of unhandled exceptions

Back to article view | Back to comp.lang.forth

Contents

  Trying to bring up mecrisp-stellaris on ARM M0 STM32F030F4P6, getting infinite loop of unhandled exceptions Richard Lourette <rlourette@gmail.com> - 2017-04-15 12:41 -0700
    Re: Trying to bring up mecrisp-stellaris on ARM M0 STM32F030F4P6, getting infinite loop of unhandled exceptions rickman <gnuarm@gmail.com> - 2017-04-15 16:03 -0400
    Re: Trying to bring up mecrisp-stellaris on ARM M0 STM32F030F4P6, getting infinite loop of unhandled exceptions David Schultz <abuse@127.0.0.1> - 2017-04-15 15:15 -0500
    Re: Trying to bring up mecrisp-stellaris on ARM M0 STM32F030F4P6, getting infinite loop of unhandled exceptions Richard Lourette <rlourette@gmail.com> - 2017-04-17 18:17 -0700
      Re: Trying to bring up mecrisp-stellaris on ARM M0 STM32F030F4P6, getting infinite loop of unhandled exceptions rickman <gnuarm@gmail.com> - 2017-04-18 11:45 -0400
      Re: Trying to bring up mecrisp-stellaris on ARM M0 STM32F030F4P6, getting infinite loop of unhandled exceptions rickman <gnuarm@gmail.com> - 2017-04-18 11:52 -0400
    Re: Trying to bring up mecrisp-stellaris on ARM M0 STM32F030F4P6, getting infinite loop of unhandled exceptions jonjo <jjonethal@yahoo.de> - 2017-04-18 12:20 -0700

#57387 — Trying to bring up mecrisp-stellaris on ARM M0 STM32F030F4P6, getting infinite loop of unhandled exceptions

I think I solved my problem by writing this post, but I will post anyway.

I was wondering if anyone can suggest how I can trouble shoot the looping unhandled exception I am seeing after installing a build of stm32f030f4 (obtained from GIT on 4/14). 

The CPU I am attempting to run it on is the STM32F030F4P6. It has 16k flash and 4k SRAM.

Any suggestion as to how to go about debugging this? This build runs on the ST DISCO board for the same family of processor.

The memory file for this build is as follows:


MEMORY
{
   rom(RX)   : ORIGIN = 0x00000000, LENGTH = 0x3800
   ram(WAIL) : ORIGIN = 0x20000000, LENGTH = 0x4000
}

SECTIONS
{
   .text : { *(.text*) } > rom
   .bss  : { *(.bss*) } > ram
}


I just realized the ram section length is 16k, but my CPU only has 4k. 

I still would like to know how I could have debugged this with a debugger.

Thanks for your thoughts.

Rich

[toc] | [next] | [standalone]

#57388

On 4/15/2017 3:41 PM, Richard Lourette wrote:
> I think I solved my problem by writing this post, but I will post anyway.
>
> I was wondering if anyone can suggest how I can trouble shoot the looping unhandled exception I am seeing after installing a build of stm32f030f4 (obtained from GIT on 4/14).
>
> The CPU I am attempting to run it on is the STM32F030F4P6. It has 16k flash and 4k SRAM.
>
> Any suggestion as to how to go about debugging this? This build runs on the ST DISCO board for the same family of processor.
>
> The memory file for this build is as follows:
>
>
> MEMORY
> {
>    rom(RX)   : ORIGIN = 0x00000000, LENGTH = 0x3800
>    ram(WAIL) : ORIGIN = 0x20000000, LENGTH = 0x4000
> }
>
> SECTIONS
> {
>    .text : { *(.text*) } > rom
>    .bss  : { *(.bss*) } > ram
> }
>
>
> I just realized the ram section length is 16k, but my CPU only has 4k.
>
> I still would like to know how I could have debugged this with a debugger.
>
> Thanks for your thoughts.

"Unhandled exceptions" are usually the result of doing something very 
basic wrong.  I find they are best found by going back to basics and 
looking at what you have done.  Debuggers tend to make problems more 
complex for potentially a long time before they make them simpler.

As an analogy, Jeff Fox once told me that stack over/underflow errors 
don't require a debugger, they just require a programmer who can count. 
The simplicity and truth of that statement hit me between the eyes.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#57390

On 04/15/2017 02:41 PM, Richard Lourette wrote:
> I think I solved my problem by writing this post, but I will post
> anyway.
> 
> I was wondering if anyone can suggest how I can trouble shoot the
> looping unhandled exception I am seeing after installing a build of
> stm32f030f4 (obtained from GIT on 4/14).

I recently had problems writing code for the Teensy 3.6 without using
all of the Arduino junk. Since there were no hooks to run gdb my ability
to debug was limited.

What I eventually resorted to, since it was working a little bit, was to
write some exception handlers that dumped the stack frame.

Fortunately I didn't have that much trouble when I ported eForth to it.
That is now happily running so I am working on my MPU-9250 data logger code.

-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

[toc] | [prev] | [next] | [standalone]

#57519

On Saturday, April 15, 2017 at 3:41:33 PM UTC-4, Richard Lourette wrote:
> I think I solved my problem by writing this post, but I will post anyway.
> 
> I was wondering if anyone can suggest how I can trouble shoot the looping unhandled exception I am seeing after installing a build of stm32f030f4 (obtained from GIT on 4/14). 
> 
> The CPU I am attempting to run it on is the STM32F030F4P6. It has 16k flash and 4k SRAM.
> 
> Any suggestion as to how to go about debugging this? This build runs on the ST DISCO board for the same family of processor.
> 
> The memory file for this build is as follows:
> 
> 
> MEMORY
> {
>    rom(RX)   : ORIGIN = 0x00000000, LENGTH = 0x3800
>    ram(WAIL) : ORIGIN = 0x20000000, LENGTH = 0x4000
> }
> 
> SECTIONS
> {
>    .text : { *(.text*) } > rom
>    .bss  : { *(.bss*) } > ram
> }
> 
> 
> I just realized the ram section length is 16k, but my CPU only has 4k. 
> 
> I still would like to know how I could have debugged this with a debugger.
> 
> Thanks for your thoughts.
> 
> Rich

Well, as it turned out, my assumption was wrong. I am still getting the unhandled exceptions. This is not code that I wrote, but a forth port called Mecrips-Stellaris for the STM32 family of processors. The port works find on the discovery board, which has 16k of Ram.

All I should have had to do was to define the RAM and Flash size for this part as it is part of the supported family. 

LMK if you have any insight.

Rich

[toc] | [prev] | [next] | [standalone]

#57551

On 4/17/2017 9:17 PM, Richard Lourette wrote:
> On Saturday, April 15, 2017 at 3:41:33 PM UTC-4, Richard Lourette wrote:
>> I think I solved my problem by writing this post, but I will post anyway.
>>
>> I was wondering if anyone can suggest how I can trouble shoot the looping unhandled exception I am seeing after installing a build of stm32f030f4 (obtained from GIT on 4/14).
>>
>> The CPU I am attempting to run it on is the STM32F030F4P6. It has 16k flash and 4k SRAM.
>>
>> Any suggestion as to how to go about debugging this? This build runs on the ST DISCO board for the same family of processor.
>>
>> The memory file for this build is as follows:
>>
>>
>> MEMORY
>> {
>>    rom(RX)   : ORIGIN = 0x00000000, LENGTH = 0x3800
>>    ram(WAIL) : ORIGIN = 0x20000000, LENGTH = 0x4000
>> }
>>
>> SECTIONS
>> {
>>    .text : { *(.text*) } > rom
>>    .bss  : { *(.bss*) } > ram
>> }
>>
>>
>> I just realized the ram section length is 16k, but my CPU only has 4k.
>>
>> I still would like to know how I could have debugged this with a debugger.
>>
>> Thanks for your thoughts.
>>
>> Rich
>
> Well, as it turned out, my assumption was wrong. I am still getting the unhandled exceptions. This is not code that I wrote, but a forth port called Mecrips-Stellaris for the STM32 family of processors. The port works find on the discovery board, which has 16k of Ram.
>
> All I should have had to do was to define the RAM and Flash size for this part as it is part of the supported family.
>
> LMK if you have any insight.

Mecrisp is available pre-compiled for the stm32f030f4.  Why are you 
compiling it?  Are you changing something?  What board are you using?


The pre-compiled form is a .bin or .hex file.  Once you have one for 
your chip, the only thing that might need to be changed is the UART.  I 
see this chip has a hardware UART, so unless you are swapping that out 
with a software UART so you can use the hardware UART in your app, I 
can't think of anything that needs to be changed.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#57552

On 4/17/2017 9:17 PM, Richard Lourette wrote:
> On Saturday, April 15, 2017 at 3:41:33 PM UTC-4, Richard Lourette wrote:
>> I think I solved my problem by writing this post, but I will post anyway.
>>
>> I was wondering if anyone can suggest how I can trouble shoot the looping unhandled exception I am seeing after installing a build of stm32f030f4 (obtained from GIT on 4/14).
>>
>> The CPU I am attempting to run it on is the STM32F030F4P6. It has 16k flash and 4k SRAM.
>>
>> Any suggestion as to how to go about debugging this? This build runs on the ST DISCO board for the same family of processor.
>>
>> The memory file for this build is as follows:
>>
>>
>> MEMORY
>> {
>>    rom(RX)   : ORIGIN = 0x00000000, LENGTH = 0x3800
>>    ram(WAIL) : ORIGIN = 0x20000000, LENGTH = 0x4000
>> }
>>
>> SECTIONS
>> {
>>    .text : { *(.text*) } > rom
>>    .bss  : { *(.bss*) } > ram
>> }
>>
>>
>> I just realized the ram section length is 16k, but my CPU only has 4k.
>>
>> I still would like to know how I could have debugged this with a debugger.
>>
>> Thanks for your thoughts.
>>
>> Rich
>
> Well, as it turned out, my assumption was wrong. I am still getting the unhandled exceptions. This is not code that I wrote, but a forth port called Mecrips-Stellaris for the STM32 family of processors. The port works find on the discovery board, which has 16k of Ram.
>
> All I should have had to do was to define the RAM and Flash size for this part as it is part of the supported family.
>
> LMK if you have any insight.

I forgot to mention that Terry Porter has a documentation page for 
Mecrisp-Stellaris at http://128.199.141.78/  Yes, he uses an IP address 
rather than a URL.  You can also reach that page with a URL I own, 
http://armforth.org/

Terry is familiar with compiling the sources for Mecrisp and in 
particular is big on the ST Micro parts.  He can be contacted on IRC 
chat or email as shown here.

http://128.199.141.78/contributors.html

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#57563

Hi,

i'm not using stm32f030f4 but some bigger stm's

have my Makefile attached and modified. It supports debugging via gdb.

i'm using gcc-arm 4.9-2015q3
https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q3-update

try this Makefile with gdb support mecrisp-stellaris-source/stm32f030f4/Makefile:


ARMGNU?=arm-none-eabi

COPS = -Wall  -Og -nostdlib -nostartfiles -ffreestanding -save-temps
AOPS = --warn --fatal-warnings

TARGET = stm32f030f4
PROJECT = mecrisp-stellaris-$(TARGET)

all : $(PROJECT).bin $(PROJECT).hex

$(PROJECT).o : flash.s interrupts.s $(PROJECT).s terminal.s vectors.s
	$(ARMGNU)-as -g $(PROJECT).s -o $(PROJECT).o

# offset 0x08000000 to enable flash with st-link utility
$(PROJECT).hex : $(PROJECT).bin
	$(ARMGNU)-objcopy -I binary -O ihex --change-addresses 0x08000000 $(PROJECT).bin $(PROJECT).hex

$(PROJECT).bin : memmap $(PROJECT).o
	$(ARMGNU)-ld -g -o $(PROJECT).elf -T memmap $(PROJECT).o
	$(ARMGNU)-objdump -D $(PROJECT).elf > $(PROJECT).list
	$(ARMGNU)-objcopy $(PROJECT).elf $(PROJECT).bin -O binary
	$(ARMGNU)-objdump --source --all-headers --demangle --line-numbers \
	--wide $(PROJECT).elf > $(PROJECT).lst

clean:
	rm -f *.bin
	rm -f *.o
	rm -f *.elf
	rm -f *.list
	rm -f *.lst
	rm -f *.hex




## jonjo

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web