Update: I reproduced the issue with the libopencm3 based program, so I
guess this is a physical issue like a floating pin or bad power
source.

2015-12-29 21:05 GMT+01:00 Szabó Antal <szabo.antal...@gmail.com>:
> I found a weird problem, If I update the LCD in a loop (with or
> without sleep) after some time (about 1 minute) the whole mcu locks up
> (hard fault). The exact same code works perfectly in the
> libopencm3-based program. Do you have any idea of what can cause this?
> Maybe some interrupt causes a corruption somewhere? I manually enable
> the AFIO clock at the beginning of the program, as I need to remap
> PA15 from a jtag pin to a gpio pin, can this be the cause?
>
> 2015-12-29 6:15 GMT+01:00 Szabó Antal <szabo.antal...@gmail.com>:
>> Hi!
>>
>> A few things work now mostly (LCD, buttons, leds).
>> Now I have to interface with an MPU9250 gyro/accelerometer/compass via
>> I2C, but the I2C examples are all a bit complex as they use premade
>> modules, so I can't yet figure out how to communicate with I2C. Any
>> pointers?
>>
>> 2015-12-28 19:22 GMT+01:00 Szabó Antal <szabo.antal...@gmail.com>:
>>> Hi!
>>>
>>> I just got to try it, and it works if I remove the
>>> "systemClock::enable();" line, otherwise it is stuck in that call. Is
>>> that bad?
>>>
>>> I also noticed there's a long (~1s) start-up time (when powering on
>>> the device) and looked at the listing, and noticed that the code is
>>> copied to RAM. Are these related? Why is this needed?
>>>
>>> 2015-12-25 0:55 GMT+01:00 Szabó Antal <szabo.antal...@gmail.com>:
>>>> Thanks, I'll try this.
>>>>
>>>> Happy Holidays to you and everyone else too :)
>>>>
>>>> Antal Szabó
>>>>
>>>> 2015. dec. 25. de. 12:32 ezt írta ("Niklas Hauser"
>>>> <niklas.hau...@rwth-aachen.de>):
>>>>>
>>>>> Hi,
>>>>>
>>>>> I’ve created a branch with a compilable STM32F103RC example:
>>>>>
>>>>> https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimental/examples/stm32f103rc/blink/main.cpp
>>>>>
>>>>> The fastest clock configuration from internal clock is only 64MHz (8MHz /
>>>>> 2 * 16) and NOT 72MHz, which is the max. allowed Frequency. Consult the
>>>>> STM32F1 Reference Manual (RM0008) Chapter 7.2 (Clocks) for details:
>>>>>
>>>>>         using systemClock = SystemClock< Pll< InternalClock, MHz64 >,
>>>>> AhbPrescaler::Div1, Apb1Prescaler::Div2 >;
>>>>>
>>>>> The clock tree is almost identical to the one from the STM32F100 so I
>>>>> expect this to work, but haven’t tested it in hardware.
>>>>> If the above configures the clock tree correctly though, the rest should
>>>>> pretty much work out-the-box.
>>>>>
>>>>> Please note that the STM32F103 clock tree support is experimental, since
>>>>> it builds directly upon the complex work of the future SystemClock:
>>>>> https://github.com/roboterclubaachen/xpcc/pull/39
>>>>>
>>>>> Happy Holidays,
>>>>> Niklas
>>>>>
>>>>> PS: You need to provide your own OpenOCD configuration file, since I
>>>>> cannot know what hardware you are using.
>>>>>
>>>>> On 23 Dec 2015, at 13:25, Szabó Antal <szabo.antal...@gmail.com> wrote:
>>>>>
>>>>> > I can't get it working yet, the compiler complains that it can't find
>>>>> > the xpcc::stm32::Clock type.
>>>>> >
>>>>> > Here is what I'm trying: http://pastebin.com/g3XdN0K9
>>>>> > (I intentionally left out the enablePll and switchToPll calls, as
>>>>> > those generated errors too)
>>>>> >
>>>>> > Here's the error:
>>>>> > main.cpp:7:22: error: 'Clock' in namespace 'xpcc::stm32' does not name a
>>>>> > type
>>>>> > typedef xpcc::stm32::Clock C;
>>>>> >
>>>>> > I also don't know what should the parameters be for enablePll.
>>>>> >
>>>>> > Can you please provide a small example like mine, with setting the pll
>>>>> > from internal oscillator, that at least compiles?
>>>>> >
>>>>> > 2015-12-23 12:37 GMT+01:00 Szabó Antal <szabo.antal...@gmail.com>:
>>>>> >> Hi!
>>>>> >>
>>>>> >> Thanks for this really quick and in-depth answer, this is a great first
>>>>> >> experience of the project's community :)
>>>>> >>
>>>>> >> I will try this, but possibly only after christmas, and report back
>>>>> >> where I
>>>>> >> got with it.
>>>>> >>
>>>>> >> 2015. dec. 23. de. 11:18 ezt írta ("Niklas Hauser"
>>>>> >> <niklas.hau...@rwth-aachen.de>):
>>>>> >>>
>>>>> >>> Hi Szabó,
>>>>> >>>
>>>>> >>> I just found xpcc, and it seems very promising. In my project I use an
>>>>> >>> STM32F103RC, and if I try to build a really simple project for it, I
>>>>> >>> get this error: "Error: XPCC Error: Could not find xml device file.”.
>>>>> >>>
>>>>> >>>
>>>>> >>> We wanted to only add Device Files for devices that we have tested.
>>>>> >>> I think I will just add a bunch of device files, so that we can get
>>>>> >>> hackers like you to not have to also deal with the hacky and
>>>>> >>> undocumented
>>>>> >>> device file generator (sorry).
>>>>> >>>
>>>>> >>> I looked in the tools/device_file_generator directory, but I don't
>>>>> >>> really know how to use it. So my question is, what do I have to do to
>>>>> >>> be able to use this mcu?
>>>>> >>>
>>>>> >>>
>>>>> >>> Here are all of my up-to-date device files:
>>>>> >>> https://www.dropbox.com/s/ea16rjmgdp4s63m/xpcc_xml_2015_12-23.zip?dl=0
>>>>> >>>
>>>>> >>> It contains the right file for the STM32F103rc
>>>>> >>> (stm32f103-r_v_z-c_d_e.xml)
>>>>> >>> plus a bunch more stuff.
>>>>> >>>
>>>>> >>> We don’t yet generate linkerscripts automatically (*poke* *poke*
>>>>> >>> @ekiwi),
>>>>> >>> so you also need to add a file to
>>>>> >>> src/xpcc/architecture/platform/linker/stm32   called   stm32f103_c.ld
>>>>> >>> with
>>>>> >>> this content:
>>>>> >>>
>>>>> >>>
>>>>> >>> MEMORY
>>>>> >>> {
>>>>> >>> ROM (rx)  : ORIGIN = 0x08000000, LENGTH = 256k
>>>>> >>> RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 48k
>>>>> >>> }
>>>>> >>>
>>>>> >>> INCLUDE stm32_ram.ld
>>>>> >>>
>>>>> >>>
>>>>> >>> I can compile it, when changing the project file for the STM32F1
>>>>> >>> blinky to
>>>>> >>> stm32f103rc.
>>>>> >>>
>>>>> >>>
>>>>> >>> https://github.com/roboterclubaachen/xpcc/blob/develop/examples/stm32f1_discovery/blink/project.cfg#L9
>>>>> >>>
>>>>> >>> I don’t have a F103 handy at the moment, so I haven’t tested this in
>>>>> >>> hardware, but it might just be similar enough to the STM32F100 to just
>>>>> >>> work
>>>>> >>> (@24MHz though).
>>>>> >>> You will very likely have to manually configure the clock tree using
>>>>> >>> this
>>>>> >>> class (well, the generated class):
>>>>> >>>
>>>>> >>>
>>>>> >>> https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/architecture/platform/driver/clock/stm32/clock.hpp.in
>>>>> >>>
>>>>> >>> The problem is that we cannot yet generate the System Clock Tree
>>>>> >>> classes
>>>>> >>> automatically, but there is a PR for that:
>>>>> >>> https://github.com/roboterclubaachen/xpcc/pull/39
>>>>> >>>
>>>>> >>> I will have a closer look at the System Clock over the holidays.
>>>>> >>>
>>>>> >>> Happy Hacking,
>>>>> >>> Niklas
>>>>> >>>
>>>>> >>> _______________________________________________
>>>>> >>> xpcc-dev mailing list
>>>>> >>> xpcc-dev@lists.rwth-aachen.de
>>>>> >>> http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
>>>>> >
>>>>> > _______________________________________________
>>>>> > xpcc-dev mailing list
>>>>> > xpcc-dev@lists.rwth-aachen.de
>>>>> > http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> xpcc-dev mailing list
>>>>> xpcc-dev@lists.rwth-aachen.de
>>>>> http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

_______________________________________________
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Reply via email to