Forum : ARM
| Post Information | Post |
|---|---|
|
August 20, 2010 - 11:32pm
|
I am trying to develop my first "application" for a STM32 in Ride7 and simulate it in the integrated SIM_ARM. Unfortunately, I am getting erroneous results from some simple calculations. First, I declare a few variables as volatile so the compilter does not optimize the test code away. (note: main.h include a #include statement.) #include "main.h" //Global Varibales //--------------------------------------------------------------------------------- volatile float f1=25.2f; volatile float f2=.707f; volatile float f3=17.3f; volatile float f4; volatile float f5; Then, in the main subroutine I do a few test math operations:
/// Main function.
int main(void)
{
// Most of the peripherals are connected to APB2. Turn on the
// clocks for the interesting peripherals
RCC->APB2ENR = 0
// Turn on USART1
| RCC_APB2ENR_USART1EN
// Turn on IO Port A
| RCC_APB2ENR_IOPAEN
// Turn on IO Port B
| RCC_APB2ENR_IOPBEN
// Turn on the alternate function block
| RCC_APB2ENR_AFIOEN;
// Put Port A pins 8 through 15 into alternate function/50 MHz
// mode.
GPIOA->CRH = 0xBBBBBBBB;
// Put PB0 into push pull 50 MHz mode
GPIOB->CRL = 0x03;
//add
f3=(f2+f1);
//mult
f3=(f2*f1);
//divide
f4=17.5/(f1);
//trig
f3=sin(f2);
f5=atan(f4);
//more code deleted that continues initialization and begins infinite loop
}
The project compiles and links successfully. When I debug in SIM-ARM and step through the code the results are... From stepping throught the dissasembly, it looks like the following calls were made for the various opetations... I am entirely new to Ride7 and the cortex processors in general (experienced with avr-gcc and AVR processors), so I am sure I just don't have something set up correctly... but I have no Idea what. Thanks in advance for your help! |
Hi,
Thanks for your detailed report. We reproduced the problem in our Labs.
Our engineers are working on the issue. When using hardware debugging (RLink, REva or STM32-Primer), the code works fine, which might be an acceptable workaround for you.
This will be corrected in the next release of RKit-ARM through.
Regards,