We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
I'm using Cortex-M3 and software float point. During C library initialization ( before reach main ) the fp_init will generate a bus fault.
Bus fault is not generated when Microlib is used.
I'm using MDK-ARM 4.10.
Have anyone experienced this issue with FP before?
What could be wrong?
The only workaround right now is to use Microlib or remove FP usage.
Depending on how the float point C code is removed/manipulated it will generate fault at fsub, fnormalize and so on.
Do you have enough stack?
I found what the problem was...
I'm using STM32. A flash sector is being used to store non-volatile data. The scatter line that was "declaring" that flash sector as EMPTY was commented out at a certain stage during development. Guess what? the app got bigger and bigger and end up being linked to exactly that sector, it did overlap with the non-volatile area.
Pretty much all C init routines where stored in there, that explains the weird behavior.
thanks for the help.
Always nice when people return back and posts the solution to their problems. Thank you!
Per, Agreed... closure is great.
Also,
I plan on using the STM32F103xG (1MB Flash) and I just want people aware of the 30 page errata on that part.
In particular, the SPI1 and USART2, and SPI2 and USART3 have conflicts.
I noticed this using the STM32F103xZ where the SPI's NSS signal wasn't hardware controlled. I had to bit-bang the NSS signal... a waste of CPU time.
The errata can be found here:
www.st.com/.../14732.pdf
Its linked from the main set of data-sheets:
www.st.com/.../familiesdocs-110.html
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
SPI's NSS signal wasn't hardware controlled. I had to bit-bang the NSS signal... a waste of CPU time.
The LPC2478 has similar issues with its SPI peripheral, but not its SSP1/2 that can be used to generate SPI frames. NXP admitted it, but did not add it to the part's errata sheet nor have they documented it in the user manual. "that's the way it is", they said. I kid you not :-)
I haven't read the documentation for the LPC2478, but wouldn't be too surprised if it is similar to the LPC2378. A master can control many SPI slaves, which means a need for multiple slave-select lines in master mode.
And not all SPI protocols toggles the slave-select between each word or between each burst. And different SPI slaves have different minimum requierments for the setup and hold times for the SS signal in ns or in relation to the clock frequency the SPI device is using.
So why should NXP add an errata for the chip not doing something that they haven't said that it should do?
Per,
I agree, but this feature is not even mentioned in the user manual. So, the reason why "it does not work" remains obscure until a scope is connected to the bus to reveal that the chip select line remains high...
The things we find out The Hard Way. This time, I'm prepared for the NSS signal's odd behavior.
Undocumented Features are always 'fun' when crunch time comes. One of the reasons to go with a FAST processor: to make it up by bit-banging.
(1x) STM32F103xG (ARM Cortex M-3) + (1x) USB Hub (uPD720114) + (1x) Xilinx FPGA (XC3S400A) + (4x) Ti TMS320C2812 (DSPs) + (4x) Actel IGLOO Nano FPGAs (AGLN250V2) ------------------------------------- = Sweet and fun times ahead... along with headaches + (x120) meds.