__IO, gcc and core_cm0.h

[pgregson1]

Posted on April 02, 2014 at 04:00

Hello,

I am porting the Custom HID demo project that is included with STM32_USB-FS-Device_Lib_V4.0.0 library to work with my gcc-based toolchain.  I have previously successfully ported other code (specifically, from Olimex for the EW-ARM 5.11 toolchain) to work with my toolchain with little difficulty.  

Both the new code and the previously ported code uses the __IO directive in places, and the library routines such as stm32f10x_adc.c also use it and were properly compiled and built in the previously ported code.  However, the new code throws a large number of errors when it tries to compile usb_pwr.c.  The first such error is:

In file included from ./inc/usb_lib.h:37:0,

                 from src/usb_pwr.c:31:

./inc/usb_regs.h:617:1: error: unknown type name '__IO'

./inc/usb_regs.h:617:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'wIstr'

In file included from ./inc/usb_lib.h:39:0,

                 from src/usb_pwr.c:31:

I can make these and a large number of my subsequent errors go away by putting

#define __IO volatile

in usb_pwr.c.  However, this makes that function non-standard which I don't want to do.

After much searching I found that an identical definition is provided in the CMSIS/Include directory in core_cm0.h.  

Where and how is this header normally included in the demo code?  Or is it included in the toolchain configuration?  It must be included somewhere to compile the demo.  I would like to duplicate that inclusion in my port or toolchain without modifying the distributed STM32_USB-FS-Device_Lib_V4.0.0 because that might give me major issues when that distribution is upgraded.

Any help would be appreciated.

Best regards,

Peter

[Tesla DeLorean]

Posted on April 02, 2014 at 04:11

Look at the MAP file, and listing file.

Do you have a Hard Fault Handler? Or is it weak linking to the default handler?

I'd look at the first 16 vectors (system handlers), and if you can identify each uniquely as a source?

I'd review the registers, and dig up the stack.

[Tesla DeLorean]

Posted on April 02, 2014 at 05:43

You could also create two destination handlers, and use bisection to figure out which vector it is coming from.

[Andrew Neil]

Posted on April 02, 2014 at 09:09

Debugging Cortex-M Hard Faults:

http://community.arm.com/thread/5414

[chen]

Posted on April 02, 2014 at 10:21

Hi

''Do I have to explicitly turn them off using NVIC_DisableIRQ with a long list of interrupt numbers?''

The NVIC is one or a number of registers (I would need to look it up).

You should be able to write to the registers directly and turn off all the configurable IRQs in the register directly without having to call the library routine NVIC_DisableIRQ()

Bear in mind that there are IRQs that cannot be turned off (NMI - non maskable interrupts)

It is a good idea to create special ISRs for the fault conditions (so that it is easier to trace the fault) and a separate default ISR for the other 'normal' ISRs

[pgregson1]

Posted on April 02, 2014 at 13:11

Perhaps my post wasn't clear.  Most often, the jump to the DefaultHandler occurs from some random location inside the startup_stm32f10x_ld.s code.  It usually hasn't reached main when it occurs.  I thought that that the system would have the interrupts turned off when it came out of reset.

Peter

[chen]

Posted on April 02, 2014 at 13:27

Hi

''I thought that that the system would have the interrupts turned off when it came out of reset.''

The reference manual should state the values in the registers for the peripherals when coming out of reset.

Please check the values for the NVIC controller.

''Most often, the jump to the DefaultHandler occurs from some random location inside the startup_stm32f10x_ld.s code.''

Are you sure it is random?

Have you checked, debugged the start up code to

a) see if there are any points where it causes an error

b) enables any IRQs

[Tesla DeLorean]

Posted on April 02, 2014 at 15:39

Perhaps my post wasn't clear.

I think it was, I just think you've been spending days looking in the wrong place. Unless you refine your search you'll be wasting more time on it.

I'd probably focus on the clocks, timings, and flash configuration. The stack, and what's going on in SystemInit()