2012-06-01 07:50 AM
Hi All,
STM32F0 Discovery kit projects examples for Arduino, Mikroelektronika and ST MEMS DIL24 boards are available from : UM1525 user manual is available from :http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/DM00050135.pdf
It explains how to set additional board to connect Arduino, Mikroelektronika or ST MEMS DIL24 boards. All .c/.h sources files are provided for : -Projects examples. -Mikroelektronika mikroBUS connector access. -Arduino UNO Analog in/Digital connector access -ST MEMS DIL24 connector access. Arduino basics functions are available. You should be able to develop projects and run existing sketch with few modifications. mikroBUS functions access call should give you possibility to run existing clickBOARD project with few modification too. All informations about STM32F0 Discovery kit are available from : Best regards Pascal #stm32f0-mikroelektronika-arduino #using-the-stm32-stdperiphlib2012-10-10 11:17 PM
As said, I don't have a EWARM installation.
But this looks more like the project itself is somehow messed up.Cannot call intrinsic function ''__nounwind __DSB'' from Thumb mode in this architecture.The DSB function is an intrinsic that comes with CMSIS (from ARM), that implements the DSB instruction as C ''function call''. I never heard of ''__nounwind __DSB''. This must be an EWARM spicific idea. And this ''...from Thumb mode in this architecture.'' looks like the project was/is not for an Cortex M, but for an ARM7 or so. Cortex M controller have ONLY Thumb instructions implemented, so there is something wrong.
2012-10-11 12:47 AM
You're right: there is some big mistake somewhere. I'll try with MDK-ARM to understand which could be the real issue. I can't understand why ST gives the preconfigured firmware which is not working.
Thank you again.Lupo2012-10-11 02:01 AM
''there is some big mistake somewhere''
Actually, there is probably just one small mistake somewhere. It is very common in 'C' (and other language) that one small mistake will lead to vast numbers of errors - because the one small mistake messes-up everything else which depends or relies upon it! In this case, there seems to be an ''undefined'' error for every single symbol from the standard peripheral library: GPIO_Pin_3, GPIO_Pin_2, GPIO_Pin_12, GPIO_Pin_11, ... GPIO_InitTypeDef, EXTI_InitTypeDef, NVIC_InitTypeDef, ... RCC_AHBPeriphClockCmd, etc, etc,...
Which suggests that the ''small mistake'' is that the required header has not been included at all, or the correct configuration #defines are missing...
2012-10-11 11:55 PM
Hi guys,
thank you for your support. I found the mistake: there were some misconfiguration in the ''option'' section which lead to the errors. Anyway the firmware provided by the ST is not ready to use as they would like us to belive. I have a question: which are the differences between ''F0514'' ''F0516'' and ''F0518'' settings for the ST F0? Lupo2012-10-23 12:29 AM
''Which suggests that the 'small mistake' is that the required header has not been included at all, or the correct configuration #defines are missing...''
For an apparently-similar problem - with resolution - see: